Modeling Connections 

Sequences

A sequence is a connection between two subsequent actions within an application component. A sequence is represented by a vertical downward-pointing arrow.

·        You use a sequence if the execution of the first action is the prerequisite for the second action being executed.

·        You can also use a sequence to define the sequence of inbound processing during asynchronous communication.

Designing Synchronous and Asynchronous Communication Steps

When designing your Business Scenario, you must pay particular attention to the exchange of information between the application components involved.

Note the following:

·        Identify all instances in your Business Scenario where information must be exchanged between the components by using messages. This also includes communication steps.

·        Define whether messages are to be exchanged synchronously or asynchronously.

¡        Synchronous communication means that the sender waits for a response from the receiver before proceeding with processing.

¡        Asynchronous communication means that the sender does not expect an immediate response from the receiver and therefore proceeds with processing immediately.

In extensive Business Scenarios, you should, where possible, always work with asynchronous communication. As a result, your Business Scenarios will be more robust and reliable.

·        Depending on whether you select synchronous or asynchronous, identify the interfaces you require for communication. If they do not already exist, you must define them in the Integration Builder designer. Ensure that the properties of the interfaces (outbound/inbound, synchronous/asynchronous) correspond to your design.

Representing Communication Steps in the Business Scenario

You must reproduce the decisions you make at design time in the Business Scenario graphic of the Integration Builder.

Note the following aspects:

·        Each message exchange must be represented in the Business Scenario by a connection between the corresponding actions.

Note that this also referred to as a type level. For example, if a communication step is used more than once, but involves the same action and interfaces each time, then this is represented by just one connection.

For example, in the Book a Flight Trip Business Scenarios example, the action Search for Flight Connection is executed repeatedly until an appropriate flight connection has been found. This action queries flight availability at the various airlines. All these communication steps are however of the same type and can therefore be represented by just one connection.

·        Define synchronous or asynchronous connections as per your design.

¡        A synchronous connection is represented by a horizontal double-headed arrow. Both actions must be on the same level in the graphic.

¡        An asynchronous connection is represented by a downward-pointing arrow. The target action must be on a lower level than the source action in the Business Scenario graphic.

The Business Scenario design environment uses the relative position of the two actions in the graphic to automatically define the communication type. Therefore, ensure that the actions are in the correct order in the graphic.

See the Business Scenario example Book a Flight Trip. The connection between the actions Search for Flight Trip and Determine Flight Availability is synchronous. The connection between Book Flight Trip and Book Single Flight is asynchronous.

·        Complete the specifications for the connection by selecting the outbound and inbound interfaces to be used for exchanging messages. If required, select a mapping to be executed for this mapping.

·        If there are different alternatives as to which interfaces and mappings you can use for exchanging messages, then model each of the alternatives as a separate connection.

·        If more than one connection exists between two actions, then these must be alternatives. At configuration time, you can only select one connection for each sender/receiver relation.

·        Note the following rules regarding the sequence of communication steps that are to be processed by an action:

¡        Inbound communication steps always come before outbound communication steps chronologically.

¡        If more than one inbound communication step exists, then no order is defined between them.

¡        If more than one outbound communication step exists, then no order is defined between them.

¡        “No order defined” means that the order is unknown and is therefore not relevant.

If an application case occurs that conflicts with the rules above, then you must model your connection differently. A solution might be to divide the action concerned into two (or more) actions.

Start and End Actions

The purpose of start and end actions is on the one hand, to improve clarity for the user, and on the other, to specify possible points for a mapping to take place.

·        A start point can be any action from which the Business Scenario can begin. It is possible to have more than one start point.

·        An end point is an action where the Business Scenario comes to a logical business conclusion. It is possible to have more than one end point.

·        If you define a start point, it must be at the start of its application component. Likewise, an end point must be at the end of its application component.