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 integration scenario, you must pay particular attention to the exchange of information between the application components involved.
Note the following:
· Identify all instances in your integration 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 integration scenarios, you should, where possible, always work with asynchronous communication. As a result, your integration 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 (design tool). Ensure that the properties of the interfaces (outbound/inbound, synchronous/asynchronous) correspond to your design.
Representing Communication Steps in the Integration Scenario
You must reproduce the decisions you make at design time in the integration scenario graphic of the Integration Builder.
Note the following aspects:
· Each message exchange must be represented in the integration 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.
· 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 integration scenario graphic.
The integration 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, as per the guidelines above.
In the demo example Checking Flight Seat Availability, the connection between the actions Check Flight Seat Availability and Determine Flight Seat Availability is synchronous. In the demo example Booking a Single Flight, the connection between the actions Send Single Flight Booking Order and Book Single Flight And Confirm 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 connection.
· 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 action can be any action from which an integration scenario can begin. It is possible to have more than one start point.
· An end action can be any action, which brings an integration scenario to a logical business conclusion. It is possible to have more than one end action.
· If an action is classified as a start action, you must position it at the start of your application component. Likewise, an end action must be positioned at the end of your application component.
No comments:
Post a Comment