BPM, serialization messages through XI

Question

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

Answer 1

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.