2 eBusiness Fundamentals

This section of the paper reviews eBusiness fundamentals – the “nuts and bolts” of what is required in electronic exchange of information.


The importance of processes cannot be overstated. The most basic perspective of a process is that it’s doing stuff and a company must do stuff to make money. Furthermore, process is critical to effectively implementing eBusiness systems. So often implementers want to jump right to the message (e.g., purchase order, invoice) without fully understanding individually, within a company, and among a set of trading partners what the process is in which a message sent. Messages are not exchanged in a vacuum. Messages are always exchanged in the context of a process. They’re sent in support of doing stuff.

There are two ways of thinking about processes: activity flows, and states and transitions. Activity flows are simply an ordered set of activities (or actions). The process starts. “A” happens. Then “B” happens. Then “C” happens. Then the process is complete. Flow charts are likely a familiar way of expressing activity flows. A key characteristic of flow charts is conditional flow. If condition “X”, then “D” happens; otherwise “E” happens.

A states and transitions view of a process considers the process as always being in a particular state. Events occurs that change the process state. While thinking of entire processes in terms of states and transitions is not common, it’s quite common to think of specific points of a process in those terms. What’s the status of ...? Processes as states and transitions can be expressed in diagrams and prose. We’ll examine these approaches in the next section: eBusiness Standards, Guidelines, and Implementation Technologies.


Messages, or documents, are frequently the most identifiable aspect of eBusiness. It’s natural to converse in terms of purchase orders, inventory reports, and invoices.

Message Name: The name of a message is important in that it is the term used in conversation among people within a company and between companies and their trading partners. When processes are documented, message names anchor the message in the context of the processes in which they occur. Often message names are bipartite (e.g., OrderCreate) with one part referring to an object (e.g., Order) and another part referring to an action (e.g., Create). More on this in section on standards.

Message structure refers to how message data is organized and possibly tagged. Often messages have a header with information that generally occurs just once, and a body with repeating information. Some message syntaxes (notably XML) include tags that identify the data that follows. Some messages include envelope information. eBusiness standards experts are divided in their opinions on what envelope-related data should be specified at a message level versus at a transport and routing level. We’ll touch on enveloping in the Message Transport & Routing section, and address it in more detail in the eBusiness Standards, Guidelines, and Implementation Technologies section.

Message data is the meat of any business message. Structure can tell you that something is a shipping address, but data tells you what the address is. It is important to understand that ultimately systems and/or people interpret data as values that stand alone, or as values that refer to a concept further defined elsewhere. Let’s explore common types of data.
  • Stand-alone values: These are values that cannot be further de-referenced. They include such values as Tom as a first name, Enid as a city, and 7 as a quantity. Often a related set of stand-alone values can be referred to by an identifier, which brings us to our next type of data.
  • Identifiers: Simply put, identifier value types refer to something that generally would need to be described in a set of values. For example, 23232399 could be the identifier for ACME Widget Company’s bill-to location, 83838311 could be the identifier for one of ACME’s Bluetooth-enabled turbo widgets. Identifiers are a critical concept in messaging, and are explored in more detail in the next section.
  • Code list values: Code list values are a sub-type of identifier. They are often defined by industry associations, national standards organizations, or global standards organizations. More on code lists in a later section. Code list values usually change less frequently than identifier lists. Code lists can be a meaningless code (e.g., 123), short meaningful code (e.g., EUR for Euro), or a word or phrase (e.g., exceed).
  • Reference data: Reference data is a term commonly used among companies who provide agricultural field operations solutions (and perhaps others). While reference data is presently not clearly defined as a category distinct from other data types, it is generally understood to be possibly frequently-changing lists of acceptable values provided by some authority. In that sense, identifiers and code lists would be regarded as reference data. However, reference data can also be a long list of descriptive words or phrases.


Identifiers identify stuff. That’s obvious. But let’s break that down a bit. A reason that something is identified with an identifier is because it would be tedious to communicate all the data required to otherwise identify the referent. That means that identifiers must be unique within a given scope, that the scope is clearly understood by all systems that process the data, and that the authority for identifier creation and assignment is clear.

While people intuitively understand that an identifier refers to a single thing, many people don’t appreciate that a thing must have a single identifier, or alternatively have a way to indicate that two or more identifiers refer to the same thing. (A common pattern for addressing this is by declaring a master identifier to which other identifiers are related.)

As a general rule, the characters in an identifier should not have semantics beyond the identity of the referent. For example, using a person’s mobile phone number as their identifier, while seemingly convenient, can lead to negative consequences. Phone numbers change. The consequences are that a process must be put in place to change the person’s identifier (leaving a disconnect to historical data) or leaving the identifier unchanged resulting in broken processes that depend upon an employee being able to call a person using their identifier.

A consequence of a clear identifier scheme, and authoritative identifier creation and assignment process is that two things can unequivocally be determined to be the same or, equally important, different from one another. This concept is critical within an enterprise and within a trading-partner community.

Message Transport & Routing

Message transport and routing addresses the part of the eBusiness process whereby messages are delivered from one system to another. For simple eBusiness implementations, this could be a directory accessible to both the sender and the receiver through FTP. More robust systems require standards-based solutions, which are discussed in the eBusiness Standards, Guidelines, and Implementation Technologies section.

