One of the core tasks in managing message formats (e.g. XML, JSON) is to store detailed descriptions of the rules applying to each field of a message. This information is used by the user maintaining the rules as well as by the computer system in charge of testing, validating and reusing it. This requires storing rules in a format both easy to read for the human user and efficient to process by the machine. Choosing OCL (Object Constraint Language) over alternative modelling solutions provides a range of benefits that manifest themselves in significant time savings and great flexibility.
Information transmitted in XML files follows a base structure, the “schema”; it defines the structure, order and names of all message fields. However, a wide range of limitations apply to the fields’ content not expressed in the schema. These so called “rules” may specify the correct format of an identification field or define interdependencies between various fields. They also help to validate that a two-letter country code actually refers to an existing country and such.
While the schemas have been designed to cover a wide range of transaction types, application-specific general rules further specify the use, for instance for SEPA payments, cross-border payments and the like. In addition, the variation in implementation between banks require specific rules for every use context.
Common approaches to defining rules are often rather inflexible. The widely established modelling language Schematron stores all rules in one file, making the management of hundreds of lines of code an intricate task. Also the popular method of encoding rules using the programming language of a validation software leads to difficult and slow workflows, as implementing changes requires rewriting the code.
The Object Constraint Language OCL is commonly used to describe rules related to sets of data. An OCL expression describes what fields a rule applies to and then carries out an operation on these. XMLdation has built their services on OCL, since it is a formal language that can be used throughout the entire production chain. OCL is utlilized to define the rules for a message format (either by the supplier or, with the new myXML service, by the client) and in the algorithmic processes as validation operations are carried out: the rules contain instructions that each field has to comply with.
“We often get asked whether OCL is yet another language for developers to learn.” XMLdation CEO Juha Keski-Nisula is well familiar with the concern that the complexity of XML management software increases rather than simplifies the complexity of day-to-day work. However, OCL does not pose such challenge; quite the opposite: “Given its highly legible syntax, this is so straightforward that users commonly pick up the basics in no time.” And indeed, looking at an OCL-formatted rule, users familiar with XML can easily grasp the logic and meaning.
But the easy learnability of the language is only the most obvious benefit. Since OCL allows to edit rules on a more granular level than for example Schematron, the time savings manifest themselves as tasks get more complex. OCL rules can not only be edited on a detail level, but are easily copied and reused. Also turning single rules on and off is quick and easy and modifications are easy to carry out by editing only the rules affected.
This feature of the OCL language is deeply rooted into XMLdation’s services. The XML management solution myXML, for instance, provides users with rule libraries. These sets of OCL-formatted rules can easily be copy-pasted between elements. And while myXML already comes with a broad range of pre-installed libraries (covering industry-standards such as ISO20022, CGI-MP and forthcoming EU eInvoice rules), users may also create their own libraries from existing rules – a significant productivity gain given the large amount of identical or similar rules applied in production use.
As the EU commission is finalising the PSD2 directive and its rules regarding XS2A, JSON is quickly establishing itself as a second messaging standard in the financial industry, along with XML. Thanks to the modular design of how rules are handled in XMLdation’s services, newly emerging standards do not pose a challenge. “XMLdation’s services are ready for PSD2, as the OCL-based handling of validation rules is independent from the XML standard,” Juha Hakomäki, Product Manager at XMLdation explains.
The independence of the rule definitions from the format of the validation payload provides great flexibility to the application of myXML and its siblings, the XMLdation Validator and Simulator. Keski-Nisula highlights how this provides an increasing number of industries to benefit from the reliable, cloud-based services the company offers: “We are not restricting our offering to payments. Our services are already being deployed for the management of e-invoicing messages, and we have inquiries from outside the financial industry as well. If it is a standardised message format, we can validate it!”