Create workflows for common SAP integration scenarios in Azure Logic Apps

Applies to: Azure Logic Apps (Consumption + Standard)

This how-to guide shows how to create example logic app workflows for some common SAP integration scenarios using Azure Logic Apps and the SAP connector.

Both Standard and Consumption logic app workflows offer the SAP managed connector that's hosted and run in multitenant Azure. Standard workflows also offer the SAP built-in service provider connector that's hosted and run in single-tenant Azure Logic Apps. If you create and host a Consumption workflow in an integration service environment (ISE), you can also use the SAP connector's ISE-native version. For more information, see Connector technical reference.

Prerequisites

• Before you start, make sure to review and meet the SAP connector requirements for your specific scenario.

Receive messages from SAP

The following example logic app workflow triggers when the workflow's SAP trigger receives a message from an SAP server.

Add an SAP trigger

Based on whether you have a Consumption workflow in multitenant Azure Logic Apps or a Standard workflow in single-tenant Azure Logic Apps, follow the corresponding steps:

Receive IDoc packets from SAP

To receive IDoc packets, which are batches or groups of IDocs, the SAP trigger doesn't need extra configuration. However, to process each item in an IDoc packet after the trigger receives the packet, you have to implement a few more steps to split the packet into individual IDocs by setting up SAP to send IDocs in packets.

The following example workflow shows how to extract individual IDocs from a packet by using the xpath() function:

1. Before you start, you need a Consumption or Standard logic app workflow with an SAP trigger. If your workflow doesn't already start with this trigger, follow the previous steps in this guide to add the SAP trigger that can receive messages to your workflow.

2. To immediately reply to your SAP server with the SAP request status, add the following response action, based on whether you use an SAP managed trigger or SAP built-in trigger:

   • SAP managed trigger: For this trigger, add a Response action to your workflow.

     In the Response action, use one of the following status codes (statusCode):

     Status code	Description
     202 Accepted	The request was accepted for processing, but processing isn't complete yet.
     204 No Content	The server successfully fulfilled the request, and there's no additional content to send in the response payload body.
     200 OK	This status code always contains a payload, even if the server generates a payload body of zero length.

   • SAP built-in trigger: For this trigger, add the Respond to SAP server action to your workflow.

   Note

   As a best practice, add the response action immediately after the trigger to free up the communication channel with your SAP server.

3. Get the root namespace from the XML IDoc that your workflow receives from SAP.

   1. To extract this namespace from the XML document and store the namespace in a local string variable, add the Initialize variable action.

   2. Rename the action's title to Get namespace for root node in received IDoc.

   3. Provide a name for the variable, and set the type to String.

   4. In the action's Value parameter, select inside the edit box, open the expression or function editor, and create the following expression using the xpath() function:

      xpath(xml(triggerBody()?['Content']), 'namespace-uri(/*)')

      Consumption workflow

      

      Standard workflow

      

      When you're done, the expression resolves and now appears as the following format:

      

4. To extract an individual IDoc by storing the IDoc collection in a local array variable, follow these steps:

   1. Add another Initialize variable action.

   2. Rename the action's title to Get array with IDoc data elements.

   3. Provide a name for the variable, and set the type to Array.

      The array variable makes each IDoc available for your workflow to process individually by enumerating over the collection.

   4. In the action's Value parameter, select inside the edit box, open the expression or function editor, and create the following xpath() expression:

      xpath(xml(triggerBody()?['Content']), '/*[local-name()="Receive"]/*[local-name()="idocData"]')

      When you're done, the expression resolves and now appears as the following format:

      Consumption workflow

      

      In this example, the following workflow transfers each IDoc to an SFTP server by using a Control action named For each and the SFTP-SSH action named Create file. Each IDoc must include the root namespace, which is the reason why the file content is wrapped inside a <Receive></Receive> element along with the root namespace before sending the IDoc to the downstream app, or SFTP server in this case.

      

      Note

      For Consumption workflows, this pattern is available as a quickstart template, which you can select from the template gallery when you create a Consumption logic app resource and blank workflow. Or, when the workflow designer is open, on designer toolbar, select Templates.

      

      Standard workflow

      

      In this example, the following workflow transfers each IDoc to an SFTP server by using a Control action named For each and the SFTP-SSH action named Create file. Each IDoc must include the root namespace, which is the reason why the file content is wrapped inside a <Receive></Receive> element along with the root namespace before sending the IDoc to the downstream app, or SFTP server in this case.

      

---

Filter received messages with SAP actions

If you use the SAP managed connector under the trigger in your workflow, set up a way to explicitly filter out any unwanted actions from your SAP server, based on the root node namespace in the received XML payload. You can provide a list (array) with a single or multiple SAP actions. By default, this array is empty, which means that your workflow receives all the messages from your SAP server without filtering. When you set up the array filter, the trigger receives messages only from the specified SAP action types and rejects all other messages from your SAP server. However, this filter doesn't affect whether the typing of the received payload is weak or strong. Any SAP action filtering happens at the level of the SAP Adapter for your on-premises data gateway. For more information, review how to test sending IDocs to Azure Logic Apps from SAP.

