1. Integration Guide
  2. Processing Overview

Processing Overview

On receipt of a Transmission XML, the integration application module performs the following steps. Note that authentication and authorization will already have been performed in a protocol specific way before the message is passed to the module:

  1. Parse and validate Transmission XML according to schemas, generate a new unique Transmission Number and persist records in the I_TRANSMISSION and I_TRANSACTION tables for this transmission number.
  2. Depending on transport protocol used, and if requested, create a TransmissionAck XML message and return to the sender. Schema validation errors will be returned at this time.
  3. An event is staged in the inbound integration data queue which will be the default or override queue specified in the incoming message. When the event is polled by a data queue poller the message is then placed on the internal Integration Workflow in-memory queue. See the Integration Data Queues chapter for more details on data queue configuration.
  4. The Integration Workflow retrieves the message from the internal queue and:
    1. Determines any grouping or sequencing constraints
    2. Submits group(s) to Mediator for processing.
  5. When the Mediator selects a group for processing, it will process each Transaction in the group as follows:
    1. If extended validation is configured the integration module validates the following:
      1. Foreign keys, for example a Location GID must exist in the Location table.
      2. Data Types, for example a number only contains numeric characters.
      3. TransactionCode. If set to I, the integration module checks that the primary key does not exist. If set to U or D, the integration module checks that the primary key does exist.
      4. Required Elements are not NULL.
    2. Saves any validation errors.
    3. If there are no validation errors or if extended validation was not configured, the corresponding business object is populated with the data from the XML and passed to the persistence module.
    4. If there are agents listening for pre-persist events, the persistence module triggers those now. An example of this is the public Order Base - Insert agent for TransOrder transmissions.
    5. The business objects are now persisted to the corresponding database tables. If extended validation had not been configured all integrity constraints are now checked and any violations would cause the transaction to fail.
    6. If there are agents listening for post-persist events, the persistence module triggers those.
  6. When the Mediator has processed all transactions for all groups in a Transmission the Transmission processing is complete. The completion process optionally sends a TransmissionReport with validation and processing errors. See AckSpec for details.
Note: The Transmission Report is only physically transmitted when all workflow that is considered to be part of the Transmission Process has completed (known as "child" processes). If there is a significant amount of agent workflow configured this could appear as a delay in delivering the report. If this is an issue it may be worth considering the use of customer-defined events with the "Create New Process" option selected.