Hello! we are doing a migration and as part of this my team installed DP 10.5.0.2 in a virtual machine. 

We are currently facing a problem for AS2 inbound messages, we get a Parse Error. 

Checking the logs I can find a little more information where the error indicates Illegal Character 'T' at offset 0. 

This character 'T' lines up with the first character on the messsage content. So it seems it is reading the content of the message and encountering an error with it. 

It is strange because on the DP instance we are migrating from (in Kubernetes), the same message is succesfull, we exported and imported all configuration from this instance, and I have been comparing all the configurations I can think off on both DataPower instances but with no success. 

(AS2 Handler, B2B Gateway, Partner Profiles, B2B routing file, etc...

Has anyone encountered this issue before or have an idea of what could be causing it? 

Thanks!

Is there, maybe, an IP based ACL at the destination that may be rejecting the requests from the new appliances?

As Joseph suggested, the culprit might be something else than the actual DataPower config. Did you try the XML file capture to see what the payload actually is? You can also try writing the received INPUT to a temp file using eg. GatewayScript action.

We fought these mysterious errors in the XML/DataPower world so much I eventually wrote an "isXML.js" to intercept any problems prior to processing XML.  It writes the payload as an error in the logs or passes it on.    Then I went so far as to give it a parameter to write the non-XML payload into XML so it would pass as XML, so at least the full text could be seen in a probe or something.

I think the error coming back from the server is going to be some plaintext starting with "The" or "There", like in, 'The request was not found", or "There was an error processing the request.".  

Hello! thanks for your answer, yes, the message contains something along the lines of "Test message" or "Test" but also happens when attempting valid documents that work on our current instance.

From what I'm reading, I don't think that it's the ACL. I think this is a confusing error. As you note, the transform completed and it's with the parse the the runtime results. Therefore, you'd need to look into this XSLT and how/whether it uses dp:parse. It seems odd that it work on physical but not on virtual. One things missing that help assist community member (and in cases like migration) are:

1. What firmware versions are involved - to rule out different versions
2. What platforms are involve - which MTM for physical and whether VMware, Linux, or container for virtual

One this not mentioned and can assist are both of the following that are standard troubleshoot.

• Set the logging level to "debug"
• Enable the probe to capture a translation

When the transaction is viewed in the probe, you should be able to see all things

------------------------------
F Hackerman
------------------------------

I'm assuming that you are using the B2B Module and this transaction is an inbound AS2 transaction coming into the B2B Gateway? The error message is standard for the B2B Gateway as it tries to parse the incoming message using the EDI header record parser, XML Parser and then it assumes that it is a binary message. 

What confuses me is that you are migrating from K8S and B2B is not supported on K8S, only standard Docker. See Available modules by product - IBM Documentation

Hello! 

Thank you all for your answers. 

About the versions used: 

New server, CPC VM with RHEL 8: DP IDG.10.5.0.2
Old server on IBM Cloud Kubernetes: IDG.10.0.1.11

I noticed a difference between the two DP instances in the transformation rule of a processing policy: 

The new (failing) had 'INPUT' and 'OUTPUT' on their respective fields, and I changed it to NULL to match with the K8s instance. Do you think this may be related to the issue? 

Unfortunately we were not able to get more testing today

I will try getting more logs and enabling the probes and come back with more information. Should I continue on this thread or open a new one? 

Thanks! 

>> I changed it to NULL to match with the K8s instance. Do you think this may be related to the issue? 

Certainly, since having INPUT as NULL means the policy won't attempt to parse anything on INPUT.    I suspect the DSGXB62_Test_PP.xsl isn't attempting to process anything in the flow.

Just closing this, and for the record in case is of use to anyone. 

The solution above solved the issue.

The content of DSGXB62_Test_PP.xsl I can not share, but it seems to be used for routing to different destinations, instead of processing the content of the file.