Set up asynchronous request-reply pattern for triggers

The SAP managed connector supports Azure's asynchronous request-reply pattern for Azure Logic Apps triggers. You can use this pattern to create successful requests that would otherwise fail with the default synchronous request-reply pattern.

If you enable an asynchronous response for your Response action, your workflow can respond with a 202 Accepted reply after accepting a request for processing. The reply contains a location header that you can use to retrieve the final state of your request.

To configure an asynchronous request-reply pattern for your workflow using the SAP connector, follow these steps:

1. In the designer, open your logic app workflow. Confirm that your workflow starts with an SAP trigger.

2. In your workflow, find the Response action, and open that action's Settings.

3. Based on whether you have a Consumption or Standard workflow, follow the corresponding steps:

   • Consumption: Under Asynchronous Response, turn the setting from Off to On, and select Done.
   • Standard: Expand Networking, and under Asynchronous Response, turn the setting from Off to On.

4. Save your workflow.

Send IDocs to SAP

To create a logic app workflow that sends an IDoc to an SAP server and returns a response, follow these examples:

1. Create a logic app workflow that's triggered by an HTTP request.
2. Add an SAP action to your workflow for sending an IDoc to SAP.
3. Add a response action to your workflow.
4. Create a remote function call (RFC) request-response pattern, if you're using an RFC to receive replies from SAP ABAP.
5. Test your workflow.

Add the Request trigger

To have your workflow receive IDocs from SAP over XML HTTP, you can use the Request built-in trigger. This trigger creates an endpoint with a URL where your SAP server can send HTTP POST requests to your workflow. When your workflow receives these requests, the trigger fires and runs the next step in your workflow.

To receive IDocs over Common Programming Interface Communication (CPIC) as plain XML or as a flat file, review the section, Receive message from SAP.

Based on whether you have a Consumption workflow in multitenant Azure Logic Apps or a Standard workflow in single-tenant Azure Logic Apps, follow the corresponding steps:

Add an SAP action to send an IDoc

Next, create an action to send your IDoc to SAP when the workflow's Request trigger fires. Based on whether you have a Consumption workflow in multitenant Azure Logic Apps or a Standard workflow in single-tenant Azure Logic Apps, follow the corresponding steps:

Send flat file IDocs to SAP server (Managed connector only)

To send an IDoc using a flat file schema when you use the SAP managed connector, you can wrap the IDoc in an XML envelope and follow the general steps to add an SAP action to send an IDoc, but with the following changes.

Wrap IDoc with XML envelope

1. In the SAP action that you use to send the message, use the following URI:

   http://Microsoft.LobServices.Sap/2007/03/Idoc/SendIdoc

2. Format your input message with an XML envelope.

The following example shows a sample XML payload:

<SendIdoc xmlns="http://Microsoft.LobServices.Sap/2007/03/Idoc/">
  <idocData>EDI_DC 3000000001017945375750 30INVOIC011BTSVLINV30KUABCABCFPPC LDCA X004010810 4 SAPMSX LSEDI ABCABCFPPC 000d3ae4-723e-1edb-9ca4-cc017365c9fd 20210217054521INVOICINVOIC01ZINVOIC2RE 20210217054520
