Objective

In NW BPM we don't have acknowledgement handling option that we had in ccBPM. The goal of this document is to show a workaround for the problem.

There is already a good solution in that topic (http://scn.sap.com/community/pi-and-soa-middleware/blog/2012/10/01/file-record-confirmation-in-a-nw-po-scenario) but it is writing in a temporary folder and uses an extra file sender channel to implement the acknowledgement functionality.

The solution described in this document uses a single file receiver channel.

The idea behind

After a successful writing the receiver file adapter can send back an empty message. In case of failure the message goes to error status (after the configured number of retries) and there is no response sent back. In our case we have 3 retries with 5 minutes interval which means either we get an acknowledgement from the file adapter in 15 minutes or we can be sure that the file writing has failed.

It is modeled by an NW BPM which is sending the asynchronous message to the file adapter and which has a timeout of 16 minutes.

What we need to make this work is:

- to make the file adapter to send back an acknowledgement message - it is done by a ResponseOneWay bean on the module tab

- to make an xml from the empty message - it is done by a Transformation bean (plain2XML)

- to transfer correlation data from the inbound message to the new asynchronous acknowledgement message created by the ResponseOneWay bean - it is done by a DynamicConfiguration bean using read/write commands.

Message flow

Implementation

ESR

Interfaces and message types

We need inbound and outbound interfaces for the main message, the acknowledgement and the error/success message with the following types:

The two fields filename and path of MT_MESSAGE will be used in the file adapter and will also form the content of the file.

The obj_id of MT_Acknowledgement is used for message correlation in the BPM and will contain in our example the file name.

The description field of MT_STATUS will be written in an error/success file in order to model some feedback logic to see the outcome of the main message transfer (it could have been also email sending, alerting etc. but for demo purpose file transfer seemed to be the easiest). In our case it will hold again the file name.

The following asynchronous interfaces are used in the scenario:

The inbound interfaces MIIA_MESSAGE and MIIA_Acknowledgement belong also to the BPM business component thus they have to be XI30 compatible.

Mapping objects

Before calling the receiver file adapter we insert the file name from the payload into the ASMA (Adapter specific message attributes). After calling the receiver file adapter when sending back the acknowledgement message we put the file name from the dynamic configuration into the acknowledgement payload.

These two operations are performed in the following mappings:

Directory

The business components

The following business components and channels are defined for the scenario:

The BPM is communicating via a sender and receiver soap channel the same way as in any other NW BPM scenario so they won't be detailed here.

The soap sender channel of the sender system and the error/success file receivers of the receiver systems are also the usual ones, no explanation needed.

It is however important to explain the file receiver channel of the main message which is the heart of the solution. The fault soap sender channel of the receiver system is also an ordinary soap channel but it is worth mentioning that it is used for the acknowledgement sending from the receiver file adapter of the main message.

The file receiver channel

As mentioned earlier this file receiver channel will send back an asynchronous acknowledgement message. To achieve this we need some module configuration.

The modules:

GetFileName: we read the file name from the dynamic configuration and store it in a variable to reuse it in the ack. sending.

Plain2XML: we need to convert the empty response of the file channel to an xml message.

SetFileName: we take the file name from the above variable and put it in the new acknowledgement message's dynamic configuration.

RequestResponse and ResponseOneway: we send back a new asynchronous acknowledgement message.

The integrated configurations

First we send MESSAGE from the sender system to the BPM:

Then the BPM sends MESSAGE to the receiver system:

The acknowledgement is sent back from the receiver system to the BPM:

It is important to setup this ICO with virtual receiver as the file adapter sets the receiver in the message header.

Finally the BPM sends an error or success status to the receiver system (they look the same so only one is detailed here):

NWDS

Start event: we map the incoming message (via MIIA_MESSAGE) to the local variable MESSAGE.

Parallel split: we start the file sending branch and the timeout branch.

Send_MESSAGE: in the input mapping we map the local MESSAGE to MT_MESSAGE and send it out via MIOA_MESSAGE.

Acknowledgement: in that intermediate message event we wait for MIIA_Acknowledgement with correlation on the file name

                              string-equal(MT_Acknowledgement/obj_id,MESSAGE/filename)

Send_SUCCESS: we map the file name in the MT_STATUS-description field and send the message via MIOA_SUCCESS

Wait_Ack: internal timer for 16 minutes (in case of error the adapter tries to resend 3 times with 5 min. interval). After 16 minutes the message is already in error status, we can send out the error status.

Send_ERR: we map the file name in the MT_STATUS-description field and send the message via MIOA_ERR

End, Termination 0: termination events