Depending on which parameters should take precedence, configuration parameters or ones from Process Data, you can switch between 'Obtain Process Data first, then Message' or ' Obtain Message first, then Process Data'. You can use assign element to put something into Process Data that will be read by a service, if the configuration parameter of the service has the same name as the element in the Process Data, depending on the option chosen for the Output Message, you can tell the service which parameter will be taken.
As Process Data accumulates all the information from the whole business process, you can always find many element that you have not configured at all and that also are not present in GPM or GIS configuration. So, it is possible to happen that a service somewhere in a business process put something in the Process Data that another service placed afterwards will read, and that you will probably be not aware of. It is always a good practice to look into every step in a process and see what has added in Process Data by services or adapters, information added in Process Data could be used/read by other services by intention or completely unexpectedly.
Example 1:
One simple example that can show the usage of Output Message
We have very simple business process in which we define 'map_name' in Process Data by using assign element:
<process name="default">
<sequence>
<assign to="map_name">mapName_doesNotExistInGIS</assign>
<operation name="Translation">
<participant name="Translation"/>
<output message="TranslationTypeInputMessage">
<assign to="map_name">mapName_existsInGIS</assign>
<assign to="." from="*"/>
</output>
<input message="inmsg">
<assign to="." from="*"/>
</input>
</operation>
</sequence>
</process>
In this case we have map_name in the Process Data as well as in the Output Message (service parameter).
If we use option 'Obtain Message first, then Process Data', map from the Process Data with the name mapName_doesNotExistInGIS will be taken by Translation Service. As this map does not exist in GIS you will get an error that 'The map object cannot be located'. We see that although map_name configured for the Translation service, in an output message, exists in a GIS, Translation Service will take the one defined in Process Data.
If we use option 'Obtain Process Data first, then Message', map from the Message with the name mapName_existsInGIS will be taken and translation service will translate a Primary Document by this map.
If we use option 'Messages Only', map object will be found, but as Translation service works on Primary Document that cannot be read from Process Data, you will get an error that 'A Primary Document is required'.
Example 2:
Here is an example in which you have to see how one service can put something into Process Data that can have repercussion on another service.
- We configure B2B Mail Client Adapter to receive a mail from a mail server and run a BP after receiving a mail.
- Presume we want to receive raw mail message in MIME format with all the headers. For that case we will chose option 'Send raw message' to Yes.
- It is format that can be easily parsable by Mail Mime Service. So body of mail will be put into Primary Document and all the attachments are placed in separate documents in Process Document area after mail is parsed by Mail Mime Service.
- Process that is run by B2B Mail Mime Service looks like as follows:
<process name="UF_mailMimeParse">
<sequence name="Sequence Start">
<sequence name="parseMail">
<operation name="Mail Mime Service">
<participant name="MailMimeService"/>
<output message="MailMimeServiceInputMessage">
<assign to="mail-mime-operation">parse</assign>
<assign to="parse">true</assign>
<assign to="." from="*"/>
</output>
<input message="inmsg">
<assign to="." from="*"/>
</input>
</operation>
</sequence>
<assign name="Assign" to="temp">tempContent</assign>
<!-- here, it can be placed anything you want -->
<sequence name="sendMail">
<operation name="SMTP Send Adapter">
<participant name="SMTP_SEND_ADAPTER"/>
<output message="SMTP_SEND_ADAPTERInputMessage">
<assign to="b2b-raw-message">false</assign>
<assign to="xport-smtp-mailfrom">from</assign>
<assign to="xport-smtp-mailhost">mailHost</assign>
<assign to="xport-smtp-mailport">25</assign>
<assign to="xport-smtp-mailsubject">subject</assign>
<assign to="xport-smtp-mailto">mailAddress</assign>
<assign to="." from="*"/>
</output>
<input message="inmsg">
<assign to="." from="*"/>
</input>
</operation>
</sequence>
</sequence>
</process>
When B2B Mail Client Adapter pull a mail from a mail server and start this BP, in the Process Data in initiating context you can find:
<ProcessData>
<PrimaryDocument SCIObjectID=" serverName:49b61c40:1102f7e087e:-3420"/>
<Mail_Client>
<Headers>
...........
</Headers>
</Mail_Client>
<b2b-protocol>smtp</b2b-protocol>
<b2b-raw-message>true</b2b-raw-message>
</ProcessData>
We can see that B2B Mail Client Adapter placed 'b2b-raw-message' element in the Process Data. It is the same parameter name as the one that SMTP Send Adapter uses. As mail for sending is not built by Mail Mime Service we want to send only Primary Document in the body of mail, so SMTP Send Adapter does not expect MIME message. Although 'b2b-raw-message' is set to false for SMTP Send Adapter, mail will not be sent if the Output Message is 'Message first, then Process Data', because this parameter is read from the Process Data, and we can see it is set to true. SMTP Send Adapter will not send the mail.
If we switch Output Message to 'Obtain Process Data first, then Message', mail will be sent because 'b2b-raw-message' from Process Data will be overriden by the configuration parameter of SMTP Send Adapter sent to the adapter in Output Message.
As we know the 'b2b-raw-message' created in the Process Data, in the beginning by B2B Mail Client Adapter, can cause problem for SMTP Send Adapter we can take care of Output Message Mode, or we can simply release this element by the Release Service somewhere before SMTP Send Adapter:
<operation name="Release Service">
<participant name="ReleaseService"/>
<output message="ReleaseServiceTypeInputMessage">
<assign to="TARGET">b2b-raw-message</assign>
<assign to="." from="*"/>
</output>
<input message="inmsg">
<assign to="." from="*"/>
</input>
</operation>
Example 3:
Sometimes there are situations when problem cannot be solved by changing Output Message, but only by the Release Service.
One example where problem happened to me is a BP that I will describe:
- I defined different Trading Partners and contracts for them, every of them had another transport mechanism (FTP, HTTP, SMTP)
- In a BP I got a list of partners and for every one I should choose appropriate contact dynamically and send a file with B2B Send Adapter by protocol defined in a consumption profile for a specific partner
- B2B Send Adapter is used for sending file. This adapter starts B2B_LOOKUP system business process which contains B2B Lookup System Service that can read profiles from previously defined contract. As it is started by B2B Send adapter, the consumption profile and its transport mechanism will be read from the profile. Among information that we can find in the Process Data, placed by B2B Lookup System Service is b2b-profile-id, according to this id B2B_LOOKUP process and its services know which protocol to use for sending.
- If we presume that in all the iteration of the loop file must be sent by different protocol it will not happen.
- In the first iteration of the loop b2b-profile-id will be placed in the Process Data and regardless of changing contract name (b2b-contract-name element in the ProcessData) b2b-profile-id stays intact in the Process Data for all the iterations of the loop.
- It is a good solution to remove b2b-profile-id element if you have B2B Send adapter in the loop and use it with different contracts/profiles with it.
Here is an example that is not exactly what I described above, it contains series of 2 B2B Send Adapters:
<process name="default">
<sequence name="Sequence Start">
<assign name="Assign" to="b2b-contract-name">TEST_CONTRACT_AAA</assign>
<operation name="B2B Send">
<participant name="B2B_SEND"/>
<output message="B2B_SEND_SERVICEInputMessage">
<assign to="." from="*"/>
</output>
<input message="inmsg">
<assign to="." from="*"/>
</input>
</operation>
<operation name="Release Service">
<participant name="ReleaseService"/>
<output message="ReleaseServiceTypeInputMessage">
<assign to="TARGET">b2b-profile-id</assign>
<assign to="." from="*"/>
</output>
<input message="inmsg">
<assign to="." from="*"/>
</input>
</operation>
<assign name="Assign" to="b2b-contract-name">TEST_CONTRACT_BBB</assign>
<operation name="B2B Send">
<participant name="B2B_SEND"/>
<output message="B2B_SEND_SERVICEInputMessage">
<assign to="." from="*"/>
</output>
<input message="inmsg">
</input>
</operation>
</sequence>
</process>
TEST_CONTRACT_AAA has consumption profile with FTP as transport mechanism and TEST_CONTRACT_BBB has consumption profile with SMTP as transport mechanism. Without Release Service between these 2 B2B Services protocol used in both cases will be FTP (because b2b-profile-id is left in the Process Data and could not be replaced by the input message sent to the Process Data by the second B2B). After adding Release service, every B2B Send Adapter will use right and expected profile and protocol accordingly.
In general, you always have to take care of elements in Process Data that could be read by services although you do not want to. You can be very careful with Output Messages, especially if you do not change its mode in GPM, elements from Process Data will override configuration parameter by default, and if you have information in Process Data that a service read instead of its own configuration parameter and you do not expect it, it is really hard to find where the problem is. It is also possible in different kind of loops where data from one iteration can be left and cause problem in another iteration.