E2EDK010013000000001017945375000001E2EDK01001000000010 ABCABC1.00000 0060 INVO9988298128 298.000 298.000 LB Z4LR EN 0005065828 L
E2EDKA1 3000000001017945375000002E2EDKA1 000000020 RS ABCABCFPPC 0005065828 ABCABCABC ABCABC Inc. Limited Risk Distributor ABCABC 1950 ABCABCABCA Blvd ABCABAABCAB L5N8L9 CA ABCABC E ON V-ABCABC LDCA
E2EDKA1 3000000001017945375000003E2EDKA1 000000020 AG 0005065828 ABCABCFPPC ABCABC ABCABC ABCABC - FPP ONLY 88 ABCABC Crescent ABCABAABCAB L5R 4A2 CA ABCABC 111 111 1111 E ON ABCABCFPPC EN
E2EDKA1 3000000001017945375000004E2EDKA1 000000020 RE 0005065828 ABCABCFPPC ABCABC ABCABC ABCABC - FPP ONLY 88 ABCABC Crescent ABCABAABCAB L5R 4A2 CA ABCABC 111 111 1111 E ON ABCABCFPPC EN
E2EDKA1 3000000001017945375000005E2EDKA1 000000020 RG 0005065828 ABCABCFPPC ABCABC ABCABC ABCABC - FPP ONLY 88 ABCABC Crescent ABCABAABCAB L5R 4A2 CA ABCABC 111 111 1111 E ON ABCABCFPPC EN
E2EDKA1 3000000001017945375000006E2EDKA1 000000020 WE 0005001847 41 ABCABC ABCABC INC (ABCABC) DC A. ABCABCAB 88 ABCABC CRESCENT ABCABAABCAB L5R 4A2 CA ABCABC 111-111-1111 E ON ABCABCFPPC EN
E2EDKA1 3000000001017945375000007E2EDKA1 000000020 Z3 0005533050 ABCABCABC ABCABC Inc. ABCA Bank Swift Code -ABCABCABCAB Sort Code - 1950 ABCABCABCA Blvd. Acc No -1111111111 ABCABAABCAB L5N8L9 CA ABCABC E ON ABCABCFPPC EN
E2EDKA1 3000000001017945375000008E2EDKA1 000000020 BK 1075 ABCABCABC ABCABC Inc 1950 ABCABCABCA Blvd ABCABAABCAB ON L5N 8L9 CA ABCABC (111) 111-1111 (111) 111-1111 ON
E2EDKA1 3000000001017945375000009E2EDKA1 000000020 CR 1075 CONTACT ABCABCABC 1950 ABCABCABCA Blvd ABCABAABCAB ON L5N 8L9 CA ABCABC (111) 111-1111 (111) 111-1111 ON
E2EDK02 3000000001017945375000010E2EDK02 000000020 0099988298128 20210217
E2EDK02 3000000001017945375000011E2EDK02 000000020 00140-N6260-S 20210205
E2EDK02 3000000001017945375000012E2EDK02 000000020 0026336270425 20210217
E2EDK02 3000000001017945375000013E2EDK02 000000020 0128026580537 20210224
E2EDK02 3000000001017945375000014E2EDK02 000000020 01740-N6260-S
E2EDK02 3000000001017945375000015E2EDK02 000000020 900IAC
E2EDK02 3000000001017945375000016E2EDK02 000000020 901ZSH
E2EDK02 3000000001017945375000017E2EDK02 000000020 9078026580537 20210217
E2EDK03 3000000001017945375000018E2EDK03 000000020 02620210217
E2EDK03 3000000001017945375000019E2EDK03 000000020 00120210224
E2EDK03 3000000001017945375000020E2EDK03 000000020 02220210205
E2EDK03 3000000001017945375000021E2EDK03 000000020 01220210217
E2EDK03 3000000001017945375000022E2EDK03 000000020 01120210217
E2EDK03 3000000001017945375000023E2EDK03 000000020 02420210217
E2EDK03 3000000001017945375000024E2EDK03 000000020 02820210418
E2EDK03 3000000001017945375000025E2EDK03 000000020 04820210217
E2EDK17 3000000001017945375000026E2EDK17 000000020 001DDPDelivered Duty Paid
E2EDK17 3000000001017945375000027E2EDK17 000000020 002DDPdestination
E2EDK18 3000000001017945375000028E2EDK18 000000020 00160 0 Up to 04/18/2021 without deduction
E2EDK28 3000000001017945375000029E2EDK28 000000020 CA BOFACATT Bank of ABCABAB ABCABC ABCABAB 50127217 ABCABCABC ABCABC Inc.
E2EDK28 3000000001017945375000030E2EDK28 000000020 CA 026000082 ABCAbank ABCABC ABCABAB 201456700OLD ABCABCABC ABCABC Inc.
E2EDK28 3000000001017945375000031E2EDK28 000000020 GB ABCAGB2L ABCAbank N.A ABCABA E14, 5LB GB63ABCA18500803115593 ABCABCABC ABCABC Inc. GB63ABCA18500803115593
E2EDK28 3000000001017945375000032E2EDK28 000000020 CA 020012328 ABCABANK ABCABC ABCABAB ON M5J 2M3 2014567007 ABCABCABC ABCABC Inc.
E2EDK28 3000000001017945375000033E2EDK28 000000020 CA 03722010 ABCABABC ABCABABC Bank of Commerce ABCABAABCAB 64-04812 ABCABCABC ABCABC Inc.
E2EDK28 3000000001017945375000034E2EDK28 000000020 IE IHCC In-House Cash Center IHCC1075 ABCABCABC ABCABC Inc.
E2EDK28 3000000001017945375000035E2EDK28 000000020 CA 000300002 ABCAB Bank of ABCABC ABCABAB 0021520584OLD ABCABCABC ABCABC Inc.
E2EDK28 3000000001017945375000036E2EDK28 000000020 US USCC US Cash Center (IHC) city USCC1075 ABCABCABC ABCABC Inc.
E2EDK29 3000000001017945375000037E2EDK29 000000020 0064848944US A CAD CA ABCABC CA United States US CA A Air Air
E2EDKT1 3000000001017945375000038E2EDKT1 000000020 ZJ32E EN
E2EDKT2 3000000001017945375000039E2EDKT2 000038030 GST/HST877845941RT0001 *
E2EDKT2 3000000001017945375000040E2EDKT2 000038030 QST1021036966TQ0001 *
E2EDKT1 3000000001017945375000041E2EDKT1 000000020 Z4VL
E2EDKT2 3000000001017945375000042E2EDKT2 000041030 0.000 *
E2EDKT1 3000000001017945375000043E2EDKT1 000000020 Z4VH
E2EDKT2 3000000001017945375000044E2EDKT2 000043030 *
E2EDK14 3000000001017945375000045E2EDK14 000000020 008LDCA
E2EDK14 3000000001017945375000046E2EDK14 000000020 00710
E2EDK14 3000000001017945375000047E2EDK14 000000020 00610
E2EDK14 3000000001017945375000048E2EDK14 000000020 015Z4F2
E2EDK14 3000000001017945375000049E2EDK14 000000020 0031075
E2EDK14 3000000001017945375000050E2EDK14 000000020 021M
E2EDK14 3000000001017945375000051E2EDK14 000000020 0161075
E2EDK14 3000000001017945375000052E2EDK14 000000020 962M
E2EDP010013000000001017945375000053E2EDP01001000000020 000011 2980.000 EA 298.000 LB MOUSE 298.000 Z4TN 4260
E2EDP02 3000000001017945375000054E2EDP02 000053030 00140-N6260-S 00000120210205 DFUE
E2EDP02 3000000001017945375000055E2EDP02 000053030 0026336270425 00001120210217
E2EDP02 3000000001017945375000056E2EDP02 000053030 0168026580537 00001020210224
E2EDP02 3000000001017945375000057E2EDP02 000053030 9100000 00000120210205 DFUE
E2EDP02 3000000001017945375000058E2EDP02 000053030 911A 00000120210205 DFUE
E2EDP02 3000000001017945375000059E2EDP02 000053030 912PP 00000120210205 DFUE
E2EDP02 3000000001017945375000060E2EDP02 000053030 91300 00000120210205 DFUE
E2EDP02 3000000001017945375000061E2EDP02 000053030 914CONTACT ABCABCABC 00000120210205 DFUE
E2EDP02 3000000001017945375000062E2EDP02 000053030 963 00000120210205 DFUE
E2EDP02 3000000001017945375000063E2EDP02 000053030 965 00000120210205 DFUE
E2EDP02 3000000001017945375000064E2EDP02 000053030 9666336270425 00000120210205 DFUE
E2EDP02 3000000001017945375000065E2EDP02 000053030 9078026580537 00001020210205 DFUE
E2EDP03 3000000001017945375000066E2EDP03 000053030 02920210217
E2EDP03 3000000001017945375000067E2EDP03 000053030 00120210224
E2EDP03 3000000001017945375000068E2EDP03 000053030 01120210217
E2EDP03 3000000001017945375000069E2EDP03 000053030 02520210217
E2EDP03 3000000001017945375000070E2EDP03 000053030 02720210217
E2EDP03 3000000001017945375000071E2EDP03 000053030 02320210217
E2EDP03 3000000001017945375000072E2EDP03 000053030 02220210205
E2EDP19 3000000001017945375000073E2EDP19 000053030 001418VVZ
E2EDP19 3000000001017945375000074E2EDP19 000053030 002RJR-00001 AB ABCABCABC Mouse FORBUS BLUETOOTH
E2EDP19 3000000001017945375000075E2EDP19 000053030 0078471609000
E2EDP19 3000000001017945375000076E2EDP19 000053030 003889842532685
E2EDP19 3000000001017945375000077E2EDP19 000053030 011CN
E2EDP26 3000000001017945375000078E2EDP26 000053030 00459064.20
E2EDP26 3000000001017945375000079E2EDP26 000053030 00352269.20
E2EDP26 3000000001017945375000080E2EDP26 000053030 01052269.20
E2EDP26 3000000001017945375000081E2EDP26 000053030 01152269.20
E2EDP26 3000000001017945375000082E2EDP26 000053030 0126795.00
E2EDP26 3000000001017945375000083E2EDP26 000053030 01552269.20
E2EDP26 3000000001017945375000084E2EDP26 000053030 00117.54
E2EDP26 3000000001017945375000085E2EDP26 000053030 00252269.20
E2EDP26 3000000001017945375000086E2EDP26 000053030 940 2980.000
E2EDP26 3000000001017945375000087E2EDP26 000053030 939 2980.000
E2EDP05 3000000001017945375000088E2EDP05 000053030 + Z400MS List Price 52269.20 17.54 1 EA CAD 2980
E2EDP05 3000000001017945375000089E2EDP05 000053030 + XR1 Tax Jur Code Level 6795.00 13.000 52269.20
E2EDP05 3000000001017945375000090E2EDP05 000053030 + Tax Subtotal1 6795.00 2.28 1 EA CAD 2980
E2EDP05 3000000001017945375000091E2EDP05 000053030 + Taxable Amount + TaxSubtotal1 59064.20 19.82 1 EA CAD 2980
E2EDP04 3000000001017945375000092E2EDP04 000053030 CX 13.000 6795.00 7000000000
E2EDP04 3000000001017945375000093E2EDP04 000053030 CX 0 0 7001500000
E2EDP04 3000000001017945375000094E2EDP04 000053030 CX 0 0 7001505690
E2EDP28 3000000001017945375000095E2EDP28 000053030 00648489440000108471609000 CN CN ABCAB ZZ 298.000 298.000 LB US 400 United Stat KY
E2EDPT1 3000000001017945375000096E2EDPT1 000053030 0001E EN
E2EDPT2 3000000001017945375000097E2EDPT2 000096040 AB ABCABCABC Mouse forBus Bluetooth EN/XC/XD/XX Hdwr Black For Bsnss *
E2EDS01 3000000001017945375000098E2EDS01 000000020 0011
E2EDS01 3000000001017945375000099E2EDS01 000000020 01259064.20 CAD
E2EDS01 3000000001017945375000100E2EDS01 000000020 0056795.00 CAD
E2EDS01 3000000001017945375000101E2EDS01 000000020 01159064.20 CAD
E2EDS01 3000000001017945375000102E2EDS01 000000020 01052269.20 CAD
E2EDS01 3000000001017945375000103E2EDS01 000000020 94200000 CAD
E2EDS01 3000000001017945375000104E2EDS01 000000020 9440.00 CAD
E2EDS01 3000000001017945375000105E2EDS01 000000020 9450.00 CAD
E2EDS01 3000000001017945375000106E2EDS01 000000020 94659064.20 CAD
E2EDS01 3000000001017945375000107E2EDS01 000000020 94752269.20 CAD
E2EDS01 3000000001017945375000108E2EDS01 000000020 EXT
Z2XSK010003000000001017945375000109Z2XSK01000000108030 Z400 52269.20
Z2XSK010003000000001017945375000110Z2XSK01000000108030 XR1 13.000 6795.00 CX
</idocData>
</SendIdoc>

