XML and ebXML - What's involved?

XML (eXtensible Markup Language) is the basis of the "next big thing" - a way to connect millions of pockets of information via the Internet so that the next generation of Internet software applications can seamlessly work together.

ebXML (Electronic Business eXtensible Markup Language) is a modular suite of standard specifications that enables enterprises of any size and in any geographical location to conduct business over the Internet. The ebXML standard was finalised during May 2001.

Fortunately a primary objective of ebXML is to promote the use of shrink-wrapped, plug-and-play software via the Internet.  This means that ebXML's design and technical architecture remain within the reach of smaller businesses.

This page attempts to provide enough information so that you can ask the right questions and cut through the advertising spin the next time a software salesman darkens your doorstep. The sections are:

Although there are some issues to be wary of, XML / ebXML have an enormous potential to change the way you do business, so you should embrace them.

If you are in a small to medium size company, XML / ebXML can become a key component of your own EDI system - and then you can enjoy the benefits currently only available to larger companies, but at a fraction of the cost.

And while you develop your systems you will have the benefit of hindsight - the ability to learn from the successes and the failures of EDI over the last 30 years.

If you decide to use XML / ebXML - these are the basic steps

If you - or your industry - don't work through these steps - then it is unlikely that you will develop an eCommerce-capable system using XML / ebXML.

If your industry already has XML standards it may need to change its specified message structure to meet the requirements of ebXML. If your industry does not have an XML standard, then you can avoid retrofitting the new standard to existing applications.

Bear in mind that you don't HAVE to wait for the rest of your business partners to get started with XML / ebXML.

For example, if you are supplying products and services in a niche market and the majority of your customers are using one of (say) five industry-specific packages, chances are that it will be cost-effective for you to go ahead and develop your own in-house XML / ebXML solution because you don't have to cater to a wide audience.

While your competitors are hesitating about connectivity, you will be able to benefit from the advantages of automation. When your industry standard is established, it's only a modest change to adopt your standard.

The recognised steps to follow are these:

1. Agree on the the types of documents you want XML-enabled

Before you can consider XML / ebXML as a technology, you - or you and your industry partners (customers and/or suppliers) - need to establish a standard way of describing the types of information that flow between your respective businesses.

It may not be economic to try and deal with everything at once - but you'll need to identify what types of information are suitable to include. Sets of information related to Purchase Orders, Invoices, Payments and Confirmation Messages are a good place to start.

If your scope is broad enough, and you are part of a supply chain, using manufacturers' product numbers by all of the companies in your industry cluster (or supply chain) will simplify inventory tracking. Rather than using different codes assigned to the same products as they flow from manufacturer to distributor to retailer to consumer, unique identification makes accumulating data easier and make it easier to forecast requirements.

Another idea that you should seriously consider within your industry is to use a unique number for each company so trading partners have a common means of identifying each other.

2. Identify the types of data and the data relationships for each type of document identified in Step 1.

Once you have these various sets of information you'll need to specify the way individual fragments of data within each clustered set information relate to each other. For example, each Purchase Order will probably need a Date. Each Purchase Order Line will probably need a Purchase Order Line Type. (The skeleton you create can be handed to a XML / ebXML developer - they will call the document they create using this information a "DTD")

It is important to understand that once you begin automating your information flows that you are not really dealing with hard copy documents any more - you are dealing with information flows - processes rather than a string of individual events.

It is a process of invoicing sales related information or the process of purchasing / procurement rather than individual invoices or individual purchase orders that your systems will be dealing with. The idea is that the individual hard copy transactions disappear.

3. Identify any data variations that may be required for each document and define these variations.

There is likely to be a mix of standard and optional data fragments within each type of document.

Optional fragments are usually for a particular program so they are called "application-specific extensions". For example some people in your industry may need additional data fields in a standard document in order to automate their in-house software.

4. Develop a way of clearly differentiating each type of message you want to XML / ebXML enable.

You'll need clearly to identify each type of message - so that all of the computers involved know that a Purchase Order IS in fact a Purchase Order. Setting up and testing the design of prototype documents is the smartest approach.

5. Establish document verification rules

Then you'll need to create some rules so that when you receive a document you can make sure all of the data fragments you MUST have are in the right place and contain valid information and that any optional or extended data fragments are correct as well. Obviously this is particularly important if you intend to pull XML / ebXML documents directly into your in-house system without human intervention.

6. Establish Standards for Message Receipting and Notification of bad Transactions

