Sterling Integrator

Sterling Integrator category
Mirjana's picture

Sterling Integrator client components

Submitted by Mirjana on Mon, 02/14/2011 - 01:19

Protocols such as FTP, SFTP, HTTP, C:D are all divided into suite adapters that can be used to create a client that then connects to the trading partner and transfer the document, enforcing any security specifications from the business process

 Client components for B2B in GIS include FTP, SFTP, HTTP, JMS, MQ, SMTP, POP3, SOAP, C:D, C:E.

 Scenarios in which GIS can act as a client, by using any of above mentioned protocols looks like as follows:

Mirjana's picture

Sterling Integrator server components

Submitted by Mirjana on Mon, 02/14/2011 - 01:07

Server components for B2B in GIS are FTP, SFTP, HTTP, WS – HTTP over SOAP, C:D Server Adapters

 FTP Server Adapter in GIS/SI

  • FTP Server is tightly integrated with the Application mailbox system. An FTP client can only access the mailbox that is assigned to its user account.
  • This adapter receives and processes requests from external trading partners that are submitted using the FTP protocol. This adapter is used with a Application Perimeter server.
  • Use this adapter to put files into a Application mailbox or get files from a Application mailbox.
  • mailbox activities can trigger routing rules

SFTP Server Adapter in GIS/SI

  • Uses Mailbox subsystem as its repository (virtual roots)
  • Receives and processes requests from external trading partners that are submitted through the SFTP protocol or SCP protocol
  • Use this adapter to enable external SFTP clients or SCP clients to put files into a Application Mailbox or get files from a Application Mailbox.
  • Routing rules for items placed in Mailbox can be used to trigger a business process

CD Server Adapter

  • This adapter receives and processes requests from remote Connect:Direct nodes.
  • Mediate requests originating from a business process and going to an external trading partner using a (non-application) Connect:Direct node or another Connect:Direct Server adapter.
  • Accept requests from a Connect:Direct node (or another Connect:Direct Server adapter) to copy to or from a mailbox or business process
  • Forward requests from one remote Connect:Direct node to another

HTTP Server Adapter

  • Use this adapter to send documents to and receive documents from a trading partner using HTTP
  • Uses Perimeter services
  • Uses the same Jetty HTTP server engine as the GIS ASI console
  • Able to run both WARs and BPML applications
  • Runs application code inside the Application JVM for access to all Application resources
  • Handles SOAP requests as well

Scenarios in which GIS can act as a server, by using any of above mentioned protocols looks like as follows:

admin's picture

Sterling Integrator examples

Submitted by admin on Sun, 01/30/2011 - 05:07

 
You can find complete bpml codes or just parts that you can use in your business processes.
 

admin's picture

Usage and real examples of Input Message options

Submitted by admin on Mon, 01/24/2011 - 07:17
Different options for Output Message determine priority of elements taken by a service, if it is element from Process Data or configuration parameter and the third option in which we tell to service to read only its configuration parameter and Process Data not at all.
 
Two options for Input Message only determine where the result will be written, into Process Data or Input Message.
 
Input Message is important to understand when you have 2 services in a BP where both of them produce the Primary Document as its result. That means, the second service will replace the Primary Document produced by the first service. After the second service executes, we have only one Primary Document, that is result of the second one. If we want to have both documents in Process Data, we have to place the Primary Document of the first service into Process Data under the name different than Primary Document and it will help us to retain the document in a business process.
 
Here is the example where we will show what happens when there are 2 different services where both produce Primary Document. The first service is FSA (File System Adapter) and another one is LWJDBC (Lightweight JDBC). In the end of a BP execution we can find only one Primary Document as the result of File System Adapter. Primary Document produced by LWJDBC is overwritten by the FSA:

Example 1 (Primary Document pulled from a DB by LWJDBC overriden by the document collected by FSA): 

<process name="default">

