Message Orchestration with multiple send step without nwBPM in SAP PO

[former_member746478]

SAP does offer many ways for message orchestration. With ABAP stack we were using  ccBPM and  now same can be achieve with nwBPM.

We have a similar requirement  and we able to achieve it without using nwBPM.

Requirement

1. Business perform operation on source application every 3 Hour which generate a service call to SAP PO system by merging all message in a single paylaod.


2. SAP PO has to split the message and submit it to target application one by one


3. Once step 1 completed, SAP PO has to again submit the source message to target application to retrieve the acknowledgement ID  generated after step 1 at target application


4. If ack ID is successful submit the message 3 to close the processing at target application else skip step 3

Typically for this kind of requirement we always look for SAP nwBPM capability to orchestrate the messages between applications but same can be achieved in SAP PO without using nwBPM.

Solution Approach

To achieve message orchestration we have used

1. SAP PO capability to start/stop a channel from adapter framework using SOAP  receiver channel: This allow us to define 3 parallels ICO and calling an ICO from another ICO.


2. Maintain order at runtime:  This allow us to manage the processing in sequence  and making sure next call get triggered once previous step are completed.

Architecture  and design

ICO1

sender SOAP channel: This should be simple SOAP sender channel configuration with quality of service as EOIO. EOIO is set to make sure all the messages (1-n) get processed completely before it switch to next step

Receiver Interface step in ICO1

     

Maintain order at runtime:  This allow  to process each step one after another making sure each step fully execute before control switch to next step

Step 1: This step call an operation mapping which split the message into 1-n. The receiver SOAP channel will submit the request in sequence due to EOIO process.

Step 2: This step will allow to start ICO 2 sender file channel(Poll interval set to 10 sec) from this ICO. Make sure you set this sender file channel as automictic control from monitoring page

      

 Adapter type: HTTPS_AAE

Target host: PO server host

port: PO server port

path: /AdapterFramework/ChannelAdminServlet?party=*&service=<file channel service             name>&channel=<ICO 2 sender channel name>& action=start

Step 3: This step will write a file to SFTP server. make sure to write a file in same location from where ICO 2 picks the file. Since ICO2 channel is already started in previous step it will pick the file once this step write the file to location.

Step 4: This step will allow to stop the sender file channel again.  But before stopping the channel we need to make sure that ICO2  get fully excused. Since 2nd ICO is synch in nature, we used simple java mapping for thread sleep to delay a process a bit. The tread sleep parameter we defined is 55 sec same as gateway timeout.

Code:

public void transform(TransformationInput input, TransformationOutput output)  throws StreamTransformationException

 {

//InputStream inputstream =input.getInputPayload().getInputStream();

OutputStream outputstream = output.getOutputPayload().getOutputStream();

try

 {

Thread.sleep(55000);

String str= " ";

outputstream.write(str.getBytes());

}

catch(InterruptedException ie)

{

}

catch(IOException io)

{

}

}

 

ICO 2

Sender file channel: we used asynch/synch bridge module to to make sure we write response message to another location for ICO 3 process.

Receiver SOAP channel for synch call: Here we are using GetPayloadValueBean and PutPayloadValueBean to store both request and response  for receiver file channel.

ICO 3

This is simple ICO running independently. it is picking file at every 10 sec and check if Ack is true. if yes it post the message else ignore it  the file in PO.

 

Conclusion 

1. This architecture are aligned with integration suite migration plan as SAP already provide connector(Process Direct) to manage calls between iflows.


2. we are avoiding nwBPM  which need to be redesigned with current integration suite offering when we migrate SAP PO to integration suite.

 

Thanks

Navneet Sumit