Cost-Based Optimization of Integration Flows - Datenbanken ...
Cost-Based Optimization of Integration Flows - Datenbanken ...
Cost-Based Optimization of Integration Flows - Datenbanken ...
- No tags were found...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
2.4 Use Cases<br />
message) is used. The Join operator (o 4 ) merges the result message with the received<br />
message (with the customer key as join predicate). Finally, an Assign operator (o 5 ) and<br />
an Invoke operator (o 6 ) are used to sent the join result to system s 3 (ERP system).<br />
Example 2.6 (Material Inventory Update). The ERP system is the leading information<br />
system in our example scenario. Hence, the current material inventory is periodically<br />
updated within the ERP system. Therefore, the integration flow (plan P 3 ) that is shown<br />
in Figure 2.9(c) is periodically executed. Essentially, this plan specifies that after a query<br />
has been prepared, the external systems s 1 (SCM system) and s 2 (Material system) are<br />
queried. The result sets are joined (o 4 ) and aggregated (o 5 ) per material. Finally, the<br />
aggregated material inventory is sent to the ERP system s 3 .<br />
Example 2.7 (Product <strong>Cost</strong> Estimate). Using the eCommerce Web shop, a customer<br />
can order user-defined products. Therefore, one can pose a cost estimate bid. In order<br />
to answer such a cost estimate bid, data from several operational systems is required.<br />
Therefore, the synchronous integration flow (plan P 4 ) shown in Figure 2.10 is used.<br />
Receive (o1)<br />
[service: s5, out: msg1]<br />
Assign (o2)<br />
[in: msg1, out: msg2]<br />
Invoke (o3)<br />
[service s3, in: msg2, out: msg3]<br />
Translation (o4)<br />
[in: msg3, out: msg4]<br />
Join (o5)<br />
[in: msg1,msg4, out: msg5]<br />
LEFT OUTER<br />
A1_Productkey>0<br />
Switch (o6)<br />
[in: msg5]<br />
Assign (o7)<br />
[in: msg5, out: msg6]<br />
Invoke (o8)<br />
[service s1, in: msg6, out: msg7]<br />
Assign (o10)<br />
[in: msg5, out: msg6]<br />
Invoke (o11)<br />
[service s2, in: msg6, out: msg7]<br />
Join (o9)<br />
[in: msg5,msg7, out: msg9]<br />
INNER<br />
A1_Productkey<br />
> 9000000<br />
Join (o13)<br />
[in: msg5,msg7, out: msg8]<br />
Switch (o12)<br />
[in: msg7]<br />
INNER<br />
INNER<br />
Join (o14)<br />
[in: msg5,msg7, out: msg8]<br />
Assign (o15)<br />
[in: msg8, out: msg9]<br />
Reply (o16)<br />
[in: msg9]<br />
Figure 2.10: Example <strong>Integration</strong> Flow – Plan P 4<br />
We receive a message from the external system s 5 (eCommerce). Subsequently, we query<br />
the ERP system in order to determine if this user-defined product has already been sold. If<br />
this is the case, we query the SCM system and join those possible products with the basic<br />
information. Otherwise, we query the Material system in order to determine the costs <strong>of</strong><br />
a newly created product. Finally, we prepare the answer in the sense <strong>of</strong> a cost estimate<br />
and send a reply message to the customer (who was blocked during execution).<br />
To summarize, the plans P 1 , P 2 , and P 4 are data-driven integration flows, while the<br />
plan P 3 is a periodically (time-based) initiated integration flow. Furthermore, the plans<br />
P 1 , P 2 , and P 3 are executed asynchronously (where for P 1 and P 2 inbound queues are<br />
used), while the plan P 4 is executed synchronously (where the client system is blocked).<br />
29