May 23, 2011, 11:33 p.m.
posted by un
Nearly everything considered in this chapter related specifically to XML. However, you may be considering building XML support into your application because of increasing demands for integration with other applications or the need to exchange common business documents electronically with trading partners. Requirements like these come with a few issues that have nothing to do with XML specifically but that you may want to consider.
Looking Up and Converting Coded Values
In Chapter 10 we talked about looking up UPC numbers used in purchase orders from customers and converting them to the item numbers used in our own systems. This is just one example of a common problem. Chapter 9 hinted at another potential problem in the discussion of the X12 purchase order example. A common practice in retail and grocery orders is to send an identifier, such as a DUNS number with a four-digit location suffix, as a ship to location rather than sending the full name and physical address. It is common for EDI management systems to allow users to define their own lookup and cross-reference tables for such purposes. However, the situation might be easier for users to deal with if lookup and cross-reference features were included in their business applications. I have seen such features in high-end enterprise resource planning (ERP) systems but have not seen them frequently in lower-end systems.
In addition to lookup and cross-reference tables, there may be data that, while not cross-referenced or converted, is required by trading partners. One example is a customer-assigned vendor number that might be required in all invoices and shipment notices sent to that customer. The vendor number could certainly be hard-coded into the appropriate XSLT stylesheets. However, it would be much more user friendly if there were a user-defined field where it could be maintained in the application's customer information subsystem. Similar information might need to be stored for each ship to location and each line item of a purchase order. For example, a UPC number might be the primary item identifier used to cross-reference against the item numbers used internally. But there may be one or more secondary identifiers that need to be captured and sent back to customers on invoices and purchase orders. I know it sounds like overkill, but it is common practice.
There are examples beyond just the traditional procurement cycle. State and federal agencies may assign organizations identifiers for certain types of regulatory compliance. If compliance data needs to be reported electronically, having fields for the identifiers in your own company record would be much easier than hard-coding them in your XSLT stylesheets.
Business Process Support
This is another area that goes beyond the scope of this book, but you need to be aware of this issue. The book has dealt with data and technical approaches for processing data at a fairly detailed level. Business process support has to do with the overall context in which the data is exchanged. This is most often a factor when dealing with business processes that cross organizational boundaries but may be a factor with internal systems that manage work flow.
In the cross-organizational sector, several groups such as RosettaNet, the Uniform Code Council in cooperation with the European Article Numbering Association (UCC/EAN), and UN/CEFACT have or are beginning to develop models that describe common business processes such as procurement, fulfillment, and payment. These models describe a series of actions that might together constitute a process. They define not only the data that might be exchanged in each step but also the conditions that must be satisfied to move from one step to the next. For example, a purchase order might be exchanged in one step of a procurement process. The process might then specify the conditions under which the order is accepted or rejected. The next step might specify that a purchase order acknowledgment be returned with specific information regarding acceptance or rejection. The model might specify different succeeding steps depending on the order status. These models can be very comprehensive, with some even considering what constitutes a legally binding contract.
It is difficult at this time to know whether or not these efforts will have an impact on requirements for business applications, and if so how great the impact will be. In some scenarios the impact would be considerable. In the case of ebXML (Electronic Business XML, www.ebxml.org), full support for the framework requires that applications be configurable using business process information read from a special type of XML document. Applications may also need to maintain certain information about the state of business processes that they don't currently track.
My own opinion is that many of these initiatives are premature. They are too ambitious not only in terms of the ability of application vendors to absorb the requisite technology but also in terms of the ability of organizations to adopt the processes. If these initiatives gain significant following, my best assessment is that it will still be several years before they do have significant impact on most business applications. It would, however, be prudent to at least monitor them.