<sequence>

                   <operation name="Lightweight JDBC Adapter">
                             <participant name="LightweightJDBCAdapterQuery"/>
                             <output message="LightweightJDBCAdapterTypeInputMessage">
                                      <assign to="pool">mysqlPool</assign>
                                      <assign to="query_type">SELECT</assign>
                                      <assign to="result_name">result</assign>
                                      <assign to="row_name">row</assign>
                                      <assign to="sql">select * from SI_VERSION</assign>
                                      <assign to="." from="*"/>
                             </output>
                             <input message="inmsg">
                                      <assign to="." from="*"/>
                             </input>
                   </operation>
                   <operation name="File System Adapter">
                             <participant name="FSA_configurationName"/>
                             <output message="FileSystemInputMessage">
                                      <assign to="Action">FS_COLLECT</assign>
                                      <assign to="deleteAfterCollect">true</assign>
                                      <assign to="filter">fileNameFilter</assign>
                                      <assign to="." from="*"/>
                             </output>
                             <input message="inmsg">
                                      <assign to="." from="*"/>
                             </input>
                   </operation>
          </sequence>
</process>
 
To save a result of LWJDBC adapter in the Process Data under another name, we can use assign, to save the first document in a temp storage. You can see that in Example 2:

Example 2 (Primary Document saved under another element with separate assign statement): 

<process name="default">

          <sequence>
                   <operation name="Lightweight JDBC Adapter">
                             <participant name="LightweightJDBCAdapterQuery"/>
                             <output message="LightweightJDBCAdapterTypeInputMessage">
                                      <assign to="pool">mysqlPool</assign>
                                      <assign to="query_type">SELECT</assign>
                                      <assign to="result_name">result</assign>
                                      <assign to="row_name">row</assign>
                                      <assign to="sql">select * from SI_VERSION</assign>
                                      <assign to="." from="*"/>
                             </output>
                             <input message="inmsg">
                                      <assign to="." from="*"/>
                             </input>
                   </operation>
                  
                   <assign to="tempStorage" from="PrimaryDocument/@SCIObjectID"/>
                  
                   <operation name="File System Adapter">
                             <participant name="FSA_configurationName"/>
                             <output message="FileSystemInputMessage">
                                      <assign to="Action">FS_COLLECT</assign>
                                      <assign to="deleteAfterCollect">false</assign>
                                      <assign to="filter">fileNameFilter</assign>
                                      <assign to="." from="*"/>
                             </output>
                             <input message="inmsg">
                                      <assign to="." from="*"/>
                             </input>
                   </operation>
          </sequence>
</process>
 
In the end we can find 2 documents in the Process Data: 

<?xml version="1.0" encoding="UTF-8"?>

<ProcessData>
          <tempStorage SCIObjectID="serverName:49b61c40:11032a4d48e:5d0f"/>
          <FileName>fileName</FileName>
          <PrimaryDocument SCIObjectID="serverName:49b61c40:11032a4d48e:5d50"/>
</ProcessData>
 

If we want to avoid this additional step between LWJDBC Adapter and FSA for saving the result of LWJDBC into document named 'tempStorage', we can use assign in input message inside of LWJDBC. First of all, option for Input Message must be 'Allow message write' and additional assign must be added in input message (by Add option in GPM). You can see it in Example 3:

Example 3 (Primary Document saved under another element with assign statement inside of Input Message):

<process name="default">

          <sequence>
                   <operation name="Lightweight JDBC Adapter">
                             <participant name="LightweightJDBCAdapterQuery"/>
                             <output message="LightweightJDBCAdapterTypeInputMessage">
                                      <assign to="pool">mysqlPool</assign>
                                      <assign to="query_type">SELECT</assign>
                                      <assign to="result_name">result</assign>
                                      <assign to="row_name">row</assign>
                                      <assign to="sql">select * from SI_VERSION</assign>
                                      <assign to="." from="*"/>
                             </output>
                            
                             <input message="inmsg">
                                                <assign to="tempStorage" from="PrimaryDocument/@SCIObjectID"/>
                                    </input>
                            
                   </operation>
                   <operation name="File System Adapter">
                             <participant name="FSA_configurationName"/>
                             <output message="FileSystemInputMessage">
                                      <assign to="Action">FS_COLLECT</assign>
                                      <assign to="deleteAfterCollect">false</assign>
                                      <assign to="filter">fileNameFilter</assign>
                                      <assign to="." from="*"/>
                             </output>
                             <input message="inmsg">
                                      <assign to="." from="*"/>
                             </input>
                   </operation>
          </sequence>
</process>

The first step was switch to 'Allow message write' so we can get result of service into input message insted of in the Process Data. As we have input message at disposal, we can use assign in the input message that takes values/nodes from Input Message and put it into Process Data. The assign statement from the example...