Envelopes: Message envelopes are sometime regarded as part of a message itself and sometimes regarded as part of the message transport and routing layer. Message envelopes may provide such information as:

  • Who the sending party is
  • Who the intended receiving party is
  • What sort of normal processing is expected
  • What sort of error processing is expected
  • Encoding information

The term envelope stems from use describing message contents as being wrapped by or inserted in an envelope. One might also hear the term message metadata or message header although with the latter one must be careful to distinguish between transport and routing header data and message contents header (i.e., the header in the common header/detail message structure pattern).

Data Security, Ownership, and Privacy

Basic principles of security include:

  • Privacy: Message contents are readable only by the sender and intended recipient.
  • Authentication: The sender’s identity can be verified by the receiver (and vice-versa, if necessary).
  • Integrity: The receiver can verify that what they received is what the sender sent (i.e., the message was not altered in route).
  • Non-Repudiation: The receiver has a means whereby they can confirm that a particular sender sent a specific message such that the sender can’t credibly deny it. Optionally there may be the ability to affirm date/time.
  • Authorization: The sender is permitted to deliver a particular message to a receiver and to expect such message to be processed by the receiver.

Circumstances dictate which combination of the five security components are required, and how they are to be implemented.

Data ownership and privacy: The term data privacy is often used in the context of one party providing data to another party for a narrowly specified purpose. For example, one party may deliver data to another party for the purposes of transforming the data into an industry format and passing it on to a final recipient. Another example would be a pool of data owners providing data to a service provider for the purposes of receiving benchmarking reports.

In many cases, many kinds of data are owned by the sender; what intermediaries and final recipients may do with that data must be explicitly permitted by the data owner through written agreement. It is beyond the scope of this paper to break down types of data (in a privacy/ownership context) and the nature of agreements between data owners and other parties. These are first and foremost legal and business-relationship matters. Technology plays a role in enabling secure data flows.

Message Creation and Consumption

The steps in the message creation process are straightforward:

  1. An event occurs in your business that triggers a need to send a message. For example, the event could be the need to order triggered by low inventory.
  2. Create/retrieve data from appropriate system or systems.
  3. Format the data in a way agreeable to your trading partner.
  4. Deliver message to business messaging server, with metadata as required. (At this point the messaging server delivers the message to the trading partner’s system.)
  5. Process business acknowledgements as required (this step overlaps with message consumption).

While processes among trading partners are usually documented at a bird’s-eye view of the interactions between firewalls, such documentation should provide useful references to which internal message-creation triggers can point. For example, low-inventory order triggers are critical to clearly understand within your own business, including understanding how such an internal process integrates with the order-to-cash process as shared between you and your trading partner. While discussing the internal triggers and activities with a trading partner may help round out a conversation, such things are usually irrelevant to the day-to-day eBusiness operations.

The process and ease of creating/retrieving data varies widely across companies and across business processes within companies. In some circumstances the data may be entirely contained within the system producing the message and conveniently available. In other circumstances the data may be strewn across several systems and geographies. For some companies it’s not a big deal. For other companies it’s a major ordeal.

Formatting data in a format agreeable to your trading partner of course implies that such an agreement is in place. More on this topic in the eBusiness Standards, Guidelines, and Implementation Technologies section. Once data has been created/retrieved, formatting the data in the agreed-upon format depends on a number of factors:

  • Does the business system support the format “out of the box”?
  • Does the format of the source data and the agreed-upon format lend itself to straightforward mapping?
  • Does the company have expertise on staff or available who:
    • understands the agreed-upon format?
    • understands the required message syntax (e.g., XML, EDI, JSON)?
    • understands the business rules that shape the message requirements in various contexts?

Usually delivering messages to business messaging servers is straightforward. However challenges can arise due to real or perceived process incompatibilities among trading partners and/or industry segments. For example, trading partner X might demand that the technical details of a process must be implemented in a way that’s incompatible with what trading partner Y requires.

Finally, systems must respond appropriately to business acknowledgments. For example, an order was accepted, an order was rejected and for what reason. Given that such acknowledgements are messages themselves, it might seem out of place to mention them here rather than in the Message Consumption section, but it’s important to understand that creating and “putting a message on the wire” is not the end of the story for the message.

Message consumption is the process of receiving a file and processing it. Steps include:

  1. Store the messages in a persistent data store (e.g., database, file system, cloud service)
  2. Determine the business-process context to which the incoming message applies. Does the message initiate a new instance of a process or is it a step in a process instance already in progress?
  3. Perform security validation, if necessary (e.g., authentication, authorization, integrity, non-repudiationùthe first two of which may be implemented as transport-and-routing-layer functions)
  4. Confirm that message is complete, consistent, and conforms to business rules.
  5. If necessary, transform the message into a format (or formats) suitable for ingestion into the receiving system.
  6. Ingest the message content.
  7. Confirm conformance to additional business rules not validated earlier.
  8. Provide business-level acknowledgements to the sender per agreement.

As with message creation, the level of effort to ingest message content varies widely across companies and across business processes within companies.

< Back to White Paper Home    Chapter 1   Chapter 2    Chapter 3    Chapter 4