It looks like that PIP4C1 document while sending outbound to this step wm.ip.cm.handlers:send is having some problems which this service internally invokes the wm.ip.util:addXMLheader which probably might not receiving the ‘document’ PIP4C1 with from the pipeline when adding RN Headers (Preamble,DeliveryHeader etc…).
So debug and step thru the flow whether your mapping creates PIP4C1 DocumentType before routing it to 'send’out service.
If you are sure the mapping is fine and created the PIP4C1 document then send service should not fail and will behave as expected.
The scenario is that I started 1247 processes and the 570 processes failed with missing required parameter ‘document’ while other 677 processes finished successfully. Certainly I am sure the mapping is fine. The error encountered only in volume performance testing. Is there any further proposal for me? Thanks.
Hello,
I do integrations that involve short times of high volume data. I at times fine the IS has threads that error out at some bottle neck point. You can have REPEAT steps in your flow service that will loop until you have the data you want. So if 100 calls are made at the same time and only 30 can go through, you can have a 3 to 5 second wait with about 5 max loop retries to help the reliability of the service calls. I do this multiple times through some flows that are heavy database users.
It won’t slow down your systems that much as if everything exists the first time, there will be no looping available. I would suggest not looping indefinitely as you may accidently not have a source system online and you may not be able to stop those threads otherwise.
I agree with Yemi’s flow suggestion you may follow that or else implement the IS largedocument handling using NodeIterator,getNextNode r configure TN largefile handling that helps for processing with less memory/threads usage.