Add a response action

Now, set up your workflow to return the results from your SAP server to the original requestor. For this task, follow these steps:

Create a remote function call (RFC) request-response pattern

For the Consumption workflows that use the SAP managed connector, if you have to receive replies by using a remote function call (RFC) to Azure Logic Apps from SAP ABAP, you must implement a request and response pattern. To receive IDocs in your workflow when you use the Request trigger, make sure that the workflow's first action is a Response action that uses the 200 OK status code without any content. This recommended step immediately completes the SAP Logical Unit of Work (LUW) asynchronous transfer over tRFC, which leaves the SAP CPIC conversation available again. You can then add more actions to your workflow for processing the received IDoc without blocking later transfers.

To implement a request and response pattern, you must first discover the RFC schema using the generate schema command. The generated schema has two possible root nodes:

• The request node, which is the call that you receive from SAP
• The response node, which is your reply back to SAP

In the following example, the STFC_CONNECTION RFC module generates a request and response pattern. The request XML is parsed to extract a node value where SAP requests <ECHOTEXT>. The response inserts the current timestamp as a dynamic value. You receive a similar response when you send a STFC_CONNECTION RFC from a logic app workflow to SAP.

<STFC_CONNECTIONResponse xmlns="http://Microsoft.LobServices.Sap/2007/03/Rfc/">
  <ECHOTEXT>@{first(xpath(xml(triggerBody()?['Content']), '/*[local-name()="STFC_CONNECTION"]/*[local-name()="REQUTEXT"]/text()'))}</ECHOTEXT>
  <RESPTEXT>Azure Logic Apps @{utcNow()}</RESPTEXT>
