Hi,
i have receive - send steps in my BPM process (let say a_step_receive_request and corresponding b_step_send_response) but after timeout or error which are implemented in separate swimlines i would like to send response (let say c_step_send_response_error) as reply to request from a_step_receive_request. I’ve used send and receive task with receive protocol Simple Service (For Synchronous Receive/Send) and proper publishable documents. Everything is ok in “happy path” but when process is timedout or throwing error response is generated from c_step_send_response_error and send task from error swimline is throwing error:

[2050]2017-10-12 09:43:32 CEST [BPM.0102.0002E] Exception: com.wm.app.prt.ProcessException
[2049]2017-10-12 09:43:32 CEST [BPM.0102.0391E] 36ea29b0-55fa-147b-a17b-fffffffd75f2:1, S62: exception sending output 0 of 2: [PRT.0101.9130] Error during transport send
[2048]2017-10-12 09:43:32 CEST [BPM.0102.0002E] Exception: com.wm.app.prt.ProcessException
[2047]2017-10-12 09:43:32 CEST [BPM.0101.0059E] Exception during send: [PRT.0101.9125] Service pub.publish:reply failed.
[2046]2017-10-12 09:43:32 CEST [BPM.0101.0002E] Exception: com.wm.app.prt.ProcessException

Any ideas how to solve this problem and what does this error means?

The reason is probably that if the timeout or error occurs, the process jumps to a track whose pipeline does not contain the envelope of the original request (you try to reply to). Hence publish.reply fails.

Swimlanes do not matter in this case IMO.

Thx for reply.

When timeout or error flow is joined to the orginal track (just before b_step_send_response) whose request envelope from a_step_receive_request should be in pipeline the error is the same. Moreover, I’ve used sleep method in one of the process step to simulate timeout conditions and when timeout and described here errors occurs at the end of timeout/error track I have step type “terminate” and i server log i see message “process failed”, but when sleep methods in original track ends, process continues his jobs and at the end send “proper” response message from b_step_send_response without errors.

1. a_step_receive_request → x_step_with_sleep_methods (timeout occurs)
2. y_step_in_timeout_track → c_step_send_response_error (failed with PRT.0101.9125), in log we can see “process failed”
3. x_step_with_sleep continues his job and finally b_step_send_response is send.

Is it possible to join “timeout track” to the original process pipeline?

I can’t follow. Please craeate a simple process model for this case and post it here. Also as an image.

Process overview screens you can see in attachements.

I’ve simple documents: request and response.
Document request has two fields: A and B, response has only one field called status. Both documents are publishable,

In “happy path” process is inititated by receive step a_step_receive_request when document request is published, next step called y_step_sleep_making_timeout is waiting 10 seconds. Proces has general timeout 5s. After 5s TimoutHandler is called and step prepare_response_error returns response dosument. Last step called c_step_send_reposponse_error is trying to send response document with status “NOK” as a reply to a_step_receive_request but failed with Exception during send: [PRT.0101.9125] Service pub.publish:reply failed.

After that, y_step_sleep_making_timeout is finished (after 10s), response document with status OK is sending as reply to a_step_receive_request from b_step_send_response.

In server log we can see:

[9368]2017-10-13 14:54:51 CEST [BPM.0102.0202I] 70e700b0-6327-135a-8421-ffffffefffd0:1, MID=TEST/TimeoutTest, MVer=1: process completed
[9367]2017-10-13 14:54:51 CEST [ISP.0090.0004I] TestpPP -- TIMEOUTRESPONSE -- Received response status -- OK
[9366]2017-10-13 14:54:51 CEST [ISP.0090.0004I] TestpPP -- TIMEOUTRESPONSE -- responding after 10s
[9364]2017-10-13 14:54:47 CEST [BPM.0102.0199I] 70e700b0-6327-135a-8421-ffffffefffd0:1, MID=TEST/TimeoutTest, MVer=1: process failed
[9363]2017-10-13 14:54:47 CEST [BPM.0102.0376E] 70e700b0-6327-135a-8421-ffffffefffd0:1, S18: exception invoking service TEST.TimeoutTest.TimeoutTest_1.IS_BS_I12:c_step_send_response_error: [PRT.0101.9130] Error during transport send
[9362]2017-10-13 14:54:47 CEST [BPM.0102.0002E] Exception: com.wm.app.prt.ProcessException
[9361]2017-10-13 14:54:47 CEST [BPM.0102.0391E] 70e700b0-6327-135a-8421-ffffffefffd0:1, S18: exception sending output 0 of 2: [PRT.0101.9130] Error during transport send
[9360]2017-10-13 14:54:47 CEST [BPM.0102.0002E] Exception: com.wm.app.prt.ProcessException
[9359]2017-10-13 14:54:47 CEST [BPM.0101.0059E] Exception during send: [PRT.0101.9125] Service pub.publish:reply failed.
[9358]2017-10-13 14:54:47 CEST [BPM.0101.0002E] Exception: com.wm.app.prt.ProcessException
[9357]2017-10-13 14:54:47 CEST [ISP.0090.0004I] TestpPP -- TIMEOUTRESPONSE -- Tmeoud occured, preparing NOK response
[9356]2017-10-13 14:54:41 CEST [ISP.0090.0004I] TestpPP -- TIMEOUTRESPONSE -- waiting 10s...
[9355]2017-10-13 14:54:41 CEST [BPM.0102.0196I] 70e700b0-6327-135a-8421-ffffffefffd0:1, MID=TEST/TimeoutTest, MVer=1: process started
[9354]2017-10-13 14:54:41 CEST [ISP.0090.0004I] TestpPP -- TIMEOUTRESPONSE -- Publishing request

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/4108b04e50abd62be203e4b069928dbc5dc4ceee_2_591x750.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/4108b04e50abd62be203e4b069928dbc5dc4ceee.jpeg 2x" data-dominant-color="F1F4E8">