<assign to="tempStorage" from="PrimaryDocument/@SCIObjectID"></assign>

 ...will take content of the Primary Document and put it into document named 'tempStorage' 

Using assign inside of input message gives the same result in Process Data as independant assign in the Example 2:

<?xml version="1.0" encoding="UTF-8"?>

<ProcessData>
          <tempStorage SCIObjectID="serverName:49b61c40:11032a4d48e:5d0f"/>
          <FileName>fileName</FileName>
          <PrimaryDocument SCIObjectID="serverName:49b61c40:11032a4d48e:5d50"/>
</ProcessData>  

Since the result of LWJDBC Adapter is always in XML format, we can use another assign to get XML tree in Process Data: 

Example 4 (Primary Document content moved directly to Process Data by DocToDOM function ): 

 <process name="default">

          <sequence>
                   <operation name="Lightweight JDBC Adapter">
                             <participant name="LightweightJDBCAdapterQuery"/>
                             <output message="LightweightJDBCAdapterTypeInputMessage">
                                      <assign to="pool">mysqlPool</assign>
                                      <assign to="query_type">SELECT</assign>
                                      <assign to="result_name">result</assign>
                                      <assign to="row_name">row</assign>
                                      <assign to="sql">select * from SI_VERSION</assign>
                                      <assign to="." from="*"/>
                             </output>
 
                             <input message="inmsg">
                                                <assign to="tempStorage" from="DocToDOM(PrimaryDocument)"/>
                                    </input>
 
                   </operation>
                   <operation name="File System Adapter">
                             <participant name="FSA_configurationName"/>
                             <output message="FileSystemInputMessage">
                                      <assign to="Action">FS_COLLECT</assign>
                                      <assign to="deleteAfterCollect">false</assign>
                                      <assign to="filter">fileNameFilter</assign>
                                      <assign to="." from="*"/>
                             </output>
                             <input message="inmsg">
                                      <assign to="." from="*"/>
                             </input>
                   </operation>
          </sequence>
</process>

Process Data after this business process will contain the result of LWJDBC in Process Data tree and Primary Document as the result of FSA: 

<?xml version="1.0" encoding="UTF-8"?>

<ProcessData>
          <tempStorage>
                   <result>
                             <row>
                                      <SI_VERSION>4.1.0-1976</SI_VERSION>
                                      <SI_INSTALL_DATE>2007-01-15 11:30:49</SI_INSTALL_DATE>
                                      <SI_COMMENTS>SI patch installation</SI_COMMENTS>
                                      <PRODUCT_VERSION>4.1.1</PRODUCT_VERSION>
                                      <ENGINE_VERSION>1976</ENGINE_VERSION>
                             </row>
                   </result>
          </tempStorage>
          <FileName>mimi</FileName>
          <PrimaryDocument SCIObjectID="serverName:49b61c40:11032a4d48e:6646"/>
</ProcessData>
 

 

admin's picture

Two different options in Input Message

Submitted by admin on Mon, 01/24/2011 - 06:36
There are 2 different options for Input Message:
 
Allow Process Data write
 
If you use option 'Allow Process Data write' for an Input Message in a service, the result of service execution will be placed in the Process Data.
How it looks like in bpml code:
 
 <operation name="File System Adapter">
          <participant name="PLIVA_FSA"/>
          <output message="FileSystemInputMessage">
                   <assign to="Action">FS_COLLECT</assign>
                   <assign to="deleteAfterCollect">false</assign>
                   <assign to="filter">mimi</assign>
                   <assign to="." from="*"/>
          </output>
          <input message="inmsg">
                        <assign to="." from="*"/>
            </input>
</operation>
 
 
Allow message write
 
If you use option 'Allow message write' for an Input Message in a service, the result of service execution will be placed into the input message.
 
Input message for this option in bpml looks as follows:
 
<operation name="File System Adapter">
          <participant name="PLIVA_FSA"/>
          <output message="FileSystemInputMessage">
                   <assign to="Action">FS_COLLECT</assign>
                   <assign to="deleteAfterCollect">false</assign>
                   <assign to="filter">mimi</assign>
                   <assign to="." from="*"/>
          </output>
          <input message="inmsg">
      </input>
</operation>
 
When you start the process and want to see an Input Message for a certain service, go into Process Monitor, find your process, open it, click on info of Instance data for the service which Input Message you want to see and finally click on 'Message From Service' link on the left side will show you input message sent from the service to the business process.
 
  • For Get Document Information Service input message looks like this:
 