</STFC_CONNECTIONResponse>

Test your workflow

You've now created a workflow that can send IDocs and communicate with your SAP server. Now that you've set up an SAP connection for your workflow, you can try experimenting with BAPI and RFC.

Workflow timeout issues

Your workflow times out in any of the following scenarios:

• All the steps required for the response don't finish within the request timeout limit. If this condition happens, requests might get blocked. To help you diagnose problems, learn how to check and monitor your logic app workflows.

• Your SAP system's processing mode is set to the default Trigger immediately setting, which causes your SAP system to block the inbound call for IDoc transmission until an IDoc finishes processing.

  If your SAP system is under load, for example, when your workflow sends a batch of IDocs all at one time to SAP, the queued IDoc calls time out. The default processing mode causes your SAP system to block the inbound call for IDoc transmission until an IDoc finishes processing. In Azure Logic Apps, workflow actions have a 2-minute timeout, by default.

  To resolve this problem, follow the steps in the Prerequisites section that change the setting to Trigger by background program.

Safe typing

By default, when you create a connection for the SAP managed operation, strong typing is used to check for invalid values by performing XML validation against the schema. This behavior can help you detect issues earlier. The Safe Typing option is available for backward compatibility and only checks the string length. If you choose Safe Typing, the DATS type and TIMS type in SAP are treated as strings rather than as their XML equivalents, xs:date and xs:time, where xmlns:xs="http://www.w3.org/2001/XMLSchema". Safe typing affects the behavior for all schema generation, the send message for both the "been sent" payload and the "been received" response, and the trigger.

