Business Object Document Message Architecture

1.0 Overview

In order to achieve interoperability between disparate systems, disparate companies and disparate supply chains, there must be a common horizontal message architecture that provides a common understanding for all.

Once a horizontal messaging architecture has been agreed upon these messages can be sequenced together to form scenarios. Scenario can provide the detail step-by-step exchange of information needed to perform specific tasks. These tasks can be simple or complex. As such, the scenario describing them may be simple or complex. Complex scenarios may reuse one or more simple scenarios.

The Open Applications Group Integration Specification (OAGIS) provides example scenarios that can be used as a starting point for integration. By identifying a scenario that most closely matches your needs, it is possible to identify the messages needed to achieve your needs.

The rest of this chapter describes the architecture of the Open Applications Group Integration Specifications, Business Object Document (BOD).  The BOD is a common horizontal message architecture. BODs are the business messages or business documents that are exchanged between software applications or components; between companies; across supply chains; and between supply chains. 

In order to do this the BOD must be able to inform the receiving system what kind of message to expect in the data area. Often there is a two-way interaction between a sender and receiver, for this reason, the BOD needs to be able to communicate status and error conditions. It is also necessary to provide for multiple actions on a common business object (Noun). For this reason the OAGIS BODs have been designed to make use of a common Nouns that a given action (Verb) may be applied. As different industries have different needs OAGIS must be extensible in order to allow industry verticals to plug in information that is needed in their industry. For this reason the BODs have been designed to be extensible, while providing a common architecture and content for integration.

The BOD Message Architecture is independent of the communication mechanism. It can be used with simple transport protocols such as HTTP and SMTP but it also can be used in more complex transport protocols such as SOAP, ebXML Transport and Routing, or any other Enterprise Application integration system.

A BOD graphically consists of the following:

These areas are defined as follows:

·        The outermost layer of the BOD identifies the Verb, Noun, revision and runtime environment (Test or Production in which the BOD instance is to be used.)

·        Application Area – Application Area communicates information that can be used by the infrastructure to communicate the message.

·        Data Area – The Data Area carries the business specific payload or data being communicated by the BOD.

·        Verbs – Verb identifies the action being performed on the specific Noun of the BOD.

·        Nouns  - Nouns identify the business specific data that is being communicated (i.e. PurchaseOrder, SalesOrder, Quote, Route, Shipment, etc.) They are comprised of Components, which are described below. Nouns are extensible in order to support the needs of specific vertical industries.

·        Components – Components are extensible building blocks of a Noun (i.e. PurchaseOrder Header, PurchaseOrder Line, Address, etc.). They are comprised of compounds and fields, which are described below. Components are extensible.

·        Compounds – Compounds are basic, shared building blocks that are used by all BODs (i.e. Quantity, Amount, etc.). They are extensible through contextual use but not with additional fields (i.e. OrderedQuantity, ShippedQuantity, BackOrderedQuantity).

·        Fields – Fields are the lowest level elements defined in OAGIS. Fields are fundamental elements that are used to create Compounds and Components. (i.e. Description, Name, etc.).

Note: The graphics within this document are from XML Spy. They are shown here as a way for the reader to visually see the constructs being defined. The Open Applications Group does not recommend individual tools. However, OAGI does recommend using an XML Integrated Development Environment (IDE) when working with complex XML Schema languages like OAGIS.

1.1 Business Object Document

The Verb identifies the action that the Sender application wants the Receiver application to perform on the Noun. OAGIS defines a standard list of Verbs and Nouns that are needed in most supply chain and manufacturing integration scenarios.

The general structure for all of Business Object Documents is shown in the following figure.

For a given Business Object Document, the generic names (BusinessObjectDocument, Verb, Noun) are replaced by specific names (ProcessPurchaseOrder, Process, and PurchaseOrder):

The child elements of a BusinessObjectDocument are:

·        ApplicationArea

·        DataArea.

The ApplicationArea and DataArea separate the application-specific information common to all BODs from the information that is specific to each BOD. Each is discussed in more detail in the following sections

In addition to these child elements, each BOD contains four attributes, the BOD's releaseID, versionID, systemEnvironmentCode, and languageCode.

Release ID

Release ID is used to identify the release of OAGIS that the BOD belongs. For the BODs from OAGIS 9.0 the value of this attribute will be “9.0”. The release ID is a required attribute of the BOD.

Version ID

Version ID is used to identify the version of the Business Object Document.   Each BOD has its own revision number to specifically identify the level of that BOD, not just the release ID of OAGIS. The specific BOD version number is documented in each chapter of OAGIS. The outermost element name no longer includes the version number; it is instead now carried as an attribute of the BOD. The version ID attribute is an optional attribute of the BOD.

System Environment Code

The System Environment Code is used to identify whether this particular BOD is being sent as a result of a test or as production level integration. Often times as new systems are brought online testing must be performed in a production environment in order to ensure integration with existing systems. This attribute allows the integrator to flag these test messages as such. The environment attribute is an optional attribute of the BOD.

Language Code

The languageCode attributes indicates the language of the data being carried in the BOD message. It is possible to override the BOD level language for fields that may need to carry multi-lingual information. Examples of this are Notes and Description.

XML supports only one encoding for an XML message as such the languages carried within a BOD are limited to the set that the XML encoding can support.

1.2 Application Area

The ApplicationArea carries information that an application may need to know in order to communicate in an integration of two or more business applications. The ApplicationArea is used at the applications layer of communication. While the integration frameworks web services and middleware provide the communication layer that OAGIS operates on top of.

As indicated in the graphic below each BOD contains one unique ApplicationArea

The ApplicationArea serves four main purposes:

 

1.      To identify the sender of the message.

2.      To identify when the document was created.

3.      To provide authentication of the sender through the use of a digital signature, if applicable.

4.      To uniquely identify a BOD instance. The BODId field is the Globally Unique Identifier for the BOD instance.

The ApplicationArea is comprised of the following elements:

-        Sender

-        Creation – (date and time)

-        Signature

-        BODID

-        UserArea

Sender

The Sender identifies characteristics and control identifiers that relate to the application that created the Business Object Document.  The sender area can indicate the logical location of the application and/or database server, the application, and the task that was processing to create the BOD.