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.
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.
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.
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.
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.
