Dear SCN forum members,

I would like to share some of my thoughts on integration patterns, which I have come across in my 15+ years of integration experience in architecture. As an Enterprise Architect involved in transcending the simple goal of linking applications, and enabling new ann innovative ways of leveraging, I have had the chance to explore the below patterns.

Below is a list of all defined interface patterns, irrespective of what middleware tool we use. This serves as the list of patterns for integration between applications for the majority of the interfaces.

Pattern Numbers

Name

Characteristics

   1

Source Standard Interface (event driven)

  • Real-Time from source to middleware
  • No response sent back from middleware
    2

Source Standard Interface (batch)

  • Batch from source to middleware
  • No response sent back from middleware
    3

Source Asynchronous Request Reply (event driven)

  • Real-Time from source to middleware
  • Non-immediate response from middleware
  • (Any responses sent back from target system are considered a separate interface)
    4

Source Asynchronous Request Reply (batch)

  • Batch from source to middleware
  • Non-immediate response from middleware
  • (Any responses sent back from target system are considered a separate interface)
    5

Source Synchronous Request Reply (event driven)

  • Real-Time from source to middleware
  • Immediate response from middleware
    6

Source Synchronous Request Reply (batch)

  • Batch from source to middleware
  • Immediate response from middleware
    7

Target Standard Interface (event driven)

  • Real-Time from middleware to target
  • No response sent back from target
    8

Target Standard Interface (batch)

  • Batch from middleware to target
  • Individual transactions are combined into a batch
  • Scheduler sends batch to target
  • No response sent back from target
    9

Target Asynchronous Request Reply (event driven)

  • Real-Time from middleware to target
  • Non-immediate response from target
  • (Any responses sent back from target system are considered a separate interface)
    10

Target Asynchronous Request Reply (batch)

  • Batch from middleware to target
  • Individual transactions are combined into a batch
  • Scheduler sends batch to target
  • Non-immediate response from target
  • (Any responses sent back from target system are considered a separate interface)
    11

Target Synchronous Request Reply (event driven)

  • Real-Time from middleware to target
  • Immediate response from target
    12

Target Synchronous Request Reply (batch)

  • Batch from middleware to target
  • Individual transactions are combined into a batch
  • Scheduler sends batch to target
  • Immediate response from target
    13

Point-to-Point Standard Interface (source=event driven, target=event driven)

  • Data is going to only one target system for the life of the business object
  • Real-Time from source to target
  • No response sent back from target
    14

Point-to-Point Standard Interface (source=batch, target=event driven)

  • Data is going to only one target system for the life of the business object
  • Batch from source to middleware
  • Event from middleware to target
  • The unit of work can be the entire batch (I.e. if one transaction fails the entire batch needs to fail – common in financial transactions)
  • The unit of work can be each individual transaction
  • No response sent back from target
    15

Point-to-Point Standard Interface (source=event driven, target=batch)

  • Data is going to only one target system for the life of the business object
  • Event from source to middleware
  • Batch from middleware to target
  • The unit of work can be the entire batch (I.e. if one transaction fails the entire batch needs to fail – common in financial transactions)
  • The unit of work can be each individual transaction
  • No response sent back from target
    16

Point-to-Point Standard Interface (source=batch, target=batch)

  • Data is going to only one target system for the life of the business object
  • Batch from source to middleware
  • Batch from middleware to target
  • The unit of work can be the entire batch (I.e. if one transaction fails the entire batch needs to fail – common in financial transactions)
  • The unit of work can be each individual transaction
  • No response sent back from target
    17

Point-to-Point Asynchronous Request Reply (source=event driven, target=event driven)

  • Data is going to only one target system for the life of the business object.
  • Real-Time from source to target
  • Non-immediate response sent back from target
    18

Point-to-Point Asynchronous Request Reply (source=batch, target=event driven)

  • Data is going to only one target system for the life of the business object
  • Batch from source to middleware
  • Event from middleware to target
  • The unit of work can be the entire batch (I.e. if one transaction fails the entire batch needs to fail – common in financial transactions)
  • The unit of work can be each individual transaction
  • Non-immediate response sent back from target
    19

Point-to-Point Asynchronous Request Reply (source=event driven, target=batch)

  • Data is going to only one target system for the life of the business object
  • Event from source to middleware
  • Batch from middleware to target
  • The unit of work can be the entire batch (I.e. if one transaction fails the entire batch needs to fail – common in financial transactions)
  • The unit of work can be each individual transaction
  • Non-immediate response sent back from target
    20

Point-to-Point Asynchronous Request Reply (source=batch, target=batch)

  • Data is going to only one target system for the life of the business object
  • Batch from source to middleware
  • Batch from middleware to target
  • The unit of work can be the entire batch (I.e. if one transaction fails the entire batch needs to fail – common in financial transactions)
  • The unit of work can be each individual transaction
  • Non-immediate response sent back from target
    21

Point-to-Point Synchronous Request Reply (event driven)

  • Data is going to only one target system for the life of the business object
  • Real-Time from source to target
  • Immediate response sent back from target
    22

Point-to-Point Synchronous Request Reply (batch)

  • Data is going to only one target system for the life of the business object
  • Batch from source to middleware
  • Batch from middleware to target
  • The unit of work can be the entire batch (I.e. if one transaction fails the entire batch needs to fail – common in financial transactions)
  • Immediate response sent back from target

Integration Patterns – Part B :

Integration Patterns – Part

The goal of the blog is to help users to make aware of the Integration Patterns, recommendations are based on my personal experience in SAP Implementation as an SAP employee and technical architect.The user can follow the suggestions provided by the blog and it should supplement with additional information,the suggestion provided by the blog might vary as per the project requirement.

SAP Help, at http://help.sap.com, provides official documentation from SAP. It is structured help that is indexed and includes diagrams to illustrate key points. This site is open to the public; no login information is required.

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Iñaki Vila

    Hi,

    Great contributtion!, thank you very much indeed for share you experience, 22 pattern cases!. I read your second blog with the specifical cases and the make decision table, it will be very helpful for me. I will apreciatte so much a third blog with a real cases like “One company with this infraestructure wants to…” in order i can check if i understand right your blogs and it could be a great exercise to improve my skills.

    Regards.

    (0) 

Leave a Reply