Author |
Message
|
Achilleas Pertesis |
Posted: Wed Nov 11, 2020 10:08 am Post subject: IIB:Split a batch msg into single msgs without MQ autocommit |
|
|
Newbie
Joined: 11 Nov 2020 Posts: 3
|
Hello all,
I am an IBM IIB/ACE/MQ user.
I have a requirement to generate single record messages from a batch message that contains a big number of records. The batch message is a web service response.
My opinion until now is that this should be implemented using an esql node and propagate single record messages while the initial batch message has a next sibling. The one record message will be put in an output queue.
My question is:
Is there any way to put the single messages in the queue without the auto commit and avoid the auto message propagation on the next node/flow?
I need first to create and put on the output queue all the single record messages and then commit them and make them available on the next node/flow.
This will secure my implementation in a crash/system failure because single records will not be propagated on the next flow without the completed successful separation on the initial batch message.
Thanks in advance,
Any proposals will be highly appreciated ! |
|
Back to top |
|
 |
abhi_thri |
Posted: Wed Nov 11, 2020 11:22 pm Post subject: |
|
|
 Knight
Joined: 17 Jul 2017 Posts: 516 Location: UK
|
hi...sounds like you just need to ensure that everthing is done as a single transaction. What type of input node does the flow starts with, check whether it is configured to start a transaction.
Please note that 'Automatic' may not start a transaction if the messages are not persistent...
https://www.ibm.com/support/knowledgecenter/SSMKHH_10.0.0/com.ibm.etools.mft.doc/ac04561_.html
If the input node is already using the correct Transaction property value try checking what is configured on the MQOutput node |
|
Back to top |
|
 |
Achilleas Pertesis |
Posted: Thu Nov 12, 2020 2:43 am Post subject: |
|
|
Newbie
Joined: 11 Nov 2020 Posts: 3
|
Thaks abhi_thri for your response,
The flow starts with an MQ Input node and ends with an MQ output node.
So if I do the right configurations about the Transactions/persist-ency on MQ Input/Output node, the following behaviour will be true?
When the esql node propagate the one record messages on the MQ output node while the processing of the batch message is not finished these messages will not be available on the next flow that uses as a starting node an MQ Input with the same queue? And if an failure occur while the batch process is not finished the batch message will be rollback-ed on the MQ Input queue as was before the process started?
Many thanks for your help. |
|
Back to top |
|
 |
abhi_thri |
Posted: Thu Nov 12, 2020 2:59 am Post subject: |
|
|
 Knight
Joined: 17 Jul 2017 Posts: 516 Location: UK
|
Achilleas Pertesis wrote: |
When the esql node propagate the one record messages on the MQ output node while the processing of the batch message is not finished these messages will not be available on the next flow that uses as a starting node an MQ Input with the same queue? And if an failure occur while the batch process is not finished the batch message will be rollback-ed on the MQ Input queue as was before the process started? |
hi...yes, that is correct...If the whole work is done under a single transaction, even though you are using Propagate to send messages to the Output queue the messages won't be available for any other process to retrieve from the queue until the whole transaction is committed. You can actually see this in working by putting a debug point in the flow and let some of the messages reach the output queue, now if you check the Output queue status (via MQ Explorer or via display qstatus command) you will see the property UNCOM set to 'Yes', i.e it is not committed yet. |
|
Back to top |
|
 |
Achilleas Pertesis |
Posted: Thu Nov 12, 2020 3:43 am Post subject: |
|
|
Newbie
Joined: 11 Nov 2020 Posts: 3
|
Many thanks abhi_thri,
I will try this later in the day and I will post the results.
You are super! |
|
Back to top |
|
 |
|