<?xml version="1.0" encoding="UTF-8"?>
<inmsg>
          <BodyName>bodyName</BodyName>
          <BodyLength>1076</BodyLength>
          <DocumentBodyLength>1076</DocumentBodyLength>
          <DocumentName>documentName</DocumentName>
          <DocumentId>serverName:49b61c40:11032a4d48e:3b0b</DocumentId>
          <DocumentSubject/>
          <DocumentCreateTime/>
          <DocumentLength>1076</DocumentLength>
          <DocumentLifeSpan>0 Minutes</DocumentLifeSpan>
          <DocumentInitialId>madrugada:49b61c40:11032a4d48e:3b0b</DocumentInitialId>
          <DocumentMaxInlineBodySize>102400</DocumentMaxInlineBodySize>
          <DocumentPurgeAfter>2007-01-18 12:21:23.93</DocumentPurgeAfter>
          <DocumentStorageType>DATABASE</DocumentStorageType>
          <DocumentWorkflowId>200152</DocumentWorkflowId>
          <DocumentType>0</DocumentType>
</inmsg>
 
It is the result of Get Document Information service that goes into Process Data with option 'Allow Process Data write', but when you choose option 'Allow Message write' it is not placed in the Process Data, but into Input Message or Message From Service as shown above.
 
  • For File System Adapter in collection mode, its result is FileName and Primary Document, Input Message looks like as follows:
 
<?xml version="1.0" encoding="UTF-8"?>
<inmsg>
          <FileName>fileName</FileName>
          <PrimaryDocument SCIObjectID="serverName:49b61c40:11032a4d48e:3b53"/>
</inmsg>
 
Remember that the rest of services in your BP will not be able to get any information that is redirected into Input Message. Input message content retains only for the current service, but not for the whole process.
The Process Data is accumulation area that lives from the beginning of the process to the end.
Input message is accesible just by a service that executes an activity and produce that message, and you can take some elements that you will need later, by assign(s) inside of the input message and put it into Process Data for later use.  

 

admin's picture

Content of Input Message

Submitted by admin on Mon, 01/24/2011 - 06:14

Example of Input Message from Get Document Information Service to business process or Process Data (it is only a part of full XML inpu message, so not well formed):

 
          <BodyName>bodyName</BodyName>
          <BodyLength>1076</BodyLength>
          <DocumentBodyLength>1076</DocumentBodyLength>
          <DocumentName>documentName</DocumentName>
          <DocumentId> serverName:49b61c40:1102f7e087e:-15ad</DocumentId>
          <DocumentSubject/>
          <DocumentCreateTime/>
          <DocumentLength>1076</DocumentLength>
          <DocumentLifeSpan>0 Minutes</DocumentLifeSpan>
          <DocumentInitialId>serverName:49b61c40:1102f7e087e:-15ad</DocumentInitialId>
          <DocumentMaxInlineBodySize>102400</DocumentMaxInlineBodySize>
          <DocumentPurgeAfter>2007-01-17 15:52:32.474</DocumentPurgeAfter>
          <DocumentStorageType>DATABASE</DocumentStorageType>
          <DocumentWorkflowId>198318</DocumentWorkflowId>
          <DocumentType>0</DocumentType>
 
Example of File System Adapter Input Message:
 
<PrimaryDocument SCIObjectID="serverName:49b61c40:1102f7e087e:-1565"/>
 
admin's picture

Input Message

Submitted by admin on Mon, 01/24/2011 - 06:10
Input Message in bpml, is message in XML format sent from a service to a business bprocess as an incoming message.
 
Result of a service execution is XML sent to a business process as an Input Message.

admin's picture

Usage and real examples of Output Message options

Submitted by admin on Mon, 01/24/2011 - 06:02
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. 
 
admin's picture

Three different options in Output Message

Submitted by admin on Mon, 01/24/2011 - 04:49
There are 3 different options for Output Message:
 
Obtain Message first, then Process Data
 
It sends configuration parameters, all defined in XML Output Message to a service first and after that Process Data. If there are elements with the same names in output message as in the Process Data, the business Process Data overrides the service configuration information. Service will always read parameters from its configuration, or Output Message first and after that from Process Data.
 
How it looks like in bpml code for e.g. File System Adapter:
 
