Views
Universal Business Language (UBL)
From PicoForms
Contents |
[edit] Introduction
UBL is intended to bring the benefits of electronic business to the widest possible business audience. It describes a set of common, inter-business processes, centred on the buying and selling of goods and services, and the documents (purchase orders, invoices and the like) required to drive them.
UBL covers much of the same ground as the venerable Electronic Data Interchange (EDI) standards, but has defined business documents in the now much more ubiquitous XML language. XML tools certainly have the potential to be cheaper and easier to use than those that work with EDI, and XML skills are much easier to hire or acquire than those needed to work with EDI.
Although EDI is a set of standards, there are many versions in use, and even within one version there are optional elements, and often more than one way to achieve the same end. Consequently no two implementations of an EDI message are ever likely to be the same.
It follows that a necessary precursor to the exchange of EDI messages between organisations (say orders and invoices) has always been the setting up of each trading partner's systems to understand and correctly process the particular, nuanced versions of EDI employed.
This is one of the issues addressed by UBL: there are only two versions thus far, and concepts are expressed in a consistent fashion. However, there are still many optional elements to UBL, and so many possible variations to interface with. So whilst UBL makes the development and testing phase less onerous, they still require care and attention. This paper explores how the complementary XML technology XForms can be employed to aid the development and testing phase of establishing links between new trading partners.
[edit] On The Importance Of Documentation
A key aspect of any data integration project is clear, unambiguous and complete documentation. No developer can be expected to do a good job without it. Exchanging UBL messages with a trading partner is no different. Fortunately the documentation that makes up the UBL specifications goes a long way to making the task of creating and maintaining documentation that much more straight forward than it might otherwise be.
Each user of UBL needs to create a profile of the subset of UBL that they employ and to layer details of their own particular usage over the documentation already provided.
Generally speaking it is necessary to document:
- Process, e.g. you send me an order, I send you an invoice.
- Structure, e.g. my order document will contain the following fields.
- Values, e.g. the value of field
xmust be a currency code from this list.
The last two especially have considerable bearing on what instances of particular business documents will look like.
UBL provides XML Schema to describe the valid structures and lexical values of business documents, and also an XML-based methodology for defining contextual constraints on the use of values and structures.
Ideally an organisation should be able to provide its trading partners with documentation that expresses the sum of the above and tools that allow them to test accurately whether or not they are able to produce or process documents that are conformant.
UBL is expressed using widely used XML technologies, such as XML Schema to define structure and lexical values, and Schematron to define context-dependant constraints. Consequently it is possible to bring to bear yet other XML technologies to generate human and machine processable documentation directly from these sources. For example, HTML pages, or PDF documents can be produced automatically.
Similarly with XForms we can create useful and authoritative documentation from such sources. The difference is that with XForms we can create something that is much more than just documentation.
[edit] XForms as Documentation
XForms is an XML language developed by the W3C for defining electronic forms that directly populate and modify XML documents. So, one might build an XForm to allow a user to add lines to and fill in values in a UBL order.
XForms allows the developer to enforce structural and lexical constraints by importing XML Schema, and to express contextual constraints using the same basic technique as that employed by Schematron (using the XPath language).
So, our order form will reference the UBL XML schema directly and import any constraints defined using Schematron in order to implement the business logic of the form.
All well and good, but remember that XML Schema and Schematron are also expressed in XML, so our form can display both the UBL order document and the associated schemas. Furthermore, the form can be written to relate the parts of the UBL order document to the relevant bits of the schemas. The schemas already contain documentation, so that too can be displayed to the user. Like this:
[edit] A Walk Through The UBL
The first and most obvious application of XForms as documentation is to provide a nice mechanism for stepping through a UBL document. The form can be constructed in a generic fashion, such that any UBL instance can be loaded into the same form and viewed as above.
So a company might build a set of representative UBL messages to indicate which structures and fields they use. Values can be displayed as input fields in the form.
Clearly the walk is much more interesting if note is made of points of interest. This is achieved here by traversing the UBL schemas associated with the instance. In this example the annotations contained within the schema are displayed.
[edit] Getting Interactive
So far what we have is really no better than an HTML page, but as we are working with a form technology there are much more interesting possibilities.
The simplest of these is to simply allow the user to edit the values exposed by the form and save what they have. Thus the user can create their own sample messages.
Less obvious, but perhaps more useful, it is equally possible to allow the annotations in the schema to be added to and otherwise modified, as the following screenshots illustrate:
[edit] Testing Times
Allowing values to change means that we can start to take advantage of XForms' validation features to do some testing. XForms imports the UBL schemas and will style the form to tell us if a value is invalid:
However, we can manage something more useful than that, by adding annotations to specific kinds of validation error and displaying them to the user. For example we might have a rule that the items being ordered must be ordered in quantities of either 10, 50 or 100. Clearly the current value is invalid by virtue of not being numeric, but if we can express the more complex rule as an XPath expression, then our form can both enforce and report the problem arising.
This approach could be adapted to present the user with a list of validation errors and descriptions, along with the means of navigating around the form to view and fix where possible. So we now have a tool that contextualises the documentation displayed to the particular UBL instance that is currently loaded, and will dynamically change as that instance is itself modified.
[edit] What Next?
Our next step is to get the form to work well with Schematron-based value validation using genericode, and that will happen in the next few days. Once this is done we have a very useful documentation, testing and debugging tool.
If we take our approach to its logical conclusion, we might imagine a service, hosted by a company that has invested in data interchange using UBL. The service would allow trading partners to log on (in order for any TP specific rules to be activated) and to view online documentation.
To begin with a new trading partner might generate some sample messages to download using the forms and work through the messages. Later they might upload their own UBL instances to run through forms in order to see if they are compliant.