When strong typing is used (Safe Typing isn't enabled), the schema maps the DATS and TIMS types to more straightforward XML types:

<xs:element minOccurs="0" maxOccurs="1" name="UPDDAT" nillable="true" type="xs:date"/>
<xs:element minOccurs="0" maxOccurs="1" name="UPDTIM" nillable="true" type="xs:time"/>

When you send messages using strong typing, the DATS and TIMS response complies with the matching XML type format:

<DATE>9999-12-31</DATE>
<TIME>23:59:59</TIME>

When Safe Typing is enabled, the schema maps the DATS and TIMS types to XML string fields with length restrictions only, for example:

<xs:element minOccurs="0" maxOccurs="1" name="UPDDAT" nillable="true">
  <xs:simpleType>
    <xs:restriction base="xs:string">
      <xs:maxLength value="8" />
    </xs:restriction>
  </xs:simpleType>
</xs:element>
<xs:element minOccurs="0" maxOccurs="1" name="UPDTIM" nillable="true">
  <xs:simpleType>
    <xs:restriction base="xs:string">
      <xs:maxLength value="6" />
    </xs:restriction>
  </xs:simpleType>
</xs:element>

When messages are sent with Safe Typing enabled, the DATS and TIMS response looks like this example:

<DATE>99991231</DATE>
<TIME>235959</TIME>

Advanced scenarios

Change language headers for sending data to SAP

When you connect to SAP from Azure Logic Apps, English is the default language used by the SAP connection for sending data to your SAP server. However, the SAP managed connector and SAP built-in connector handle changing and saving the language used in different ways.

• When you create a connection with SAP built-in connector, the connection parameters let you specify and save the language parameter value as part of the SAP connection parameters.

• When you create a connection with the SAP managed connector, the connection parameters don't have language parameter. So, during this time, you can't specify or the language to use for sending data to your SAP server. Instead, at both workflow design time and run time, the connector uses your web browser's local language from each request that's sent to your server. For example, if your browser is set to Portuguese, Azure Logic Apps creates and tests the SAP connection with Portuguese, but doesn't save the connection with that language.

  However, you can set the language for your connection by using the standard HTTP header Accept-Language with your inbound requests. Most web browsers add an Accept-Language header based on your locale settings. The web browser applies this header when you create a new SAP connection in the workflow designer. So, you can either update your web browser's settings to use your preferred language, or you can create your SAP connection using Azure Resource Manager instead of the workflow designer.

  For example, you can send a request with the Accept-Language header to your logic app workflow by using the Request trigger named When a HTTP request is received. All the actions in your workflow receive the header. Then, SAP uses the specified languages in its system messages, such as BAPI error messages. If you don't pass an Accept-Language header at run time, by default, English is used.

  If you use the Accept-Language header, you might get the following error: Please check your account info and/or permissions and try again. In this case, check the SAP component's error logs instead. The error actually happens in the SAP component that uses the header, so you might get one of these error messages:

  • "SAP.Middleware.Connector.RfcLogonException: Select one of the installed languages"

  • "SAP.Middleware.Connector.RfcAbapMessageException: Select one of the installed languages"

Confirm transaction separately and explicitly

When you send transactions to SAP from Azure Logic Apps, this exchange happens in two steps as described in the SAP document, Transactional RFC Server Programs.

By default, the SAP managed connector action named Send message to SAP handles both the steps to transfer the function and confirm the transaction in a single call. You also have the option to decouple these steps. The capability to decouple the transfer and confirmation steps is useful for scenarios where you don't want to duplicate transactions in SAP. Such scenarios include failures that happen due to causes such as network issues.

You can send an IDoc without automatically confirming the transaction using the SAP managed connector action named [IDOC] Send document to SAP. You can then explicitly confirm the transaction using the SAP managed connector action named [IDOC - RFC] Confirm transaction Id. When your workflow separately confirms the transaction in a different step, the SAP system completes the transaction only once.

In Standard workflows, the SAP built-in connector also has actions that separately handle the transfer and confirmation steps, specifically, [IDoc] Send document to SAP and [IDOC - RFC] Confirm transaction Id.

The following example workflow shows this pattern:

1. Create and open a Consumption or Standard logic app with a blank workflow in the designer. Add the Request trigger.

2. To help avoid sending duplicate IDocs to SAP, follow these alternative steps to create and use an IDoc transaction ID in your SAP actions.

3. Add the SAP action named [IDOC] Send document to SAP to your workflow. Provide the information for the IDoc that you send to your SAP system plus the following values:

   Parameter	Value	Description
   Confirm TID	No	Don't automatically confirm the transaction ID, which explicitly happens in a separate step.
   Transaction Id GUID	<IDoc-transaction-ID>	If this parameter doesn't automatically appear, open the Add new parameters list, and select the parameter. You can either manually specify this value, or the connector can automatically generate this GUID as an output from the [IDOC] Send document to SAP action. This example leaves this parameter empty to automatically generate the GUID.

   Consumption workflow

   

   Standard workflow

   

4. On the SAP action named [IDOC] Send document to SAP, open Settings to review the Retry Policy.

   The Default option is the recommended policy, but you can select a custom policy for your specific needs. If you choose to use a custom policy, set up at least one retry to overcome temporary network outages.

5. Now, add the SAP action named [IDOC - RFC] Confirm transaction Id.

   1. In the Transaction ID parameter, select inside the edit box to open the dynamic content list.

   2. From the list, under [IDOC] Send document to SAP, select the Transaction Id value, which is the output from the previous SAP action.

      Consumption workflow

      

      Standard workflow

      

   After this step runs, the current transaction is marked complete at both ends, on the SAP connector side and on SAP system side.

Avoid sending duplicate IDocs with a transaction ID variable

If you experience a problem with your workflow sending duplicate IDocs to SAP, you can create a string variable that serves as an IDoc transaction identifier. You can then use this identifier to help prevent duplicate network transmissions in conditions such as temporary outages, network issues, or lost acknowledgments.

1. In the designer, after you add the Request trigger, and before you add the SAP action named [IDOC] Send document to SAP, add the action named Initialize variable to your workflow.

2. Rename the action to Create IDoc transaction ID.

3. In the action information box, provide the following parameter values:

   Parameter	Value	Description
   Name	<variable-name>	A name for your variable, for example, IDocTransactionID
   Type	String	The variable type
   Value	guid()	Select inside the edit box, open the expression or function editor, and enter guid(). Save your changes. The Value parameter is now set to the guid() function, which generates a GUID.

   Consumption workflow

   

   Standard workflow

   

   Note

   SAP systems forget a transaction identifier after a specified time, or 24 hours by default. As a result, SAP never fails to confirm a transaction identifier if the ID or GUID is unknown. If confirmation for a transaction identifier fails, this failure indicates that communcation with the SAP system failed before SAP was able to acknowledge the confirmation.

4. Add the SAP action named [IDOC] Send document to SAP to your workflow. Provide the information for the IDoc that you send to your SAP system plus the following values:

   Parameter	Value	Description
   Confirm TID	No	Don't automatically confirm the transaction ID, which explicitly happens in a separate step.
   Transaction Id GUID	<IDoc-transaction-ID>	If this parameter doesn't automatically appear, open the Add new parameters list, and select the parameter. To select the transaction ID variable that you created, follow these steps: 1. In the Transaction Id GUID parameter, select inside the edit box to open the dynamic content list. 2. From the list, under Variables, select the variable that you previously created, which is IDocTransactionID in this example.

   Consumption workflow

   

   Standard workflow

   

5. For the SAP managed action named [IDOC] Send document to SAP, open Settings to review the Retry Policy.

   The Default option is the recommended policy, but you can select a custom policy for your specific needs. If you choose to use a custom policy, set up at least one retry to overcome temporary network outages.

   Note

   Only managed connector actions currently have the Retry Policy setting, not built-in, service provider-based connectors.

6. Now, add the SAP action named [IDOC - RFC] Confirm transaction Id.

   1. In the Transaction ID parameter, select inside the edit box to open the dynamic content list.

   2. From the list, under Variables, enter the name for the variable that you created, which is IDocTransactionID in this example.

      Consumption workflow

      

      Standard workflow

      

7. Optionally, validate the deduplication in your test environment.

   1. Add another SAP action named [IDOC] Send document to SAP. In the Transaction ID parameter, select the Transaction ID GUID that you used in the previous step.

   2. To validate which IDoc number gets assigned after each call to the action named [IDOC] Send document to SAP, add the action named [IDOC] Get IDOC list for transaction to your workflow with the same Transaction ID and the Receive direction.

      If the same IDoc number is returned for both calls, the IDoc was deduplicated.

If you send the same IDoc twice, you can validate that SAP can identify the duplication of the tRFC call, and resolve the two calls to a single inbound IDoc message.

Troubleshoot problems

Connection problems

During connection creation, if you receive the following error, a problem exists with your installation of the SAP NCo client library:

Test connection failed. Error 'Failed to process request. Error details: 'could not load file or assembly 'sapnco, Version=3.0.0.42, Culture=neutral, PublicKeyToken 50436dca5c7f7d23' or one of its dependencies. The system cannot find the file specified.'.'

Make sure to install the required version of the SAP NCo client library and meet all other prerequisites.

500 Bad Gateway or 400 Bad Request error

If you receive a 500 Bad Gateway or 400 Bad Request error with a message similar to service 'sapgw00' unknown, the network service name resolution to port number is failing, for example:

{
   "body": {
      "error": {
         "code": 500,
         "source": "EXAMPLE-FLOW-NAME.eastus.environments.microsoftazurelogicapps.net",
         "clientRequestId": "00000000-0000-0000-0000-000000000000",
         "message": "BadGateway",
         "innerError": {
            "error": {
               "code": "UnhandledException",
               "message": "\nERROR service 'sapgw00' unknown\nTIME Wed Nov 11 19:37:50 2020\nRELEASE 721\nCOMPONENT NI (network interface)\nVERSION 40\nRC -3\nMODULE ninti.c\nLINE 933\nDETAIL NiPGetServByName: 'sapgw00' not found\nSYSTEM CALL getaddrinfo\nCOUNTER 1\n\nRETURN CODE: 20"
            }
         }
      }
   }
}

• Option 1: In your API connection and trigger configuration, replace your gateway service name with its port number. In the example error, sapgw00 needs to be replaced with a real port number, for example, 3300.

• Option 2: If you're using the on-premises data gateway, you can add the gateway service name to the port mapping in %windir%\System32\drivers\etc\services and then restart the on-premises data gateway service, for example:

  sapgw00  3300/tcp
  

You might get a similar error when SAP Application server or Message server name resolves to the IP address. For the on-premises data gateway, you can instead add the name to the IP address mapping in %windir%\System32\drivers\etc\hosts, for example:

10.0.1.9 SAPDBSERVER01 # SAP System Server VPN IP by computer name
10.0.1.9 SAPDBSERVER01.someguid.xx.xxxxxxx.chinacloudapp.cn # SAP System Server VPN IP by fully qualified computer name

Errors sending IDoc packets from SAP to your trigger

If you can't send IDoc packets from SAP to your trigger, review the Transactional RFC (tRFC) call rejection message in the SAP tRFC (T-Code SM58) dialog box. In the SAP interface, you might get the following error messages, which are clipped due to the substring limits on the Status Text field.

The segment or group definition E2EDK36001 was not found in the IDoc meta

This error message means expected failures happen with other errors. For example, the failure to generate an IDoc XML payload because its segments aren't released by SAP. As a result, the segment type metadata required for conversion is missing.

To have these segments released by SAP, contact the ABAP engineer for your SAP system.

The RequestContext on the IReplyChannel was closed without a reply being sent

For the SAP managed connector, this error message means unexpected failures happen when the catch-all handler for the channel terminates the channel due to an error, and rebuilds the channel to process other messages.

• To acknowledge that your workflow received the IDoc, add a Response action that returns a 200 OK status code. Leave the body empty and don't change or add to the headers. The IDoc is transported through tRFC, which doesn't allow for a response payload.

• To reject the IDoc instead, respond with any HTTP status code other than 200 OK. The SAP Adapter then returns an exception back to SAP on your behalf. You should only reject the IDoc to signal transport errors back to SAP, such as a misrouted IDoc that your application can't process. You shouldn't reject an IDoc for application-level errors, such as issues with the data contained in the IDoc. If you delay transport acceptance for application-level validation, you might experience negative performance due to blocking your connection from transporting other IDocs.

• If you receive this error message and experience systemic failures calling Azure Logic Apps, check that you've configured the network settings for your on-premises data gateway service for your specific environment. For example, if your network environment requires the use of a proxy to call Azure endpoints, you need to configure your on-premises data gateway service to use your proxy. For more information, review Proxy Configuration.

• If you receive this error message and experience intermittent failures calling Azure Logic Apps, you might need to increase your retry count or also retry interval by following these steps:

  1. Check the SAP settings in your on-premises data gateway service configuration file named Microsoft.PowerBI.EnterpriseGateway.exe.config.

     1. Under the configuration root node, add a configSections element, if none exists.

     2. Under the configSections node, add a section element with the following attributes, if none exists: name="SapAdapterSection" type="Microsoft.Adapters.SAP.Common.SapAdapterSection, Microsoft.Adapters.SAP.Common"

        Important

        Don't change the attributes in existing section elements, if such elements already exist.

        Your configSections element looks like the following version, if no other section or section group is declared in the gateway service configuration:

        <configSections>
          <section name="SapAdapterSection" type="Microsoft.Adapters.SAP.Common.SapAdapterSection, Microsoft.Adapters.SAP.Common"/>
        </configSections>
        

     3. Under the configuration root node, add an SapAdapterSection element, if none exists.

     4. Under the SapAdapterSection node, add a Broker element with the following attributes, if none exists: WebhookRetryDefaultDelay="00:00:00.10" WebhookRetryMaximumCount="2"

        Important

        Change the attributes for the Broker element, even if the element already exists.

        The SapAdapterSection element looks like the following version, if no other element or attribute is declared in the SAP adapter configuration:

        <SapAdapterSection>
          <Broker WebhookRetryDefaultDelay="00:00:00.10" WebhookRetryMaximumCount="2" />
        </SapAdapterSection>
        

        The retry count setting looks like WebhookRetryMaximumCount="2". The retry interval setting looks like WebhookRetryDefaultDelay="00:00:00.10" where the timespan format is HH:mm:ss.ff.

     Note

     For more information about the configuration file, review Configuration file schema for .NET Framework.

  2. Save your changes.

  3. If you're using the on-premises data gateway, restart your gateway.

Next steps

• Generate schemas for artifacts in SAP