<operation name="File System Adapter">
          <participant name="FSA_configurationName"/>
          <output message="FileSystemInputMessage">
                   <assign to="Action">FS_COLLECT</assign>
                   <assign to="appendOnExtract">true</assign>
                   <assign to="deleteAfterCollect">false</assign>
                   <assign to="filter" from="assignedFilter/text()"/>
                   <assign to="genReport">true</assign>
                   <assign to="." from="*"/>
          </output>
          <input message="inmsg">
                   <assign to="." from="*"/>
          </input>
</operation>
 
We see that assign element (<assign to="." from="*"/>) comes after configuration parameters, as the last element in the output message. So what service read first are parameters from configuration and after that from Process Data.
 
Obtain Process Data first, then Messages
 
It sends Process Data first to a service and service configuration information after Process Data. If duplicate information can be found between Output Message (containing service configuration parameters) and Process Data, parameters from the configuration overrides Process Data.
 
How it looks like in bpml code for e.g. File System Adapter:
 
<operation name="File System Adapter">
          <participant name=" FSA_configurationName "/>
          <output message="FileSystemInputMessage">
                   <assign to="." from="*"/>
                   <assign to="Action">FS_COLLECT</assign>
                   <assign to="appendOnExtract">true</assign>
                   <assign to="deleteAfterCollect">false</assign>
                   <assign to="filter" from="assignedFilter/text()"/>
                   <assign to="genReport">true</assign>
          </output>
          <input message="inmsg">
                   <assign to="." from="*"/>
          </input>
</operation>
 
We see that assign element (<assign to="." from="*"/>) comes first and configuration parameters after it. So what service reads first is Process Data and after that parameters from configuration.
 
Messages Only
 
Sends only parameters from configuration, that is Output Message to a service. In that case, service will not be able to read anything from the Process Data.
 
<operation name="File System Adapter">
          <participant name="FSA_configurationName"/>
          <output message=" FileSystemInputMessage ">
                   <assign to="Action">FS_COLLECT</assign>
                   <assign to="appendOnExtract">true</assign>
                   <assign to="deleteAfterCollect">false</assign>
                   <assign to="filter" from="assignedFilter/text()"/>
                   <assign to="genReport">true</assign>
          </output>
          <input message="inmsg">
                   <assign to="." from="*"/>
          </input>
</operation>
 
You see there is no assign <assign to="." from="*"/>in output message any more, so Process Data will not be read.
 
Be aware that with this option set – Messages Only, for a service that needs a Primary Document to work on, the service will not be able to read the Primary Document, because it is always placed in the Process Data. If you configure File System Adapter for extraction with Output Message in mode 'Messages Only', the adapter will throw an error that there is no Primary Document, although you can find the Primary Document in the Process Data. But in this mode service cannot read anything from the Process Data.

 

 

admin's picture

Problems and notes

Submitted by admin on Mon, 01/24/2011 - 04:27

There are 2 things important to mention:

 

How and where we can see Output Message

 

You can see Output Messages only if at least one parameter in GPM is defined as Xpath.

If none parameter is defined by using Xpath, you will not see the Output Message, but services always get such messages, they could not work without them. I do not know why it is implemented so, it is always good and useful to see the Output Message regardless the way parameters are defined, by using Xpath or constants.

For testing purposes I like to see all data and messages in every step in order to debug or optimize BP for production.  

 

Inconsistency in naming for Output Message

 

Although it is an Output Message, all the services has 'InputMessage' suffix added in the end of the message name.

It is ' FileSystemInputMessage ' for File System Adapter and 'SMTP_SEND_ADAPTERInputMessage' for SMTP Send Adapter. It can be changed in GPM in Service Editor / Message To Service /  Message Name. We can say that it can be input message for a service, but regarding consistency, we could follow the rule or definition that says that Output Message goes from a BP to a service. I think it is problem in design, because Input Message is saved under element 'inmsg' and Output Message should have significant name and it should be 'OutputMessage' instead of 'InputMessage' suffix.

Everything is relative and we can say what will be input or output depends on the point of view, but I would say when we talk about Inbound or Outbound EDI, no one will ask yourself for point of view, but will know exact direction in both cases, it should be the same in this case with Messages.

 

Syndicate content

Library

Main Menu

User login

Login/Register

Tell a friend

Send an e-Postcard

New forum topics

Recent Posts Recent Posts