Some thoughts on validations for SAP Interactive Forms

I often get asked where validations for Interactive Forms should be implemented. There is the option to do it locally in the form using the possibilities provided by the Interactive Form (e.g. patterns or scripting) or it can be done on the back-end after the data is submitted back from the form. When you have to decide where to implement your validations you should also take a look at your scenario. If it’s an offline scenario you cannot do a server roundtrip for validations. Hence, validations have to be implemented twice: In the form and on the back-end. The recommendation here is to implement only validations that ensure data accuracy. More complex validations like verifying business partners should reside in the back-end. In other words do not put too much business logic into the form itself and error handling takes place on the back-end.

For offline scenarios a PDF has to contain everything you need for validations meaning the additional data (e.g. lists of allowed values) used for validating input is part of the PDF form and thus increasing it’s size. For online scenarios it’s easier since you can do a server roundtrip so you do not have to implement validations twice and include additional data. You only want to implement it on the back-end.

Validations

Interactive Forms allow defining two types of validations. The first one is a pattern-based data entry validation. The second possibility is to use one of the scripting languages (JavaScript or FormCalc) to implement a validation. While the first one only considers the actual field value, the latter can access other form fields via scripting.

Here is a description of building a small sample to play around with. In the sample we want to have a text field where either a code with either 3 or 6 alphabetic characters can be added. And it is not allowed to use the code “AAA”. Start Adobe Designer and create a new document. As next step drag a text field on the form. Go to the Object palette for the text field and select the tab “Field”. There “Limit length” has to be checked and the “max chars” are set to 6. As next step go to the “Value” tab. On this tab you can find a field/drop-down list for the validation pattern. Enter “text{AAA}|text{AAAAAA}” in the field. The vertical bar (|) is used to specify alternate patterns. In this case a pattern for a code with three characters and a second pattern for a code with six characters. “text” says that it is a text picture clause. For “Validation pattern message” enter something like “Pattern!”. And for “Validation script message” enter something like “Script!”. Now we have to implement the script for the check if the entered code is “AAA”. In the script editor select the “validate” event. Make sure the scripting language is JavaScript. For this event you can enter an expression that evaluates to true or false. Use the following expression: ‘this.rawValue != “AAA”‘. Save the form and do some tests in the PDF Preview.

For defining validation patterns it is necessary to know the pattern language. I strongly recommend taking a look at the Picture Clause Specification that is contained in Part 3 of the XFA specification. By the way if you have not seen my blog about “Useful documentation for developing Interactive Forms” I recommend looking at it 😉

In the picture clause specification you can find a pretty good description of patterns. Patterns are used in various ways for fields. You can define a display pattern, an edit pattern, a validation and a data pattern. A display pattern is used to format a data value when it is displayed on the screen. The edit pattern is used when a data value is edited. Validation patterns are used if a data value has to be validated after entry. And with the data pattern you can define in which format a data value is stored in the XML data.

Conclusion

You should add validations to your form wherever possible. Especially for offline scenarios additional “intelligence” greatly improves usability and acceptance. One thing that always should be done is to re-validate on the back-end to make sure no one manipulated the data.