ReceiveImplementation.jpg727×922 101 KB

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/c7a6d58ffbd63cd684a46b7310d1f1693be8eda7_2_550x748.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/c7a6d58ffbd63cd684a46b7310d1f1693be8eda7.jpeg 2x" data-dominant-color="F2F4E6">

TimeoutResponseImplementation.jpg710×965 104 KB

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/d0072374f9c64aa3e6127e631c77224f2cc4e291_2_585x750.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/d0072374f9c64aa3e6127e631c77224f2cc4e291.jpeg 2x" data-dominant-color="F1F4E8">

ResponseImplementation.jpg736×943 99.5 KB

After having seen the pictures, I still think that the problem is that the process “thread” starting at the timeout handler does not have all the needed information to send a synchronous reply.

To verify this, make the following:

1. In the y_step_sleep, before calling sleep, write out the contents of the received request to a file (it’s importatnt that the whole request is written, including _env).

2. prepare_response_error, read in the file so that the request is in the pipeline and then do the rest.

If you do it properly, I’m quite sure it will work.

Of course, it’s just a PoC. This solution is not for a production system. But you first have to understand the problem.

Unfortunately POC doesnt work. I have done what you sugested but when I write request in y_step_sleep into file and read file in prepare_response_error making request document visible in process pipeline before c_step_send_reposponse_error - result is exactly the same.

request document before writing and afer reading is logged, _env is exactly the same, for example:
_env before write:

<_env> 
<activation>wm69de9cbc0-7024-1f43-a9ea-fffffffcceb9</activation> 
<businessContext>wm6:65fd1130-bea3-1eed-a988-fffffffccef2\sf287ba80-7bba-145e-a446-fffffffcceba\s9de9cbc0-7024-1f43-a9ea-fffffffcceb9:wm69de9cbc0-7024-1f43-a9ea-fffffffcceb9:null:IS_61:null</businessContext>
<locale></locale> 
<tag>13</tag> 
<pubId>10_252_12_88_5555_1499686653_J_jRQtEolDEurgAVIwwwADXaZQs__RequestReplyClient</pubId> 
<uuid>a86ce5b0-b33f-11e7-898f-000000000022</uuid> 
<eventID>43</eventID> 
<recvTime>Tue Oct 17 15:32:44 CEST 2017</recvTime>
</_env>

_env after read:

<_env> 
<activation>wm69de9cbc0-7024-1f43-a9ea-fffffffcceb9</activation>
<businessContext>wm6:65fd1130-bea3-1eed-a988-fffffffccef2\sf287ba80-7bba-145e-a446-fffffffcceba\s9de9cbc0-7024-1f43-a9ea-fffffffcceb9:wm69de9cbc0-7024-1f43-a9ea-fffffffcceb9:null:IS_61:null</businessContext>
<locale></locale>
<tag>13</tag>
<pubId>10_252_12_88_5555_1499686653_J_jRQtEolDEurgAVIwwwADXaZQs__RequestReplyClient</pubId>
<uuid>a86ce5b0-b33f-11e7-898f-000000000022</uuid>
<eventID>43</eventID>
<recvTime>Tue Oct 17 15:32:44 CEST 2017</recvTime>
</_env>

I have also tried to set _env in response:

response/_env/activation = request/_env/activation
response/_env/businessContext = request/_env/businessContext
response/_env/tag = request/_env/tag
response/_env/destId = request/_env/pubId

but no success. Still the same exception is throwing: exception sending output 0 of 2: [PRT.0101.9130] Error during transport send

Are you sure that the request document is present in the input pipeline of c_step_send? It might be that it gets discarded because of the “pipeline express” setting. Check that the request doc is present.

After all, the PRT can’t do any magic. If the data is present, it should send the response.

If this does not help, then I have no further proposals. You’d have to open a case with SAG support. Or ask someone else on this forum.

Success!
request document was in prepare_response_error output, but in input c_step_send_response_error was only response document. After adding request in c_step_send_response_error input (both, request and response are inputs now) everything works like a charm

Thanks man!

Now i must find solution for reading request from process pipeline wihout writing to file.

I found solution, maybe a little bit dirty but it works without using minitor package, logging documents and process fields. I just need to create parallel track using parallel gateway after a_step_receive_request. Parellel track has request document in his pipeline and step which waits for signal from TimeoutHandler step, so in case of timeout or other exceptions everything is working.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/5db42f9c842a1e85bb558d3944971d65e36c61db.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/5db42f9c842a1e85bb558d3944971d65e36c61db.jpeg 2x" data-dominant-color="F1F5D5">

WorkingProcessOverview.JPG624×617 36.1 KB