Dialog chaining and nesting DCX keys and event mappers
In context of dialog chaining or nesting, DCX keys and mappers never influence another dialogs DCX segment. When a transition part of a calling dialog uses a DCX key or a mapper it influences only the data that is stored in the calling dialog's DCX segment and not the called dialog's segment. Similarly, when a transition part of a called dialog uses a DCX key or a mapper it influences only the data that is stored in the called dialog's DCX segment and not the calling dialog's segment.
Use of DCX keys and mappers in dialog chaining or dialog nesting is required to properly exchange data between the calling and called dialogs. In many cases, called dialogs are developed independently from calling dialogs, not intended to be part of another dialog.
For example, consider a travel booking screen flow. It consists of steps that allow to book a flight, a hotel, and a car after a particular date of travel, and destination is specified. Before the agent can start booking, the customer's personal data needs to be collected. Assume that another screen flow, a billing screen flow, is already modeled which allows the agent to look up this data through a customer ID. Thus the entire flow requires the booking to be started, the personal data to be collected and updated and finally the actual bookings to be done.
travellerID
to be the
blue screen flow. Assume the billing screen flow that
carries the customer information under the key customerID
to be the red screen flow. - During step 1, the
travellerID
is specified along with the date of travel, and destination. The red screen flow is started in a nested fashion. - During step 2, the red screen flow is supposed to display the customer information such as name, and address.
- During step 3, the red screen flow must allow for
updating the customer information. The red screen flow
needs to be fed with the
travellerID
but expects it to be sent with an event withQName customerID
. - The entire set of customer information such as name, and address, is
packaged in a special customer object. This customer object is emitted by
the red screen flow's end transition under the key
customerBean
. - The blue screen flow requires this data but expects it
to be sent by an event with
QName travellerBean
. ThetravellerID
needs to be converted tocustomerID
andtravellerBean
tocustomerBean
.
The following code sample shows an option to convert the event Qnames
. The outgoing transition responsible for calling
the red dialog assigned the attribute dcx-key
with value customerID
to the
event element associated with this transition's source transition endpoint. Thus,
even though the transition endpoint step_1 emits an event with QName travellerID
, the information is stored in
the blue dialog's DCX under the key customerID
. Thus it can be sent to the red dialog
through an event with QName customerID
as the
corresponding payload can be found in the blue dialog's DCX
under exactly that key. The blue dialog's incoming transition
receives the customer information through an event with QName
customerBean
, but stores the corresponding payload under the key
travellerBean
. Thus the customer information can
be propagated with events with QName travellerBean
as the corresponding payload can be found in the blue dialog's
DCX under exactly that name.
<dialog name="dialog blue">
...
<transition type="nested">
<source>
<transition-endpoint nameref="step_1">
<event qname="travellerID" dcx-key="customerID"/>
</transition-endpoint>
</source>
<target>
<transition-endpoint nameref="dialog red">
<event qname="customerID"/>
</transition-endpoint>
</target>
</transition>
...
<transition>
<source>
<transition-endpoint nameref="dialog red">
<event qname="customerBean" dcx-key="travellerBean"/>
</transition-endpoint>
</source>
<target>
<transition-endpoint nameref="step 4">
<event qname="travellerBean"/>
</transition-endpoint>
</target>
</transition>
...
</dialog>
...
<dialog name="dialog red">
...
<transition type="start">
<source>
<transition-endpoint nameref="...">
<event qname="customerID"/>
</transition-endpoint>
</source>
<target>
<transition-endpoint nameref="step_2">
<event qname="customerID"/>
</transition-endpoint>
</target>
</transition>
...
<transition type="end">
<source>
<transition-endpoint nameref="step 3">
<event qname="customerBean"/>
</transition-endpoint>
</source>
<target>
<transition-endpoint nameref="PAGE ORIGIN">
<event qname="customerBean"/>
</transition-endpoint>
</target>
</transition>
...
</dialog>
...
</dialog>
Assume the screen flow that carries the customer information under
the key travellerID
to be the
blue screen flow. Assume the screen flow that carries the
customer information under the key customerID
to be
the red screen flow. Assume the travellerID
is of type string
while
the customerID
is of type Integer
. Also, assume that the beans travellerBean
and customerBean
differ not only by name but are also of different object type.
The following code sample shows an option to convert the keys and the bean. The mappers ensure that the events are properly renamed and the data types are properly transformed.
<dialog name="dialog blue">
...
<transition type="nested">
<source>
<transition-endpoint nameref="step 1">
<event qname="travellerID" mapper-class="B2RMapper"/>
</transition-endpoint>
</source>
<target>
<transition-endpoint nameref="dialog red">
<event qname="customerID"/>
</transition-endpoint>
</target>
</transition>
...
<transition>
<source>
<transition-endpoint nameref="dialog red">
<event qname="customerBean" mapper-class="R2BMapper"/>
</transition-endpoint>
</source>
<target>
<transition-endpoint nameref="step 4">
<event qname="travellerBean"/>
</transition-endpoint>
</target>
</transition>
...
</dialog>
...
<dialog name="dialog red">
...
<transition type="start">
<source>
<transition-endpoint nameref="...">
<event qname="customerID"/>
</transition-endpoint>
</source>
<target>
<transition-endpoint nameref="step_2">
<event qname="customerID"/>
</transition-endpoint>
</target>
</transition>
...
<transition type="end">
<source>
<transition-endpoint nameref="step 3">
<event qname="customerBean"/>
</transition-endpoint>
</source>
<target>
<transition-endpoint nameref="PAGE ORIGIN">
<event qname="customerBean"/>
</transition-endpoint>
</target>
</transition>
...
</dialog>
...
</dialog>