Introduction

The Azure Logic Apps’ SAP Connector provides a trigger named “When a message is received”, which allows receiving IDoc messages and initiating a Logic App workflow – similar to how a BizTalk Receive Location triggers a process, either through orchestration or messaging.

When migrating workloads, avoiding the reimplementation or modification of existing code is key to reducing regression risk. In most integration scenarios, incoming messages are transformed—often using BizTalk maps, which ultimately rely on XSLT. In many cases, BizTalk developers bypass the visual mapper and write XSLTs directly.

Let’s take note of the typical XML structure of an IDoc received in BizTalk:

<Receive xmlns="ReceiveNamespace">
  <idocData>
    <EDI_DC40 xmlns="IDocNamespace">
		<TABNAM xmlns="CommonNamspace">EDI_DC40</TABNAM>
		...
    </EDI_DC40>
    <IDOC_ROOT xmlns="IDocNamespace">
		...
    </IDOC_ROOT>
  </idocData>
</Receive>

Wouldn’t it be ideal to reuse existing BizTalk XSLTs as-is? Let’s explore how to achieve that.

SAP trigger “When a message is received”

The SAP connector “When a message is received” trigger offers several parameters that are not thoroughly documented. Based on experience, I will present the combination of parameters that facilitates the reuse of BizTalk XSLTs.

IDoc Format Options

When configuring the trigger, the first parameter to set is “IDoc Format”, which offers three options:

• FlatFile
• SapPlainXml
• MicrosoftLobNamespaceXml

Since BizTalk is XML-centric and the goal is to reuse existing XSLTs, the relevant Idoc Format choices are SapPlainXml and MicrosoftLobNamespaceXml.

Let’s explore the behavior of each.

Option 1: SapPlainXml

When selecting the SapPlainXml IDoc format, the received IDoc is structured as XML without any namespace and without a <Receive> wrapper element:

<IdocTypeName>
	<IDOC BEGIN="1">
		<EDI_DC40 SEGMENT="1">
			...
		</EDI_DC40>
		<IDOC_ROOT SEGMENT="1"/>
	</IDOC>
</IdocTypeName>

This structure differs from what BizTalk expects, so existing XSLTs would require adjustments to be reused.

Option 2: MicrosoftLobNamespaceXml

When selecting the MicrosoftLobNamespaceXml IDoc format, the IDoc message is received in XML that closely matches the BizTalk structure. However, the namespaces are slightly different—specifically, the release number is missing.

For example, the Receive namespace might appear as:

http://Microsoft.LobServices.Sap/2007/03/Idoc/3/IDOCTYPENAME///Receive

Whereas in BizTalk it could be:

http://Microsoft.LobServices.Sap/2007/03/Idoc/3/IDOCTYPENAME//740/Receive

As a result, existing XSLTs will still require some namespace updates.

Option 3: MicrosoftLobNamespaceXml + Generate Namespace From Control Record = Yes

When selecting the MicrosoftLobNamespaceXml IDoc format and enabling the advanced parameter “Generate Namespace From Control Record”, the received message includes both the correct structure and the expected namespace, including the release number. This makes it compatible with BizTalk’s structure and allows direct reuse of existing XSLTs.

Here is how these parameters are presented in the worflow designer:

Note: In the Logic App code view, the “Generate Namespace From Control Record” parameter appears as EnforceControlRecordNamespace.
Example snippet from the code view:

{
  "type": "ServiceProvider",
  "inputs": {
    "parameters": {
      "idocFormat": "MicrosoftLobNamespaceXml",
      "DegreeOfParallelism": 10,
      "GatewayHost": "dummy",
      "GatewayService": "dummy",
      "ProgramId": "dummy",
      "EnforceControlRecordNamespace": true
    },
    "serviceProviderConfiguration": {
      "connectionName": "sap",
      "operationId": "SapTrigger",
      "serviceProviderId": "/serviceProviders/sap"
    }
  }
}

Conclusion

To ensure maximum compatibility with BizTalk and reuse existing XSLT artifacts with minimal changes, configure the SAP Logic App trigger as follows:

• IDoc Format: MicrosoftLobNamespaceXml
• Generate Namespace From Control Record: Yes (or EnforceControlRecordNamespace: true in code view)

This setup preserves the BizTalk-style message structure and namespace conventions, enabling a smoother migration path.