Open Framework, Information Management Strategy & Collaborative Governance | Data & Social Methodology - MIKE2.0 Methodology
Wiki Home
Collapse Expand Close

Collapse Expand Close

To join, please contact us.

Improve MIKE 2.0
Collapse Expand Close
Need somewhere to start? How about the most wanted pages; or the pages we know need more work; or even the stub that somebody else has started, but hasn't been able to finish. Or create a ticket for any issues you have found.

Architecture Patterns for Partner-to-Partner Integration

From MIKE2.0 Methodology

Jump to: navigation, search

Architecture Patterns for Partner-to-Partner Integration describe how different components in the SAFE Architecture interact to solve a general set of problems for automating a set of manual business processes.

= The Problem and its Symptoms

Businesses do not exist in a vacuum. Likewise, internal business systems cannot exist and operate in the absence of a wider system context. They must naturally extend beyond the internal boundaries of the organisation to interact with partner systems and applications, exchanging information and collaborating in cross boundary business processes. This is the essence of Partner to Partner Integration.

Partner to Partner Integration has the same characteristics as the Distributed Business Process Automation pattern—but extends the distance and latency between collaborating systems beyond the corporate firewall. That “distance” and “latency” extends also to the semantic gulf that exists between the organisation and its external partner systems. By virtue of being external systems, there is little control or influence over the application design, data quality and operational security of those systems.

The typical symptoms of poor or inadequate Partner to Partner Integration are:

  • Disconnection of the supply chain at the corporate boundary interface (between an organisation and a business partner) which must be reconciled through ad hoc manual processes.
  • Extreme time lag and delay between a business event originating in one partner’s systems and the fulfilment of that event in the corresponding partner’s systems.
  • Multiple point to point batch interface files exchanged between partner organisations, each with unique file formats and processing  windows.

Separate integration mechanisms for external versus internal system integration requirements. comparer forfait rio b and you portabilité calcul IMC rio orange

Design Pattern for Partner-to-Partner Integration

The Partner to Partner Integration design pattern epitomises the concept of loose coupling between interacting systems. There is never any direct application to application connectivity between partner systems across organisational boundaries. All integration is conducted “at arms length” through agreed inter organisational message exchange protocols and standards. This obviates the need for any direct knowledge of the other partner’s systems by either collaborating partner.</span>

The pattern emphasises asynchronous communication between partners to strengthen the loose coupling concept. Thus, there is no temporal coupling between a request for a Business Service by one partner and the fulfilment of that Business Service by the other partner.</span>

Asynchronous communication is characterised by “fire and forget” message exchange. The initiating application assumes guaranteed delivery of its message, handled by a reliable messaging system, and continues its thread of execution without waiting for a synchronous response from the partner system. This mode of communication is appropriate for single transactions, batches of multiple transaction and even process oriented, conversational exchanges between partners.</span>

A central (logical) integration broker or “hub” provides the concentration point for all integration activity, both with external partner systems as well as intra-organisation integration between internal systems. This pattern builds upon the Distributed Business Process Automation Pattern, hence, the details of that pattern are assumed and not repeated in the schematic. Instead, only the important abstractions specific to this pattern are highlighted and described below.</span>

Trading partner integration architecture design pattern.jpg
  1. An event occurs within an external partner application that results in an invocation of a Service Requester adapter interface. A Business Service request message is formed using data extracted from the external partner system and has an associated “Transaction ID”. The message conforms to an agreed format established between the organisation and its external partner.
  2. The Business Service request message transits the partner organisation’s network boundary, through its firewall, across an intervening shared network infrastructure (possibly the public Internet, or a private extranet), through the firewall and to a publicly published Business Service interface. The network transport layer is responsible for ensuring confidentiality and integrity of the message and its data payload during transit between organisation boundaries.
  3. Business Service interfaces are accessible to internal and external callers, thus allowing a single Integration Broker to act as a logically centralised integration point for internal and external systems alike.
  4. The Integration Broker receives the Business Service request message through the public interface and marshals its contents into an internal canonical message format. Business Service interface logic determines the precise processing steps for the received message:
    1. The message may represent a single transaction, or a batch of multiple transactions. A message splitter de aggregates a batch message into its constituent transactions for further downstream processing.
    2. The message may require workflow managed processing of multi step business process automation and human workflow interaction. A workflow process will be instantiated from a “process template” selected on the basis of the message content.
    3. A message router will reroute the message (or messages) to one or more internal application end points for final processing.
  5. Adapters to internal applications accept routed messages (or message elements) and allow the appropriate stream of API calls to be made to the application.
  6. The return of information from the invoked internal application, back to the original external partner system, is complicated by the asynchronous nature of the message communication.
    1. Request specific responses require a “Correlation ID” (distinct from the “Transaction ID”, as there could be multiple asynchronous outbound responses for a single inbound request) to accompany any message returned to the external partner system. The “Correlation IDs” must be generated by the calling partner system and held in a persistent store for future correlation.
    2. In some instances, the “response” by the internal system is the invocation of a “reverse” Business Service exposed by the external partner system. The internal application invokes a Business Service exposed by the Integration Broker which delegates the call to the external partner system for handling.
  7. The external partner system receives the response message from its peer. The “Correlation ID” is inspected and an attempt is made to “correlate” this response against a list of responses the external partner system is expecting to receive. If correlation is successful, the expected is response is handled as normal processing, otherwise an “Unexpected Response” exception is thrown and the message rejected (and possibly rerouted to the Integration Broker).

This pattern applies to integration of a “one to many” nature between external partners, and in both directions (i.e. initiated by one external partner system or one internal system). The Integration Broker is responsible for coordinating the “many” side of the integration with one or more external partner systems.

Conversational (dialogue) style exchanges between partner systems should be handled by state driven workflow models executing within the Integration Broker. The workflow models within the Integration Broker allow for long lived, multi part exchanges between systems. Request messages serve as “event stimuli” that trigger the next transition in the workflow model’s state (see illustration below).

Wiki Contributors
Collapse Expand Close

View more contributors