Message models

The B2Bi trading engine API allows developers access to messages while in process. At several points in a message’s life cycle, message models can effect changes in a message payload or perform some action. Each model provides access to a message's payload and metadata about the message's payload and the context in which the payload was processed.

There are two message model interfaces exposed through the API. These models are similar but have unique qualities because they are accessed from separate APIs. They are:

  • com.cyclonecommerce.api.inlineprocessing.Message
  • com.cyclonecommerce.tradingengine.transport.pluggable.api.PluggableMessage

Message payloads

Message payload models provide access to the payload data of a message. They do not contain the payload itself. Rather, they provide access to the payload stored in a temporary file system directory managed by the application through an abstraction layer called VirtualData. VirtualData provides automatic in-memory caching and some hidden management functions. This indirection enables a much lighter message to be passed between processing services. Additionally, the VirtualData object provides the developer with different ways to access and update message payloads.

A message changes state on its way through the application. Only the current state of the message payload is exposed via the API. Inbound messages are in a packaged state just after being consumed from a partner and a clear-text state as they are sent to integration. So if an in-line processor is configured at the consuming delivery exchange, the message model contains the packaged state of the payload at that point. Subsequently, at the integration delivery point, the message model contains the clear-text (unpackaged) state.

Message metadata

Metadata are data that describe data. With The B2Bi trading engine, metadata are data that describe the payload being processed and the context in which it was processed. Message metadata control the processing applied to a message and its eventual routing. There is a finite set of application-defined metadata items. Software developers and application administrators can define additional arbitrary metadata items. These items could be used to alter the flow of control or provide additional information to custom processing.

Once associated with a message via the message model, the metadata are persisted with the message. For example, the consumption timestamp marks when a message was consumed by the system for processing. This is a piece of metadata that describes the context in which the message was processed. This information is now available to all APIs that have access to that message.

There are a finite set of application-defined metadata items described by two Java interfaces:

  • com.cyclonecommerce.collaboration.metadataDictionary
  • com.cyclonecommerce.webservices.collaboration.ebxml.EbxmlMetadataDictionary

Not all metadata items are present in all routing scenarios. Verify the presence of the information you expect for your routing scenarios before starting any development.

In addition to predefined metadata items, software developers and application administrators can add arbitrary metadata items through the API or user interface. Regardless of where defined, all metadata for a message are persisted to the same message and exposed by the same message model. This means that metadata defined by one source can be accessed from another.

The following are where metadata can be added to a message:

  • Application-defined items populated by default as a message is processed (for example, parsing).
  • Consumer exchange point user interface (for example, delivery exchange and integration pickup).
  • Message Handler user interface.
  • Pluggable transport API.
  • In-line processing API (exchange point and Message Handler varieties).

Related Links