25.01.2015 Views

Cost-Based Optimization of Integration Flows - Datenbanken ...

Cost-Based Optimization of Integration Flows - Datenbanken ...

Cost-Based Optimization of Integration Flows - Datenbanken ...

SHOW MORE
SHOW LESS
  • 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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!