Inbound Message Processing

An inbound message refers to the transmission of data from external systems to the master index database. These messages can be sent into the database via a number of web services. Inbound messages can be stored in journal files and tracked in the log files. The steps below describe how inbound messages are processed.

1. Messages are created in an external system, and the message is transmitted to the Enterprise Service Bus (ESB) via that system's binding service.

2. The ESB identifies the message and the appropriate process to which the message should be sent. The message is then routed for processing.

3. The message is modified into the appropriate format for the master index database, and validations are performed against the data elements of the message to ensure accurate delivery. The message is typically validated using the business process logic and other information stored in the master index configuration files.

4. If the message was successfully transmitted to the database, the appropriate changes to the database are processed.

5. After the master index application processes the message, an enterprise-wide universal identifier (EUID) is returned (for a new or updated record). That EUID can be sent back out through a different web service to the external system. Alternatively, the entire updated message can be published using the generated outbound message (see Outbound Message Processing).

Figure 2 below illustrates the flow of a message inbound to an Oracle Java CAPS Master Index application.

Figure 2 Inbound Message Processing Data Flow

About Inbound Messages

The format for the bulk of the inbound message is defined by the object structure of the master index, located in the object.xml configuration file. The inbound messages can either conform to the required format for the master index application, or they can be mapped to the correct format in a business process.

In addition to the objects and fields defined in object.xml, you can include standard master index application fields. For example, you must include the system and local ID fields, and you can also include transaction information, such as the date and time of the transaction, the transaction type, user ID, and so on. Transaction fields include the following:

• Message Id

• EventTypeCode

• UserId

• AssigningSystem

• Source

• Department

• TerminalId

• DateOfEvent

• TimeOfEvent

  If you do not send these fields into the master index application, default values are used (for example, the date and time fields default to the date and time the transaction is processed by the master index application).