BPM, serialization messages through XI

[Former Member]

Hello,

I want to achieve the following:

A business process receives and manages each message through XI in the same order as the adapter engine has sent this message (EOIO) to the BPM.

Therefore I use the fork step (Necessary branches = 1).

The first branch receives messages and appends each message to a list. (Never ending iteration: 1 = 1). To receive each message I use a dummy correlation id like a version attribute of the message type (e.g. 1.0).

The second branch manages this message list how long as the last message in the list is managed (Iteration: ReveivedMessage.MessageId != MessageList[n].MessageId.

The process also sends messages EOIO.

I have tested it and it works. But I have never seen such a process and so I'm not sure whether this process reveals any errors.

Can anybody give me an hint whether this process is correct?

Regards

Marc

[Former Member]

Hi,

thank you for very good answers. I have read the mentioned notes and article. I will go on to check these options.

Best regards

Marc

[bhavesh_kantilal]

Marc,

In the send step of your BPM you will have an option Called <b>QUEUE NAME</b> . You can use this to make sure that all messages sent from your BPM are processed EOIO.

Have you considered this?

Regards

Bhavesh

[Former Member]

Bhavesh,

yes, I've considered this.

What do you think about the following issues?

Is it correct to receive a message in the first branch and manage it in the second branch?

The second branch finishes the fork step if all received messages are managed. Form you point of view is it possible that a message(a late arrived message) is received and afterwards the fork step finishes without processing the message. Consider: The second branch finishes if "ReceivedMessage.MessageId = MessageList[n].MessageId".

What happens if the fork step ends while the receive step is working?

What happens with this incomplete message?

Regards

Marc

[henrique_pinto]

Hey Marc,

your questions are very pertinent.

I'll try to give some comments on experience that I've had.

For every collectPattern BPM instance (which is your case), you'll have a input queue which will receive messages while your correlation is active. So, while you are executing steps inside the block which defines the correlation, then you will also have messages being added to that instance's queue. So, it is extremely sugested that you use local correlations in a Block step and that you only put the loop with the receiving step and relevant container operation steps inside it.

In the case that some messages are in the queue but was never processed (because the fork or the loop reached an end condition, for example), they are called "Parked messages" and from XI SP 17/PI SP 8 you can even resend them (with a kind of huge delay time, this is a gap from workflow framework...). Check out these notes:

903139 BPE-RUN: Messages are not processed

901047 BPE-RUN: Local correlations, error in block at runtime

Briefly, you can minimize the probability of a parked message to occur, but you cannot eliminate it (probability will never reach zero). You can, by setting that particular BPM to a mode "without buffering" (meaning, no input queue), minimize the problem, and all messages which would be parked in "with buffering" mode will now be reprocessed (resent to BPE) but they have a kinda large delay (set in SMQR's Pause parameter for that particular queue).

To set the BPM for "without buffering" mode, you need to go to tx SWF_INB_CONF and enter the BPM_MODE='X' (the task of the BPM can be checked in SXI_CACHE).

But please read the notes (and the notes they refer to) before doing any setting. They comment you can't set a particular BPM to "without buffering" if you still have any parked messages for that BPM. You need to check and delete those through report RSWF_XI_UNPROCESSED_MSGS.

Regards,

Henrique.

[bhavesh_kantilal]

This article discusses the concept of buffering in a BPM. Have read throught it but never tried it, worth going trhough this as well,

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/c00d9465-ea97-2910-deac-f8aa681e...

Regards

Bhavesh