You'll need to have a standard way of telling each sender that you have received their (say) Purchase Order Document - and they will need a standard way of getting the receipt. You will also need to agree on a way of dealing with bad transactions.

In some cases you might want use simple e-mail messages, but you should consider increasing the amount and the quality of the information you send.

For example, why not let the other system confirm your understanding of each line on a document and list any exceptions in your receipt message - say the differences between a delivery docket and the actual goods that were unloaded. (The remote computer should of course then "know" what to do about the short-delivery).

7. Prioritise how you will automate your in-house business processes

Finally - and this is optional - for your in-house systems you'll need to set up ways of "reacting" to the (say) Purchase Order documents you receive.

These types of programs are are sometimes called "DataBots" or "Agents". These programs sit waiting on your computer until something that they "understand" occurs - like a file arrives into a particular folder - or an document is added with the prefix INV. then they do what they have been told to do - like translate the information in the XML / ebXML document so that the information contained within it can be automatically uploaded into your Order Entry System.

These kinds of functions are often available with large-scale "Enterprise" systems by are usually beyond the budget of small and medium sized companies. Their options are usually to write custom DataBots or re-key information.

The Extensible Stylesheet Language (XSL) - part of the overall XML / ebXML concept - lets users display and format incoming data. As support for XML / ebXML grows, more and more applications packages used by small to medium companies will support XML / ebXML. Processing incoming XML / ebXML documents will become a mainstream software function.

You might restrict your initial efforts to sending/receiving XML / ebXML documents and making sure they are valid. DataBots or Agents may be an overkill to start with.

Integrating EDI, XML and ebXML

If EDI is widely spread through your industry you will need to consider ways to get EDI and XML / ebXML working together.

Using ebXML, "companies now have a standard method to exchange business messages, conduct trading relationships, communicate data in common terms and define and register business processes" (See: http://www.ebxml.org/ for more details)

Although you may not need to adopt the ebXML 100% to XML-enable your applications, by adopting the standard you can expect to reduce future system maintenance costs and overcome the problem of getting getting EDI and XML data to work together seamlessly. Working to standards will also help deal with another issue - translating EDI data into XML format - especially when there could be several variations within your industry. 

For an official "plain-English" overview of XML / ebXML you should read the "Frequently Asked Questions" page at http://www.ebxml.org/faq.htm.

Getting the most out of XML

To get the best out of your investment in automation you should try to combine the best features of XML / ebXML with the lessons learned from previous technologies - in particular EDI. Here are a few ideas:

a) Leverage XML and automation into your business processes - try to IMPROVE your business - don't just aim to automate existing procedures. Look at the way you link with every customer and supplier and seek way to improve and then automated your business processes. For example, if you are (say) a wholesale glass distributor, why not consider managing inventories for your customers.

b) Use brainstorming to extend the way you look at the technology. You might find that by dealing in very fine detail you can move your business to a new plateau. (If you're not sure what brainstorming is, check out The Learning Revolution).

For example if you are a flat glass merchant, why not capture the Batch ID's for each pack of glass you order and provide an ISO compliant system without any extra effort.

Or, if you are dealing with boxes and cartons of goods, why not capture their dimensions and weights and manufacturing batch ID's and transparently provide a quality control system that exceeds your customer's expectations. (The same information can also be used by tools like Cube-IQ to save 10-15% on your freight costs).

The more detail you capture the more control you will have over your business. Disk space is cheap and it the additional information costs you nothing - so why not?

c) Coordinate your business as if it were a ballet! Use your detailed data to manage issues like Just-In-Time deliveries. If you can, link with your suppliers and your customers and form supply chain systems where error-free and low-cost information flows are the norm - not individual labour-intensive paper-based transactions between just two isolated parties.

d) Merge your in-house systems with other technologies. The costs of doing this will get lower and lower and the more that you link the closer your relationships with your customers. For example, there is no real reason why your system cannot link to pagers or SMS/WAP cellphones.

Finally, look beyond the promises of the self-appointed experts (including us!). It is your business and your technology should let you do your business your way - but better and better - especially of you take advantage of the benefits of XML and the new ebXML standard.

See Also: EDI Explained

Back to Top

eCommerce - eBusiness - XML - Back to Remarkable Home Page
XML eBusiness with CustomShop eCommerce

Unless specified otherwise, the entire contents of this site are protected by copyright.
(c) 1999-2010 Noel Ferguson / Remarkable Ideas Ltd. All Rights Reserved.
Postal Address: PO Box 633, Tokoroa 3444, Waikato, New Zealand
Mobile: +64-27-306-8999 After Hours: +64-7-886-0445