Database Reference
In-Depth Information
DELETE FOR ALL ports in the voyage for previous condition if re-
moved
POD was the last port in the TP's area of interest, which means that the voyage
had one POL and one POD. Two messages should be provided in this case: one
for single port and the other for the entire voyage.
• Deleting a port call from the voyage using DELETE on the TP side for one or
more voyages in the list.
You can see from the analysis of the preceding operation that updating the port call in-
formation is the most complex task and requires historical retrospective. The Event Pro-
cessor (such as Rule Engine (RE), for instance) will need to have information about the
previous ports in voyages to make the decision regarding using Insert , Update , or
Delete operations provided in Message Header to TP. The Insert and Delete oper-
ations do not reflect physical operations on the BA side. As long as the message body
provided by TP cannot contain new and old information at the same time, previous in-
formation about the key values must be provided in the Message Header's Object Context
part. This fact was explained in Chapter 5 , Maintaining the Core - the Service Repository ,
dedicated to metadata taxonomy, where we linked ESR taxonomy to the message struc-
ture.
The preceding realization can be physically presented as a two-level rule. Here, we have a
conjunction of a single entity with disjunctions.
<root> voyage must have POL1[and]
<level one> POD must be in PODn1,PODn2…PODm1,PODm2
For the second use case, we have additional realization requirements, as follows:
• The number of keys needed for resolving TP can be more than one.
• To be effective, RE (if we use Rule Engine) should execute as many rules as pos-
sible in one go. It can be achieved by:
◦ Using an effective cost-based parsing ruleset and indexes.
◦ Reducing the number of rules applied to one complex event pattern.
◦ Composite events signatures can be invoked. Signature composition.
• Rules' tasks (or references to the tasks) and expected values should be stored in
ESR ruleset tables. Consequently, they can be part of the execution plan, but the
performance could be affected. Furthermore, we will see how CQL could address
this issue.
Search WWH ::




Custom Search