preview : a rule a minute

At the end of May, the xlinkit Rule Workbench will start its early access programme. As a test of things to come, we thought we would give you an inside look of how validation rules can be quickly put together and tested. Hopefully this will kill your appetite for coding your business rules in programming languages for good!

The rule: the rule we are going to look at is a draft rule for an FpML Equity Derivative trade, an XML representation of a financial trade (the rule is not endorsed by ISDA or any of the FpML working groups). It reads as follows:

In equityAmericanExercise, if latestExerciseTimeType is equal to SpecificTime then latestExerciseTime must be present.

As you can see, the rule expresses a constraint of the form if element A has a certain value, another element must be present, and thus cannot be validated using XML Schema. Off we go.

1. work on the rule structure

In the workbench, you express your rule as logical rules that will be saved in the CLiX rule language - in XML form. Click on the screenshot for an expanded version.

You can add more formula constructs to make the rule tighter by right-clicking on the placeholders. In the logical form, our rule will read

For all equityAmericanExercise, (latestExerciseTimeType = 'SpecificTime') implies that there exists latestExerciseTime.

2. select elements from XML documents

CLiX uses the standard XPath language to pick out elements from documents. Frequent users of XPath know that it can be tedious to identify elements in documents without making mistakes, and there are nasty details like namespaces to keep in mind.

Fear not, the workbench takes care of XPath for you. Click on the screenshot to the left to see how the "recording mode" in the XPath editor generates path expressions.

Of course, if you're an XPath wizard, we'd rather not humble you by generating your paths. You can click the Evaluate button and the workbench shows you the result of the path you've written.

3. write a report

Our rule is now complete, as you can see on the left. We've also entered a report message in the report window at the bottom - this message, which can contain XML elements - will be displayed as part of an XML or HTML report when a rule check is performed.

4. analyse rule impact

Rules need to be tested properly. Contrary to intuition, this doesn't just mean executing the rule over broken documents and making sure that errors are picked up. It is equally important to check whether the rule has been applied at all!

In our example, we say "for all equity exercise dates". If there is no equity exercise date in some document, the rule will actually hold, but if you get the paths wrong it will always hold. So it is no coincidence that a rule impact analysis component is included, which tells you whether your rule checks everything you thought it should check. In the screenshot on the left, you can see that all elements access by the rule are marked, and some information is displayed on how many elements the rule accesses.

5. execute the rule

Now, let's try and run the rule over a broken document. The screenshot on the left shows you what happens: the patented xlinkit rule evaluation semantics picks out elements from the document that contribute to violating the rule. In this case, it has picked out the equityAmericanExercise element.

The execution view also shows the report for the rule. If the report had included paths to pull out elements from the document, the values would also be shown here.

6. run a batch check across your documents

The rule is done and dusted. We can now run a batch check across all our documents, to ensure that they are all compliant.

A batch check is set up as an eclipse run configuration. This means that it is stored in your local configuration, and you can re-execute it quickly. You can also bundle rules and documents together in different run configurations. Click the screenshot to see the results of the check, again with an error report for broken documents.

done : summary

With a few mouse clicks, and using some clever wizards and dialogs, we have implemented a validation business rule that can now be shared in XML form, used in test harnesses, translated to HTML for documentation purposes, and is not buried in code.

interested? participate!

If you are interested in the xlinkit Rule Workbench, and would like to join the early access programme, please contact enquiries@systemwire.com. Participants will be screened for eligibility.