We have a partner who is sending in XML via AS2. We have set up a processing rule that calls a handler to base64 encode the payload and envelope it before publishing to oour EAI IS instance. Everything works fine until we get a document larger than 2MB. It appears that the EDIINT default rule ends up generating multiple TN docs of the payload and generating a recursion error. I have attached 3 screenshots of how things look.

First, a successful transaction. You will see 1. EDIINT 2. EDIINT MDN 3. Lean Web Settle 4. AS2 envelope.

Second, the same transaction with a payload > 2MB.You will see 1. EDIINT 2. EDIINT MDN 3. Lean Web Settle(DONE) 4. Lean Web Settle(DONE) 5. Lean Web Settle(ABORTED). 3 & 4 status is DONE but it never generates the AS2 Envelope.

Third the handler code.

In the log we see: java.lang.IllegalStateException: Processing recursion exceeded the allowed recursion depth of 1. The processing rule Process Inbound Lean XML invoked itself, most recently with document 56a1qi008mcsvmsl0000016k. Processing fails.

It only behaves this way with large documents.

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

webSettle_multi.jpg1101×873 157 KB

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files3/452b92286da3af044f9eec8573ff0cc3bf16bda9_2_1024x748.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/452b92286da3af044f9eec8573ff0cc3bf16bda9.jpeg 2x" data-dominant-color="E2E8E8">

webSettle_success.jpg1101×805 150 KB

which version of WM are you running?
Do you run it on 64bit OS? What’s the memory setting?
Looks like a out -of-memory issue. If you are running on 64 bit OS, just increase the memory setting.

We are running version 8.2. We do not see any out of memory issues at all. If I reprocess the first Web Settle that comes in it creates the envelope and goes through. Same thing if I step through in Designer by supplying the internal id to the first step wn.tn.doc:view.

setenv.sh:

JAVA_MIN_MEM=256M
JAVA_MAX_MEM=4096M
JAVA_MEMSET=“-ms${JAVA_MIN_MEM} -mx${JAVA_MAX_MEM}”

That should be enough for a 2MB file.

if you click on the ABORTED document, what do you see on the activity log?

An internal error prevented processing from finishing normally on this document. The aborted rule was Process Inbound Lean XML, and the original error message was java.lang.IllegalStateException: Processing recursion exceeded the allowed recursion depth of 1. The processing rule Process Inbound Lean XML invoked itself, most recently with document 56a1qi008md2dset000001cj. Processing fails.

my guess is that the routeXML service is rerouting the “Lean Web Settle” again instead of the new AS2.
after the base64Encode step, try to drop bizdoc from the pipeline.

We never convert the extraccted content part bytes to an IS document. It gets extracted, encoded, and dropped. routeXML expects node as input and we never take the contentPart bytes to node.

See attached the routeXML step.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/6669f53f2ad9439b95619e160009d3c6d1ee79b6.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/6669f53f2ad9439b95619e160009d3c6d1ee79b6.jpeg 2x" data-dominant-color="F2F2F2">

RouteXML_step.jpg969×327 53.4 KB

The thing that really perplexes me is that everything works correctly for anything under 2MB. For the life of me I can not explain how our handle service could be creating the duplicate documents and it is not throwing any exceptions. The activity log for the first two attached.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/42c5d722abe6837a4622551245a063a0922ab538.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/42c5d722abe6837a4622551245a063a0922ab538.jpeg 2x" data-dominant-color="E1E7E9">

HandlerActivity.jpg770×370 63 KB

RESOLUTION:

After many rounds with SAG support it was discovered that TN puts a pipeline variable called $reservation in the pipeline at RUNTIME when using large file handling. $reservation is not present at design time or in debug. Apparently, $reservation is a reference to the original document in tspace that triggered the processing rule. When we were calling routeXML it was using $reservation instead of the envelope we had mapped to document input. This created the duplicate document in TN, re-trigered the processing rule all from the same thread, thus causing the recursion and finally aborting. In order to resolve we had to create a document, $reservation, in Designer and drop it in the step before routeXML.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/3cb04ed5b67c4eeafa5d58e7ac619ba4d06f2a65.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/3cb04ed5b67c4eeafa5d58e7ac619ba4d06f2a65.jpeg 2x" data-dominant-color="F3F4F4">

processNodeIteration2.jpg838×629 74.3 KB

Thanks for sharing the resolution, helps to understand such mysterious behavior.

This is really great information. User would came to know about runtime varaible & issue’s

we faced same while posting data to TN using iterator. TN will generate document “flag” @ runtime, which replace our existing document flag.

Thanks ID for sharing the info and $reservation runtime var resolution.

HTH,
RMG