BizTalk pulling data from SAP but a field is incorrectly populating as 0

Last week I faced this issue while the BizTalk interface polling data from SAP system. BizTalk SAP adapter polls the RFC message data and converts a particular field value “300799” to “0”.

SAP Log

Message received in BizTalk

The first step was to enable the SAP RFC trace on BizTalk server to confirm if the SAP field value “300799” is making into the SAP client layer on the BizTalk machine. After enabling the traces and reproducing the issue we got the following

1. RFC trace shows the “300799” value made it into the SAP client layer on the BizTalk machine.
2. We also know that this value got converted to “0” by the time the message made it into the orchestration.

What happens in-between above two points is that the WCF-SAP adapter gets the message from the SAP client layer, constructs the XML, submits it to the BizTalk XMLReceive pipeline, which processes it and then submits it to the MessageBox database for the orchestration to process.

We enabled the message body tracking for receive pipeline to get the message going to pipeline and be able to isolate the issue between the SAP adapter and pipeline.

After enabling the tracking we found that the SAP adapter is creating the XML message with value “0” and passing it to XMLReceive pipeline.

Now the issue was within the SAP adapter, specifically with the SAP Data Type validation where the value will be converted to 0. To confirm, I just changes the value 0 to 1 for invalidNumcToInt, and now the XML message created by the adapter has the value “1” instead of “0”.

Now to debug the issue further to find the root cause we required to capture TTT trace or IDNA trace of the receive host process along with PSSDiag trace and RFC trace. The tool, Time Travel Tracing Diagnostic required to capture TTT trace is internal with Microsoft Support. So if you come across this kind of issue then you need to raise a ticket with the Microsoft Support.

The TTT trace successfully captured the problem as the support engineer can clearly see the number “300799” from the raw data.

The SAP RFC datatype of PARNRWE field is type 6: RFCTYPE_NUM instead of RFCTYPE_INT or other number types. According to SAP’s online document this datatype’s definition is:

RFCTYPE_NUM  = 6,  /* digits, fixed size, leading ‘0’ padded. */

According to the findings in TTT trace, the digit check was failed in function Microsoft.Adapters.SAP.SapMetadataUtilities.ConvertRfcBytesToXmlString(). The actual data returned from SAP is 3.0.0.7.9.9. . . trailing with whitespace instead of 0.0.0.0.3.0.0.7.9.9 .

As you can see,  the IsDigit() call to the 7th char (the index is 6 as it is zero indexed) in the string returned false because the 7th char is 0x20 (a whitespace) which is invalid digit. From the corresponding reflected code below, when digit check fails, the result will be set to the value of InvalidNumcToInt setting. That’s why you got the 0 result in this particular field.

Based on the analysis we had 3 options:

1. Change the value in SAP
2. Change the datatype in SAP
3. Set EnableSafeTyping to true in the SAP receive location properties so RFC_NUM (or NUMC) values are treated as string.

Note that if you go with option 3, enabling safe typing will also treat RFCTYPE_DATE (DATS) and RFC_TIME (TIMS) as string as well.

We went ahead with the option 3 to resolve the issue.