Creating eForms applications
Before considering how to create eForms applications, let’s define what an eForms application is, along with a few other necessary concepts.
- eForms Application
-
In general terms, an eForms application is an application that:
-
can create a valid eForms notice,
-
can manipulate (read, modify, transform) an existing eForms notice,
-
can use the TED API to submit, validate or retrieve eForms notices.
-
- Valid eForms Notice
-
A valid eForms notice is an XML file that:
-
conforms to the eForms Schema (by means of XSD validation)
-
conforms to the eForms regulation by means of TED CVS validation
-
- TED CVS
-
TED CVS, (short for TED Central Validation Service), is a web service in the TED Ecosystem that verifies the conformance of a notice XML file with the eForms regulation. To perform this validation, apart from verifying conformance with the eForms Schema, TED CVS crucially uses a series of tests designed to verify the conformance of the structure and content of the notice XML with every applicable business rule.
- Business Rule
-
A business rule is a testable logical statement constraining the structure or content of information contained in an eForms notice. The business rules constitute in essence the implementation of the eForms Regulation.
Considerations
Based on the above definitions, the main criterion for a properly functioning eForms application, is whether or not it can create an eForms notice that can successfully pass TED CVS validation.
As easy and straight forward as this may seem, in practice there are several considerations that need to be addressed:
-
The implementation of the eForms regulation is still ongoing and there are still several moving parts.
-
The number of active business rules is in the order of thousands.
-
The number of fields is in the hundreds with several different configurations across the 40+ notice types.
-
Regardless of how stable the eForms implementation is, there will inevitably be several changes, adaptations or improvements in the regulation itself in the future. These will effectively keep changing the business rules, set of fields, notices etc.
Before creating an eForms application, therefore, one must consider and select an effective strategy for adopting to the inevitable change.
Paradigm
Considering the complexity of this issue for all our eSenders (as well as for our own eForms applications), in the Publications Office we have decided to adopt, promote and support the principles of metadata driven application design.
- Metadata driven applications
-
A metadata driven application is an application that adopts its behaviour to a given set of metadata. Changes in these metadata automatically alter the behaviour of the application without any developer intervention.
- Metadata
-
Metadata are data about data. Metadata are used to describe the properties of and behaviours attached to the actual data.
For an eForms application, data is the content of an eForms notice. Metadata is the content of the eForms SDK. The eForms SDK contains machine readable descriptions of the properties and behaviours associated with every data element in an eForms notice.
A metadata driven approach to developing an eForms application is therefore a design in which the application is agnostic of the actual types of notices, combinations of fields or business rules that it manipulates. A metadata driven application only needs to know how to obtain this information from the eForms SDK and automatically adopts its behaviour to this information.
In practice
Your eForms application needs to be able to read the eForms SDK. The necessary developer documentation is maintained on this site and will keep being updated as the SDK evolves.
Apart from being able to read the SDK, your application must use the information in the SDK to drive its behaviour.
Takeaways
There is even more complexity hidden behind the choice of following a metadata driven application design approach or not.
Consider that your application needs to modify a notice (or continue a procedure) that was created several months ago using a codelist that has since been modified. How do you know which is the right version of the codelist to use unless you put in place a mechanism for managing all this information? It gets even more difficult when you consider that some business rules may have changed since the specific notice was created. How do you know which ones?
The solution to this and several other similar problems is abandoning the idea of hard-coding eForms field by field into your applications and favouring instead a metadata driven design. Creating a metadata driven application will be far easier than implementing the entire regulation form by form, field by field. It will allow you to finish your developments faster and it will leave you with a much more maintainable application.