Accessing data nodes in SAP Interactive Forms

[Former Member]

In my last Some thoughts on validations for SAP Interactive Forms. To implement validations using scripting it is often very useful to have additional data you can use (e.g. a list of valid codes, a price list, a list of discounts). Using scripts to do validations has the following advantages: you can access other fields and you can even access data. Additional data can be part of the XML data that is part of a form. And it is not necessary that all data nodes are bound to form fields. It is easily possible to define a section in your data that contains additional data that is not visible on the form it is only used by scripts. It is also possible to do nothing at all with a data node. This allows for example to include a form/process identifier in a form. Nobody can see this identifier and this identifier is used to track instances of a form. This is useful in offline scenarios when you have to process a form that is submitted back to the back-end.

Accessing data nodes is also useful when you implement calculations on you form.

Accessing data nodes

Now, I want to discuss the question on how to access a data node in a script. I'm using JavaScript in my examples. This is very easy; you just have to know how it works.

Let's assume the data structure looks as follows:

 1
 

The form data is part of the XFA DOM (XML Form Architecture Document Object Model) that is built for every form. The data can be found under the node "xfa.datasets.data". To get the actual value of a node the "value" property has to be accessed. The following if-statement checks if the value of the attribute "an_attribute" is "3".

if (xfa.datasets.data.my_data.second_node.an_attribute.value == "3") {
 // do something
}

A second possibility is to use "$record" or "$data". $record is a shortcut for "xfa.datasets.data.mydata". "$data" is a shortcut for "xfa.datasets.data". A script using "$record" could look like the following example:

if ($record.node.value == "1") {
  this.presence = "invisible";
}

My Access Mode and Presence of Fields on Adobe Interactive Forms of form fields explains what happens in the example above if the value of the data node is "1". It's no surprise the field/subform is set to be invisible. 

Let's take a look at an Web Dynpro application. For a view that contains an Interactive Form there is a mapping defined between the view's context and the data context for the form. It is important to look at the root node of the data view. So in the example above the my_data node is the name of the node that is the "dataSource" for the InteractiveForm UI element. The "data view" of Designer helps you to putting together the expression to address a node.

Accessing data in table-like structures

Hierarchical structures are built using nested subforms. This is also true if you build them using tables. Each subform knows its index amongst all siblings. A form field can then use a script to ask its parent (a subform) for the index. The code looks like this: "this.parent.index".

Here's the complete example of how to get the value for a given row in a table-like structure:

xfa.resolveNode("xfa.data.my_data.tableData[" + this.parent.index  + "].column1").value

resolveNode is a helper function that allows to evaluate SOM expressions (SOM = Scripting Object Model). It takes a SOM expression (string) as input and returns a node object. On this node object you can access the "value" property.

Conclusion

A form can contain data that is not bound to form fields. This additional data can be accessed via scripting. Advantage is that you can include data (not bound to form fields) into forms that can be used for validations and calculations. The disadvantage of accessing data from a script is that the path to the data node is contained in the script expressions or even as a parameter for resolveNode. This means when the data structure changes also the scripts have to be changed.

Remember if you are doing calculations and validations in a form you have to repeat them in the back-end to ensure that the data has not been manipulated between the end user and your back-end.