Connect to SAP systems from Azure Logic Apps

This article explains how you can access your SAP resources from Azure Logic Apps using the SAP connector.

Prerequisites

  • An Azure account and subscription. If you don't have an Azure subscription yet, sign up for a free Azure account.

  • A logic app workflow from which you want to access your SAP resources. If you're new to Azure Logic Apps, review the Azure Logic Apps overview and the quickstart for creating your first logic app workflow in the Azure portal.

  • An SAP application server or SAP message server that you want to access from Azure Logic Apps. For information about the SAP servers that support this connector, review SAP compatibility.

    Important

    Make sure that you set up your SAP server and user account to allow using RFC. For more information, which includes the supported user account types and the minimum required authorization for each action type (RFC, BAPI, IDOC), review the following SAP note: 460089 - Minimum authorization profiles for external RFC programs.

    • For RFC actions, the user account additionally needs access to function modules RFC_GROUP_SEARCH and DD_LANGU_TO_ISOLA.
    • For BAPI actions, the user account also needs access to the following function modules: BAPI_TRANSACTION_COMMIT, BAPI_TRANSACTION_ROLLBACK, RPY_BOR_TREE_INIT, SWO_QUERY_METHODS and SWO_QUERY_API_METHODS.
    • For IDOC actions, the user account also needs access to the following function modules: IDOCTYPES_LIST_WITH_MESSAGES, IDOCTYPES_FOR_MESTYPE_READ, INBOUND_IDOCS_FOR_TID, OUTBOUND_IDOCS_FOR_TID, GET_STATUS_FROM_IDOCNR, and IDOC_RECORD_READ.
    • For the Read Table action, the user account also needs access to either following function module: RFC BBP_RFC_READ_TABLE or RFC_READ_TABLE.
  • Message content to send to your SAP server, such as a sample IDoc file. This content must be in XML format and include the namespace of the SAP action you want to use. You can send IDocs with a flat file schema by wrapping them in an XML envelope.

  • If you want to use the When a message is received from SAP trigger, you must also do the following tasks:

    • Set up your SAP gateway security permissions or Access Control List (ACL). In the secinfo and reginfo files, which are visible in the Gateway Monitor dialog box, T-Code SMGW, follow Goto > Expert Functions > External Security > Maintenance of ACL Files. The following permission setting is required:

      P TP=LOGICAPP HOST=<on-premises-gateway-server-IP-address> ACCESS=*

      This line has the following format:

      P TP=<trading-partner-identifier-(program-name)-or-*-for-all-partners> HOST=<comma-separated-list-with-external-host-IP-or-network-names-that-can-register-the-program> ACCESS=<*-for-all-permissions-or-a-comma-separated-list-of-permissions>

      If you don't configure the SAP gateway security permissions, you might receive this error:

      Registration of tp Microsoft.PowerBI.EnterpriseGateway from host <host-name> not allowed

      For more information, review SAP Note 1850230 - GW: "Registration of tp <program ID> not allowed".

    • Set up your SAP gateway security logging to help find Access Control List (ACL) issues. For more information, review the SAP help topic for setting up gateway logging.

    • In the Configuration of RFC Connections (T-Code SM59) dialog box, create an RFC connection with the TCP/IP type. The Activation Type must be Registered Server Program. Set the RFC connection's Communication Type with Target System value to Unicode.

    • If you use this SAP trigger with the IDOC Format parameter set to FlatFile along with the Flat File Decode action, you have to use the early_terminate_optional_fields property in your flat file schema by setting the value to true.

      This requirement is necessary because the flat file IDoc data record that's sent by SAP on the tRFC call IDOC_INBOUND_ASYNCHRONOUS isn't padded to the full SDATA field length. Azure Logic Apps provides the flat file IDoc original data without padding as received from SAP. Also, when you combine this SAP trigger with the Flat File Decode action, the schema that's provided to the action must match.

    Note

    This SAP trigger uses the same URI location to both renew and unsubscribe from a webhook subscription. The renewal operation uses the HTTP PATCH method, while the unsubscribe operation uses the HTTP DELETE method. This behavior might make a renewal operation appear as an unsubscribe operation in your trigger's history, but the operation is still a renewal because the trigger uses PATCH as the HTTP method, not DELETE.

SAP compatibility

The SAP connector is compatible with the following types of SAP systems:

  • On-premises and cloud-based HANA-based SAP systems, such as S/4 HANA.

  • Classic on-premises SAP systems, such as R/3 and ECC.

The SAP connector supports the following message and data integration types from SAP NetWeaver-based systems:

  • Intermediate Document (IDoc)

  • Business Application Programming Interface (BAPI)

  • Remote Function Call (RFC) and Transactional RFC (tRFC)

The SAP connector uses the SAP .NET Connector (NCo) library.

To use the available SAP trigger and SAP actions, you need to first authenticate your connection. You can authenticate your connection with a username and password. The SAP connector also supports SAP Secure Network Communications (SNC) for authentication. You can use SNC for SAP NetWeaver single sign-on (SSO), or for additional security capabilities from external products. If you use SNC, review the SNC prerequisites and the SNC prerequisites for the ISE connector.

Migrate to current connector

The previous SAP Application Server and SAP Message server connectors were deprecated February 29, 2020. To migrate to the current SAP connector, follow these steps:

  1. Update your on-premises data gateway to the current version. For more information, review Install an on-premises data gateway for Azure Logic Apps.

  2. In your logic app workflow that uses the deprecated SAP connector, delete the Send to SAP action.

  3. Add the Send message to SAP action from the current SAP connector.

  4. Reconnect to your SAP system in the new action.

  5. Save your logic app workflow. On the designer toolbar, select Save.

Multi-tenant Azure prerequisites

These prerequisites apply if your logic app workflow runs in multi-tenant Azure. The managed SAP connector doesn't run natively in an ISE.

Tip

If you're using a Premium-level ISE, you can use the SAP ISE connector instead of the managed SAP connector. For more information, review the ISE prerequisites.

The managed SAP connector integrates with SAP systems through your on-premises data gateway. For example, in send message scenarios, when a message is sent from a logic app workflow to an SAP system, the data gateway acts as an RFC client and forwards the requests received from the logic app workflow to SAP. Likewise, in receive message scenarios, the data gateway acts as an RFC server that receives requests from SAP and forwards them to the logic app workflow.

  1. Download and install the on-premises data gateway on a host computer or virtual machine that exists in the same virtual network as the SAP system to which you're connecting.

  2. Create an Azure gateway resource for your on-premises data gateway in the Azure portal. This gateway helps you securely access on-premises data and resources. Make sure to use a supported version of the gateway.

Tip

If you experience an issue with your gateway, try upgrading to the latest version, which might include updates to resolve your problem.

  1. Download and install the latest SAP client library on the same local computer as your on-premises data gateway.

  2. Configure the network host names and service names resolution for the host machine where you installed the on-premises data gateway.

If you intend to use host names or service names for connection from Azure Logic Apps, you must set up each SAP application, message, and gateway server along with their services for name resolution. The network host name resolution is configured in the %windir%\System32\drivers\etc\hosts file or in the DNS server that's available to your on-premises data gateway host machine. The service name resolution is configured in %windir%\System32\drivers\etc\services. If you do not intend to use network host names or service names for the connection, you can use host IP addresses and service port numbers instead.

If you do not have a DNS entry for your SAP system, the following example shows a sample entry for the hosts file:

10.0.1.9           sapserver                   # SAP single-instance system host IP by simple computer name
10.0.1.9           sapserver.contoso.com       # SAP single-instance system host IP by fully qualified DNS name

A sample set of entries for the services files is:

sapdp00            3200/tcp              # SAP system instance 00 dialog (application) service port
sapgw00            3300/tcp              # SAP system instance 00 gateway service port
sapmsDV6           3601/tcp              # SAP system ID DV6 message service port

ISE prerequisites

An ISE provides access to resources that are protected by an Azure virtual network and offers other ISE-native connectors that let logic app workflows directly access on-premises resources without using the on-premises data gateway.

  1. If you don't already have an Azure Storage account with a blob container, create a container using either the Azure portal or Azure Storage Explorer.

  2. Download and install the latest SAP client library on your local computer. You should have the following assembly files:

    • libicudecnumber.dll

    • rscp4n.dll

    • sapnco.dll

    • sapnco_utils.dll

  3. Create a .zip file that includes these assembly files. Upload the package to your blob container in Azure Storage.

  4. In either the Azure portal or Azure Storage Explorer, browse to the container location where you uploaded the .zip file.

  5. Copy the URL of the container location. Make sure to include the Shared Access Signature (SAS) token, so the SAS token is authorized. Otherwise, deployment for the SAP ISE connector fails.

  6. Install and deploy the SAP connector in your ISE. For more information, review Add ISE connectors.

    1. In the Azure portal, find and open your ISE.

    2. On the ISE menu, select Managed connectors > Add. From the connectors list, find and select SAP.

    3. On the Add a new managed connector pane, in the SAP package box, paste the URL for the .zip file that has the SAP assemblies. Again, make sure to include the SAS token.

    4. Select Create to finish creating your ISE connector.

  7. If your SAP instance and ISE are in different virtual networks, you also need to peer those networks so they are connected. Also review the SNC prerequisites for the ISE connector.

  8. Get the IP addresses for the SAP application, message, and gateway servers that you plan to use for connecting from your logic app workflow. Network name resolution is not available for SAP connections in an ISE.

  9. Get the port numbers for the SAP application, message, and gateway services that you plan you will use for connection with Logic App. Service name resolution is not available for SAP connector in ISE.

SAP client library prerequisites

The following list describes the prerequisites for the SAP client library that you're using with the connector:

  • Make sure that you install the latest version, SAP Connector (NCo 3.0) for Microsoft .NET 3.0.24.0 compiled with .NET Framework 4.0 - Windows 64-bit (x64). Earlier versions of SAP NCo might experience the following issues:

    • When more than one IDoc message is sent at the same time, this condition blocks all later messages that are sent to the SAP destination, causing messages to time out.

    • Session activation might fail due to a leaked session. This condition might block calls sent by SAP to the logic app workflow trigger.

    • The on-premises data gateway (June 2021 release) depends on the SAP.Middleware.Connector.RfcConfigParameters.Dispose() method in SAP NCo to free up resources.

  • You must have the 64-bit version of the SAP client library installed, because the data gateway only runs on 64-bit systems. Installing the unsupported 32-bit version results in a "bad image" error.

  • Copy the assembly files from the default installation folder to another location, based on your scenario as follows.

    • For a logic app workflow that runs in an ISE, follow the ISE prerequisites instead.

    • For a logic app workflow that runs in multi-tenant Azure and uses your on-premises data gateway, copy the assembly files to the data gateway installation folder.

      Note

      If your SAP connection fails with the error message, Please check your account info and/or permissions and try again, make sure you copied the assembly files to the data gateway installation folder.

      You can troubleshoot further issues using the .NET assembly binding log viewer. This tool lets you check that your assembly files are in the correct location.

    • Optionally, when you install the SAP client library, select the Global Assembly Cache registration option.

Note the following relationships between the SAP client library, the .NET Framework, the .NET runtime, and the gateway:

  • Both the Microsoft SAP Adapter and the gateway host service use .NET Framework 4.7.2.

  • The SAP NCo for .NET Framework 4.0 works with processes that use .NET runtime 4.0 to 4.8.

  • The SAP NCo for .NET Framework 2.0 works with processes that use .NET runtime 2.0 to 3.5, but no longer works with the latest gateway.

SNC prerequisites

If you use an on-premises data gateway with optional SNC, which is only supported in multi-tenant Azure, you must configure these additional settings. If you're using an ISE, review the SNC prerequisites for the ISE connector

If you're using SNC with SSO, make sure the data gateway service is running as a user who is mapped against the SAP user. To change the default account, select Change account, and enter the user credentials.

Screenshot that shows Azure portal with on-premises data gateway settings and Service Settings page with button to change gateway service account selected.

If you're enabling SNC through an external security product, copy the SNC library or files on the same computer where your data gateway is installed. Some examples of SNC products include sapseculib, Kerberos, and NTLM. For more information about enabling SNC for the data gateway, review Enable Secure Network Communications (SNC).

Tip

The version of your SNC library and its dependencies must be compatible with your SAP environment.

  • You must use sapgenpse.exe specifically as the SAPGENPSE utility.
  • If you use an on-premises data gateway, also copy these same binary files to the installation folder there.
  • If PSE is provided in your connection, you don't need to copy and set up PSE and SECUDIR for your on-premises data gateway.
  • You can also use your on-premises data gateway to troubleshoot any library compatibility issues.

SNC prerequisites (ISE)

The ISE version of the SAP connector supports SNC X.509. You can enable SNC for your SAP ISE connections with the following steps:

Important

Before you redeploy an existing SAP connector to use SNC, you must delete all connections to the old connector. Multiple logic app workflows can use the same connection to SAP. As such, you must delete any SAP connections from all your logic app workflows in the ISE. Then, you must delete the old connector.

When you delete an old connector, you can still keep the logic app workflows that use this connector. After you redeploy the connector, you can then authenticate the new connection in your SAP triggers and actions in these logic app workflows.

First, if you have already deployed the SAP connector without the SNC or SAPGENPSE libraries, delete all the connections and the connector.

  1. Sign in to the Azure portal.

  2. Delete all connections to your SAP connector from your logic app workflows.

    1. Open your logic app resource in the Azure portal.

    2. In your logic app's menu, under Development Tools, select API connections.

    3. On the API connections page, select your SAP connection.

    4. On the connection's page menu, select Delete.

    5. Accept the confirmation prompt to delete the connection.

    6. Wait for the portal notification that the connection has been deleted.

  3. Or, delete connections to your SAP connector from your ISE's API connections.

    1. Open your ISE resource in the Azure portal.

    2. In your ISE's menu, under Settings, select API connections.

    3. On the API connections page, select your SAP connection.

    4. On the connection's page menu, select Delete.

    5. Accept the confirmation prompt to delete the connection.

    6. Wait for the portal notification that the connection has been deleted.

Next, delete the SAP connector from your ISE. You must delete all connections to this connector in all your logic apps before you can delete the connector. If you haven't already deleted all connections, review the previous set of steps.

  1. Sign in to the Azure portal.

  2. Open your ISE resource in the Azure portal again.

  3. In your ISE's menu, under Settings, select Managed connectors.

  4. On the Managed connectors page, select the checkbox for your SAP connector.

  5. In the toolbar, select Delete.

  6. Accept the confirmation prompt to delete the connector.

  7. Wait for the portal notification that the connector has been deleted.

Next, deploy or redeploy the SAP connector in your ISE:

  1. Prepare a new zip archive file to use in your SAP connector deployment. You must include the SNC library and the SAPGENPSE utility.

    1. Copy all SNC, SAPGENPSE, and NCo libraries to the root folder of your zip archive. Don't put these binaries in subfolders.

    2. You must use the 64-bit SNC library. There is no 32-bit support.

    3. Your SNC library and its dependencies must be compatible with your SAP environment. For how to check compatibility, the ISE prerequisites.

  2. Follow the deployment steps in ISE prerequisites with your new zip archive.

Last, create new connections that use SNC in all your logic apps that use the SAP connector. For each connection, follow these steps:

  1. Open your workflow in the workflow designer again.

  2. Create or edit a step that uses the SAP connector.

  3. Enter required information about your SAP connection.

    Screenshot of the workflow designer, showing SAP connection settings.

    Note

    The fields SAP Username and SAP Password are optional. If you don't provide a username and password, the connector uses the client certificate provided in a later step for authentication.

  4. Enable SNC.

    1. For Use SNC, select the checkbox.

    2. For SNC Library, enter the name of your SNC library. For example, sapcrypto.dll.

    3. For SNC Partner Name, enter the backend's SNC name. For example, p:CN=DV3, OU=LA, O=MS, C=US.

    4. For SNC Certificate, enter your SNC client's public certificate in base64-encoded format. Don't include the PEM header or footer.

    5. Optionally, enter SNC settings for SNC My Name, SNC Quality of Protection as needed.

    Screenshot that shows the workflow designer and the SNC configuration settings for a new SAP connection.

  5. Configure PSE settings. For PSE, enter your SNC PSE as a base64-encoded binary.

    • The PSE must contain the private client certificate, which thumbprint matches the public client certificate that you provided in the previous step.

    • The PSE may contain additional client certificates.

    • The PSE must have no PIN. If needed, set the PIN to empty using the SAPGENPSE utility.

    For certificate rotation, follow these steps:

    1. Update the base64-encoded binary PSE for all connections that use SAP ISE X.509 in your ISE.

    2. Import the new certificates into your copy of the PSE.

    3. Encode the PSE file as a base64-encoded binary.

    4. Edit the API connection for your SAP connector, and save the new PSE file there.

    The connector detects the PSE change and updates its own copy during the next connection request.

    Note

    If you're using more than one SNC client certificate for your ISE, you must provide the same PSE for all connections. You can set the client public certificate parameter to specific the certificate for each connection used in your ISE.

  6. Select Create to create your connection. If the parameters are correct, the connection is created. If there's a problem with the parameters, the connection creation dialog displays an error message.

    Tip

    To troubleshoot connection parameter issues, you can use an on-premises data gateway and the gateway's local logs.

  7. On the workflow designer toolbar, select Save to save your changes.

Send IDoc messages to SAP server

Follow these examples to create a logic app workflow that sends an IDoc message to an SAP server and returns a response:

  1. Create a logic app workflow that is triggered by an HTTP request.

  2. Create an action in your workflow to send a message to SAP.

  3. Create an HTTP response action in 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 logic app.

Add an HTTP request trigger

To have your logic app workflow receive IDocs from SAP over XML HTTP, you can use the Request trigger.

Tip

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

This section continues with the Request trigger, so first, create a logic app workflow with an endpoint in Azure to send HTTP POST requests to your workflow. When your logic app workflow receives these HTTP requests, the trigger fires and runs the next step in your workflow.

  1. In the Azure portal, create a blank logic app, which opens the workflow designer.

  2. In the search box, enter http request as your filter. From the Triggers list, select When a HTTP request is received.

    Screenshot that shows the workflow designer with a new Request trigger being added to the logic app workflow.

  3. Save your logic app workflow, which generates an endpoint URL that can receive requests. On the designer toolbar, select Save. The endpoint URL now appears in your trigger.

    Screenshot that shows the workflow designer with the Request trigger with generated POST URL being copied.

Create SAP action to send message

Next, create an action to send your IDoc message to SAP when your Request trigger fires. By default, 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. Learn more about the Safe Typing option.

  1. In the workflow designer, under the trigger, select New step.

    Screenshot that shows the workflow designer with the workflow being edited to add a new step.

  2. In the search box, enter send message sap as your filter. From the Actions list, select Send message to SAP.

    Screenshot that shows the workflow designer with the selected "Send message to SAP" action.

    Or, you can select the Enterprise tab, and select the SAP action.

    Screenshot that shows the workflow designer with the selected "Send message to SAP" action under Enterprise tab.

  3. If your connection already exists, continue to the next step. If you're prompted to create a new connection, provide the following information to connect to your on-premises SAP server.

    1. Provide a name for the connection.

    2. If you're using the data gateway, follow these steps:

      1. In the Data Gateway section, under Subscription, first select the Azure subscription for the data gateway resource that you created in the Azure portal for your data gateway installation.

      2. Under Connection Gateway, select your data gateway resource in Azure.

    3. For the Logon Type property, follow the step based on whether the property is set to Application Server or Group.

      • For Application Server, these properties, which usually appear optional, are required:

        Screenshot that shows how to create SAP application server connection.

      • For Group, these properties, which usually appear optional, are required:

        Screenshot that shows how to create SAP message server connection.

        In SAP, the Logon Group is maintained by opening the CCMS: Maintain Logon Groups (T-Code SMLG) dialog box. For more information, review SAP Note 26317 - Set up for LOGON group for automatic load balancing.

      By default, 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. Learn more about the Safe Typing option.

    4. When you're finished, select Create.

      Azure Logic Apps sets up and tests your connection to make sure that the connection works properly.

      Note

      If you receive the following error, there is a problem 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.

  4. Now find and select an action from your SAP server.

    1. In the SAP Action box, select the folder icon. From the file list, find and select the SAP message you want to use. To navigate the list, use the arrows.

      This example selects an IDoc with the Orders type.

      Screenshot that shows finding and selecting an IDoc action.

      If you can't find the action you want, you can manually enter a path, for example:

      Screenshot that shows manually providing a path to an IDoc action.

      Tip

      Provide the value for SAP Action through the expression editor. That way, you can use the same action for different message types.

      For more information about IDoc operations, review Message schemas for IDoc operations.

    2. Click inside the Input Message box so that the dynamic content list appears. From that list, under When a HTTP request is received, select the Body field.

      This step includes the body content from your Request trigger and sends that output to your SAP server.

      Screenshot that shows selecting the "Body" property in the Request trigger.

      When you're finished, your SAP action looks like this example:

      Screenshot that shows completing the SAP action.

  5. Save your logic app workflow. On the designer toolbar, select Save.

Send flat file IDocs

You can use IDocs with a flat file schema if you wrap them in an XML envelope. To send a flat file IDoc, use the generic instructions to create an SAP action to send your IDoc message with the following changes.

  1. For the Send message to SAP action, use the SAP action URI http://microsoft.lobservices.sap/2007/03/Idoc/SendIdoc.

  2. Format your input message with an XML envelope.

For example, review the following example XML payload:

<ReceiveIdoc 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>
</ReceiveIdoc>

Create HTTP response action

Now add a response action to your logic app's workflow and include the output from the SAP action. That way, your logic app workflow returns the results from your SAP server to the original requestor.

  1. In the workflow designer, under the SAP action, select New step.

  2. In the search box, enter response as your filter. From the Actions list, select Response.

  3. Click inside the Body box so that the dynamic content list appears. From that list, under Send message to SAP, select the Body field.

    Screenshot that shows finishing the SAP action.

  4. Save your logic app workflow.

Create RFC request-response

You must create a request and response pattern if you need to receive replies by using a remote function call (RFC) to Azure Logic Apps from SAP ABAP. To receive IDocs in your logic app workflow, you should make the workflow's first action a Response action with a status code of 200 OK and no content. This recommended step completes the SAP Logical Unit of Work (LUW) asynchronous transfer over tRFC immediately, which leaves the SAP CPIC conversation available again. You can then add further actions in your logic app workflow to process the received IDoc without blocking further transfers.

Note

The SAP trigger receives IDocs over tRFC, which doesn't have a response parameter by design.

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, a request and response pattern is generated from the STFC_CONNECTION RFC module. The request XML is parsed to extract a node value in which 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>

Test your logic app workflow

  1. If your logic app isn't already enabled, on your logic app menu, select Overview. On the toolbar, select Enable.

  2. On the designer toolbar, select Run. This step manually starts your logic app workflow.

  3. Trigger your logic app workflow by sending an HTTP POST request to the URL in your Request trigger. Include your message content with your request. To the send the request, you can use a tool such as Postman.

    For this article, the request sends an IDoc file, which must be in XML format and include the namespace for the SAP action you're using, for example:

    <?xml version="1.0" encoding="UTF-8" ?>
    <Send xmlns="http://Microsoft.LobServices.Sap/2007/03/Idoc/2/ORDERS05//720/Send">
    <idocData>
    <...>
    </idocData>
    </Send>
    
  4. After you send your HTTP request, wait for the response from your logic app workflow.

    Note

    Your logic app workflow might time out if 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 you can check and monitor your logic apps.

You've now created a logic app workflow that can communicate with your SAP server. Now that you've set up an SAP connection for your logic app workflow, you can explore other available SAP actions, such as BAPI and RFC.

Receive message from SAP

This example uses a logic app workflow that triggers when the app receives a message from an SAP system.

Add an SAP trigger

  1. In the Azure portal, create a blank logic app, which opens the workflow designer.

  2. In the search box, enter when message received sap as your filter. From the Triggers list, select When a message is received from SAP.

    Screenshot that shows adding an SAP trigger.

    Or, you can select the Enterprise tab, and then select the trigger:

    Screenshot that shows adding an SAP trigger from the Enterprise tab.

  3. If your connection already exists, continue with the next step so you can set up your SAP trigger. However, if you're prompted for connection details, provide the information so that you can create a connection to your on-premises SAP server now.

    1. Provide a name for the connection.

    2. If you're using the data gateway, follow these steps:

      1. In the Data Gateway section, under Subscription, first select the Azure subscription for the data gateway resource that you created in the Azure portal for your data gateway installation.

      2. Under Connection Gateway, select your data gateway resource in Azure.

    3. Continue providing information about the connection. For the Logon Type property, follow the step based on whether the property is set to Application Server or Group:

      • For Application Server, these properties, which usually appear optional, are required:

        Screenshot that shows creating a connection to SAP application server.

      • For Group, these properties, which usually appear optional, are required:

        Screenshot that shows creating a connection to SAP message server

      By default, 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. Learn more about the Safe Typing option.

    4. When you're finished, select Create.

      Azure Logic Apps sets up and tests your connection to make sure that the connection works properly.

  4. Based on your SAP system configuration, provide the required parameters, and add any other parameters available for this trigger, for example:

    • To receive IDocs as plain XML, in the When a message is received from SAP trigger, which supports the SAP plain XML format, add and set the IDOC Format parameter to SapPlainXml.

    • To receive IDocs as a flat file using the same SAP trigger, add and set the IDOC Format parameter to FlatFile. When you also use the Flat File Decode action, in your flat file schema, you have to use the early_terminate_optional_fields property and set the value to true.

      This requirement is necessary because the flat file IDoc data record that's sent by SAP on the tRFC call IDOC_INBOUND_ASYNCHRONOUS isn't padded to the full SDATA field length. Azure Logic Apps provides the flat file IDoc original data without padding as received from SAP. Also, when you combine this SAP trigger with the Flat File Decode action, the schema that's provided to the action must match.

    • To filter the messages that you receive from your SAP server, specify a list of SAP actions.

      For example, select an SAP action from the file picker:

      Screenshot that shows adding an SAP action to logic app workflow.

      Or, you can manually specify an action:

      Screenshot that shows manually entering the SAP action that you want to use.

      Here's an example that shows how the action appears when you set up the trigger to receive more than one message.

      Screenshot that shows a trigger example that receives multiple messages.

      For more information about the SAP action, review Message schemas for IDoc operations

  5. Now save your logic app workflow so you can start receiving messages from your SAP system. On the designer toolbar, select Save.

    Your logic app workflow is now ready to receive messages from your SAP system.

    Note

    The SAP trigger in these steps is a webhook-based trigger, not a polling trigger. If you're using the data gateway, the trigger is called from the data gateway only when a message exists, so no polling is necessary.

  6. In your logic app workflow's trigger history, check that the trigger registration succeeds.

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. This is the only available option for ISE.

  • 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 ISE, you must specify the IP address for your SAP application server or message server. 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.cloudapp.net # SAP System Server VPN IP by fully qualified computer name

Parameters

Along with simple string and number inputs, the SAP connector accepts the following table parameters (Type=ITAB inputs):

  • Table direction parameters, both input and output, for older SAP releases.

  • Changing parameters, which replace the table direction parameters for newer SAP releases.

  • Hierarchical table parameters

Filter with SAP actions

You can optionally filter the messages that your logic app workflow receives from your SAP server by providing a list, or array, with a single or multiple SAP actions. By default, this array is empty, which means that your logic app receives all the messages from your SAP server without filtering.

When you set up the array filter, the trigger only receives messages 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 send test IDocs to Azure Logic Apps from SAP.

If you can't send IDoc packets from SAP to your logic app workflow's 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 RequestContext on the IReplyChannel was closed without a reply being sent

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 logic app 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're receiving 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're receiving this error message and experience intermittent failures calling Azure Logic Apps, you might need to increase your retry count or also retry interval.

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

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

  2. Save your changes. Restart your on-premises data gateway.

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

Asynchronous request-reply for triggers

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

Tip

In logic app workflows that have multiple response actions, all response actions must use the same request-reply pattern. For example, if your logic app workflow uses a switch control with multiple possible response actions, you must configure all the response actions to use the same request-reply pattern, either synchronous or asynchronous.

If you enable asynchronous response for your response action, your logic app 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 logic app workflow using the SAP connector, follow these steps:

  1. Open your logic app in the workflow designer.

  2. Confirm that the SAP connector is the trigger for your logic app workflow.

  3. Open your logic app workflow's Response action. In the action's title bar, select the menu (...) > Settings.

  4. In the Settings for your response action, turn on the toggle under Asynchronous Response. Select done.

  5. Save the changes to your logic app workflow.

Find extended error logs

For full error messages, check your SAP Adapter's extended logs. You can also enable an extended log file for the SAP connector.

  • For on-premises data gateway releases from April 2020 and earlier, logs are disabled by default.

  • For on-premises data gateway releases from June 2020 and later, you can enable gateway logs in the app settings.

    • The default logging level is Warning.

    • If you enable Additional logging in the Diagnostics settings of the on-premises data gateway app, the logging level is increased to Informational.

    • To increase the logging level to Verbose, update the following setting in your configuration file. Typically, the configuration file is located at C:\Program Files\On-premises data gateway\Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config.

      <setting name="SapTraceLevel" serializeAs="String">
         <value>Verbose</value>
      </setting>
      

Extended SAP logging in on-premises data gateway

If you use an on-premises data gateway for Azure Logic Apps, you can configure an extended log file for the SAP connector. You can use your on-premises data gateway to redirect Event Tracing for Windows (ETW) events into rotating log files that are included in your gateway's logging .zip files.

You can export all of your gateway's configuration and service logs to a .zip file in from the gateway app's settings.

Note

Extended logging might affect your logic app workflow's performance when always enabled. As a best practice, turn off extended log files after you're finished with analyzing and troubleshooting an issue.

Capture ETW events

Optionally, advanced users can capture ETW events directly. You can then consume your data in Azure Diagnostics in Event Hubs or collect your data to Azure Monitor Logs. For more information, review the best practices for collecting and storing data. You can use PerfView to work with the resulting ETL files, or you can write your own program. This walkthrough uses PerfView:

  1. In the PerfView menu, select Collect > Collect to capture the events.

  2. In the Additional Provider field, enter *Microsoft-LobAdapter to specify the SAP provider to capture SAP Adapter events. If you don't specify this information, your trace only includes general ETW events.

  3. Keep the other default settings. If you want, you can change the file name or location in the Data File field.

  4. Select Start Collection to begin your trace.

  5. After you've reproduced your issue or collected enough analysis data, select Stop Collection.

  6. To share your data with another party, such as Azure support engineers, compress the ETL file.

  7. To view the content of your trace:

    1. In PerfView, select File > Open and select the ETL file you just generated.

    2. In the PerfView sidebar, the Events section under your ETL file.

    3. Under Filter, filter by Microsoft-LobAdapter to only view relevant events and gateway processes.

Test your workflow

  1. To trigger your logic app workflow, send a message from your SAP system.

  2. On the logic app menu, select Overview. Review the Runs history for any new runs for your logic app workflow.

  3. Open the most recent run, which shows the message sent from your SAP system in the trigger outputs section.

Test sending IDocs from SAP

To send IDocs from SAP to your logic app workflow, you need the following minimum configuration:

Important

Use these steps only when you test your SAP configuration with your logic app workflow. Production environments require additional configuration.

  1. Configure an RFC destination in SAP.

  2. Create an ABAP connection to your RFC destination.

  3. Create a receiver port.

  4. Create a sender port.

  5. Create a logical system partner.

  6. Create a partner profile.

  7. Test sending messages.

Create RFC destination

  1. To open the Configuration of RFC Connections settings, in your SAP interface, use the sm59 transaction code (T-Code) with the /n prefix.

  2. Select TCP/IP Connections > Create.

  3. Create a new RFC destination with the following settings:

    1. For your RFC Destination, enter a name.

    2. On the Technical Settings tab, for Activation Type, select Registered Server Program.

    3. For your Program ID, enter a value. In SAP, your logic app workflow's trigger is registered by using this identifier.

      Important

      The SAP Program ID is case-sensitive. Make sure you consistently use the same case format for your Program ID when you configure your logic app workflow and SAP server. Otherwise, you might receive the following errors in the tRFC Monitor (T-Code SM58) when you attempt to send an IDoc to SAP:

      • Function IDOC_INBOUND_ASYNCHRONOUS not found
      • Non-ABAP RFC client (partner type ) not supported

      For more information from SAP, review the following notes (login required):

    4. On the Unicode tab, for Communication Type with Target System, select Unicode.

      Note

      SAP .NET Client libraries support only Unicode character encoding. If you get the error Non-ABAP RFC client (partner type ) not supported when sending IDoc from SAP to Azure Logic Apps, check that the Communication Type with Target System value is set to Unicode.

  4. Save your changes.

  5. Register your new Program ID with Azure Logic Apps by creating a logic app workflow that starts with the SAP trigger named When a message is received from SAP.

    This way, when you save your workflow, Azure Logic Apps registers the Program ID on the SAP Gateway.

  6. In your workflow's trigger history, the on-premises data gateway SAP Adapter logs, and the SAP Gateway trace logs, check the registration status. In the SAP Gateway monitor dialog box (T-Code SMGW), under Logged-On Clients, the new registration should appear as Registered Server.

  7. To test your connection, in the SAP interface, under your new RFC Destination, select Connection Test.

Create ABAP connection

  1. To open the Configuration of RFC Connections settings, in your SAP interface, use the sm59* transaction code (T-Code) with the /n prefix.

  2. Select ABAP Connections > Create.

  3. For RFC Destination, enter the identifier for your test SAP system.

  4. Save your changes.

  5. To test your connection, select Connection Test.

Create receiver port

  1. To open the Ports In IDOC processing settings, in your SAP interface, use the we21 transaction code (T-Code) with the /n prefix.

  2. Select Ports > Transactional RFC > Create.

  3. In the settings box that opens, select own port name. For your test port, enter a Name. Save your changes.

  4. In the settings for your new receiver port, for RFC destination, enter the identifier for your test RFC destination.

  5. Save your changes.

Create sender port

  1. To open the Ports In IDOC processing settings, in your SAP interface, use the we21 transaction code (T-Code) with the /n prefix.

  2. Select Ports > Transactional RFC > Create.

  3. In the settings box that opens, select own port name. For your test port, enter a Name that starts with SAP. All sender port names must start with the letters SAP, for example, SAPTEST. Save your changes.

  4. In the settings for your new sender port, for RFC destination, enter the identifier for your ABAP connection.

  5. Save your changes.

Create logical system partner

  1. To open the Change View "Logical Systems": Overview settings, in your SAP interface, use the bd54 transaction code (T-Code).

  2. Accept the warning message that appears: Caution: The table is cross-client

  3. Above the list that shows your existing logical systems, select New Entries.

  4. For your new logical system, enter a Log.System identifier and a short Name description. Save your changes.

  5. When the Prompt for Workbench appears, create a new request by providing a description, or if you already created a request, skip this step.

  6. After you create the workbench request, link that request to the table update request. To confirm that your table was updated, save your changes.

Create partner profiles

For production environments, you must create two partner profiles. The first profile is for the sender, which is your organization and SAP system. The second profile is for the receiver, which is your logic app.

  1. To open the Partner profiles settings, in your SAP interface, use the we20 transaction code (T-Code) with the /n prefix.

  2. Under Partner Profiles, select Partner Type LS > Create.

  3. Create a new partner profile with the following settings:

    • For Partner No., enter your logical system partner's identifier.

    • For Partn. Type, enter LS.

    • For Agent, enter the identifier for the SAP user account to use when you register program identifiers for Azure Logic Apps or other non-SAP systems.

  4. Save your changes. If you haven't created the logical system partner, you get the error, Enter a valid partner number.

  5. In your partner profile's settings, under Outbound parmtrs., select Create outbound parameter.

  6. Create a new outbound parameter with the following settings:

  7. Save your changes.

Test sending messages

  1. To open the Test Tool for IDoc Processing settings, in your SAP interface, use the we19 transaction code (T-Code) with the /n prefix.

  2. Under Template for test, select Via message type, and enter your message type, for example, CREMAS. Select Create.

  3. Confirm the Which IDoc type? message by selecting Continue.

  4. Select the EDIDC node. Enter the appropriate values for your receiver and sender ports. Select Continue.

  5. Select Standard Outbound Processing.

  6. To start outbound IDoc processing, select Continue. When processing finishes, the IDoc sent to SAP system or external program message appears.

  7. To check for processing errors, use the sm58 transaction code (T-Code) with the /n prefix.

Receive IDoc packets from SAP

You can set up SAP to send IDocs in packets, which are batches or groups of IDocs. To receive IDoc packets, the SAP connector, and specifically the trigger, doesn't need extra configuration. However, to process each item in an IDoc packet after the trigger receives the packet, some additional steps are required to split the packet into individual IDocs.

Here's an example that shows how to extract individual IDocs from a packet by using the xpath() function:

  1. Before you start, you need a logic app workflow with an SAP trigger. If you don't already have this trigger in your logic app workflow, follow the previous steps in this topic to set up a logic app workflow with an SAP trigger.

    Important

    The SAP Program ID is case-sensitive. Make sure you consistently use the same case format for your Program ID when you configure your logic app workflow and SAP server. Otherwise, you might receive the following errors in the tRFC Monitor (T-Code SM58) when you attempt to send an IDoc to SAP:

    • Function IDOC_INBOUND_ASYNCHRONOUS not found
    • Non-ABAP RFC client (partner type) not supported

    For more information from SAP, review the following notes (login required) https://launchpad.support.sap.com/#/notes/2399329 and https://launchpad.support.sap.com/#/notes/353597.

    For example:

    Screenshot that shows adding an SAP trigger to logic app workflow.

  2. Add a Response action to your logic app workflow to reply immediately with the status of your SAP request. As a best practice, add this action immediately after your trigger to free up the communication channel with your SAP server. Choose one of the following status codes (statusCode) to use in your response action:

    • 202 Accepted, which means the request has been accepted for processing but the processing isn't complete yet.

    • 204 No Content, which means the server has successfully fulfilled the request and there is 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.

  3. Get the root namespace from the XML IDoc that your logic app workflow receives from SAP. To extract this namespace from the XML document, add a step that creates a local string variable and stores that namespace by using an xpath() expression:

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

    Screenshot that shows getting the root namespace from IDoc.

  4. To extract an individual IDoc, add a step that creates an array variable and stores the IDoc collection by using another xpath() expression:

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

    Screenshot that shows getting an array of items.

    The array variable makes each IDoc available for your logic app workflow to process individually by enumerating over the collection. In this example, the logic app workflow transfers each IDoc to an SFTP server by using a loop:

    Screenshot that shows sending an IDoc to an SFTP server.

    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.

You can use the quickstart template for this pattern by selecting this template in the workflow designer when you create a new logic app workflow.

Screenshot that shows selecting a batch logic app template.

Generate schemas for artifacts in SAP

This example uses a logic app workflow that you can trigger with an HTTP request. To generate the schemas for the specified IDoc and BAPI, the SAP action Generate schema sends a request to an SAP system.

This SAP action returns an XML schema, not the contents or data of the XML document itself. Schemas returned in the response are uploaded to an integration account by using the Azure Resource Manager connector. Schemas contain the following parts:

  • The request message's structure. Use this information to form your BAPI get list.

  • The response message's structure. Use this information to parse the response.

To send the request message, use the generic SAP action Send message to SAP, or the targeted [BAPI] Call method in SAP actions.

Sample XML schemas

If you're learning how to generate an XML schema for use in creating a sample document, review the following samples. These examples show how you can work with many types of payloads, including:

You can begin your XML schema with an optional XML prolog. The SAP connector works with or without the XML prolog.

<?xml version="1.0" encoding="utf-8">

XML samples for RFC requests

The following example is a basic RFC call. The RFC name is STFC_CONNECTION. This request uses the default namespace xmlns=, however, you can assign and use namespace aliases such as xmmlns:exampleAlias=. The namespace value is the namespace for all RFCs in SAP for Microsoft services. There is a simple input parameter in the request, <REQUTEXT>.

<STFC_CONNECTION xmlns="http://Microsoft.LobServices.Sap/2007/03/Rfc/">
   <REQUTEXT>exampleInput</REQUTEXT>
</STFC_CONNECTION>

The following example is an RFC call with a table parameter. This example call and its group of test RFCs are available as part of all SAP systems. The table parameter's name is TCPICDAT. The table line type is ABAPTEXT, and this element repeats for each row in the table. This example contains a single line, called LINE. Requests with a table parameter can contain any number of fields, where the number is a positive integer (n).

<STFC_WRITE_TO_TCPIC xmlns="http://Microsoft.LobServices.Sap/2007/03/Rfc/">
   <RESTART_QNAME>exampleQName</RESTART_QNAME>
   <TCPICDAT>
      <ABAPTEXT xmlns="http://Microsoft.LobServices.Sap/2007/03/Rfc/">
         <LINE>exampleFieldInput1</LINE>
      <ABAPTEXT xmlns="http://Microsoft.LobServices.Sap/2007/03/Rfc/">
         <LINE>exampleFieldInput2</LINE>
      <ABAPTEXT xmlns="http://Microsoft.LobServices.Sap/2007/03/Rfc/">
         <LINE>exampleFieldInput3</LINE>
      </ABAPTEXT>
   </TCPICDAT>
</STFC_WRITE_TO_TCPIC>

Note

Observe the result of RFC STFC_WRITE_TO_TCPIC with the SAP Logon's Data Browser (T-Code SE16.) Use the table name TCPIC.

The following example is an RFC call with a table parameter that has an anonymous field. An anonymous field is when the field has no name assigned. Complex types are declared under a separate namespace, in which the declaration sets a new default for the current node and all its child elements. The example uses the hex codex002F as an escape character for the symbol /, because this symbol is reserved in the SAP field name.

<RFC_XML_TEST_1 xmlns="http://Microsoft.LobServices.Sap/2007/03/Rfc/">
   <IM_XML_TABLE>
      <RFC_XMLCNT xmlns="http://Microsoft.LobServices.Sap/2007/03/Rfc/">
         <_x002F_AnonymousField>exampleFieldInput</_x002F_AnonymousField>
      </RFC_XMLCNT>
   </IM_XML_TABLE>
</RFC_XML_TEST_1>

The following example includes prefixes for the namespaces. You can declare all prefixes at once, or you can declare any number of prefixes as attributes of a node. The RFC namespace alias ns0 is used as the root and parameters for the basic type.

Note

Complex types are declared under a different namespace for RFC types with the alias ns3 instead of the regular RFC namespace with the alias ns0.

<ns0:BBP_RFC_READ_TABLE xmlns:ns0="http://Microsoft.LobServices.Sap/2007/03/Rfc/" xmlns:ns3="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc/">
   <ns0:DELIMITER>0</ns0:DELIMITER>
   <ns0:QUERY_TABLE>KNA1</ns0:QUERY_TABLE>
   <ns0:ROWCOUNT>250</ns0:ROWCOUNT>
   <ns0:ROWSKIPS>0</ns0:ROWSKIPS>
   <ns0:FIELDS>
      <ns3:RFC_DB_FLD>
         <ns3:FIELDNAME>KUNNR</ns3:FIELDNAME>
      </ns3:RFC_DB_FLD>
   </ns0:FIELDS>
</ns0:BBP_RFC_READ_TABLE>

XML samples for BAPI requests

The following XML samples are example requests to call the BAPI method.

Note

SAP makes business objects available to external systems by describing them in response to RFC RPY_BOR_TREE_INIT, which Azure Logic Apps issues with no input filter. Logic Apps inspects the output table BOR_TREE. The SHORT_TEXT field is used for names of business objects. Business objects not returned by SAP in the output table aren't accessible to Azure Logic Apps.

If you use custom business objects, you must make sure to publish and release these business objects in SAP. Otherwise, SAP doesn't list your custom business objects in the output table BOR_TREE. You can't access your custom business objects in Logic Apps until you expose the business objects from SAP.

The following example gets a list of banks using the BAPI method GETLIST. This sample contains the business object for a bank, BUS1011.

<GETLIST xmlns="http://Microsoft.LobServices.Sap/2007/03/Bapi/BUS1011">
   <BANK_CTRY>US</BANK_CTRY>
   <MAX_ROWS>10</MAX_ROWS>
</GETLIST>

The following example creates a bank object using the CREATE method. This example uses the same business object as the previous example, BUS1011. When you use the CREATE method to create a bank, be sure to commit your changes because this method isn't committed by default.

Tip

Be sure that your XML document follows any validation rules configured in your SAP system. For example, in this sample document, the bank key (<BANK_KEY>) needs to be a bank routing number, also known as an ABA number, in the USA.

<CREATE xmlns="http://Microsoft.LobServices.Sap/2007/03/Bapi/BUS1011">
  <BANK_ADDRESS>
    <BANK_NAME xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc">ExampleBankName</BANK_NAME>
    <REGION xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc">ExampleRegionName</REGION>
    <STREET xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc">ExampleStreetAddress</STREET>
    <CITY xmlns="http://Microsoft.LobServices.Sap/2007/03/Types/Rfc">Redmond</CITY>
  </BANK_ADDRESS>
  <BANK_COUNTRY>US</BANK_COUNTRY>
  <BANK_KEY>123456789</BANK_KEY>
</CREATE>

The following example gets details for a bank using the bank routing number, the value for<BANK_KEY>.

<GETDETAIL xmlns="http://Microsoft.LobServices.Sap/2007/03/Bapi/BUS1011">
  <BANK_COUNTRY>US</BANK_COUNTRY>
  <BANK_KEY>123456789</BANK_KEY>
</GETDETAIL>

XML samples for IDoc requests

To generate a plain SAP IDoc XML schema, use the SAP Logon application and the WE-60 T-Code. Access the SAP documentation through the GUI and generate XML schemas in XSD format for your IDoc types and extensions. For an explanation of generic SAP formats and payloads, and their built-in dialogs, review the SAP documentation.

This example declares the root node and namespaces. The URI in the sample code, http://Microsoft.LobServices.Sap/2007/03/Idoc/3/ORDERS05//700/Send, declares the following configuration:

  • /IDoc is the root note for all IDocs.

  • /3 is the record types version for common segment definitions.

  • /ORDERS05 is the IDoc type.

  • // is an empty segment because there's no IDoc extension.

  • /700 is the SAP version.

  • /Send is the action to send the information to SAP.

<ns0:Send xmlns:ns0="http://Microsoft.LobServices.Sap/2007/03/Idoc/3/ORDERS05//700/Send" xmlns:ns3="http://schemas.microsoft.com/2003/10/Serialization" xmlns:ns1="http://Microsoft.LobServices.Sap/2007/03/Types/Idoc/Common/" xmlns:ns2="http://Microsoft.LobServices.Sap/2007/03/Idoc/3/ORDERS05//700">
   <ns0:idocData>

You can repeat the idocData node to send a batch of IDocs in a single call. In the example below, there is one control record, EDI_DC40, and multiple data records.

<...>
  <ns0:idocData>
    <ns2:EDI_DC40>
      <ns1:TABNAM>EDI_DC40</ns1:TABNAM>
      <...>
      <ns1:ARCKEY>Cor1908207-5</ns1:ARCKEY>
    </ns2:EDI_DC40>
    <ns2:E2EDK01005>
      <ns2:DATAHEADERCOLUMN_SEGNAM>E23DK01005</ns2:DATAHEADERCOLUMN_SEGNAM>
      <ns2:CURCY>USD</ns2:CURCY>
    </ns2:E2EDK01005>
    <ns2:E2EDK03>
    <...>
  </ns0:idocData>

The following example is a sample IDoc control record, which uses the prefix EDI_DC. You must update the values to match your SAP installation and IDoc type. For example, your IDoc client code may not be 800. Contact your SAP team to make sure you're using the correct values for your SAP installation.

<ns2:EDI_DC40>
  <ns:TABNAM>EDI_DC40</ns1:TABNAM>
  <ns:MANDT>800</ns1:MANDT>
  <ns:DIRECT>2</ns1:DIRECT>
  <ns:IDOCTYP>ORDERS05</ns1:IDOCTYP>
  <ns:CIMTYP></ns1:CIMTYP>
  <ns:MESTYP>ORDERS</ns1:MESTYP>
  <ns:STD>X</ns1:STD>
  <ns:STDVRS>004010</ns1:STDVRS>
  <ns:STDMES></ns1:STDMES>
  <ns:SNDPOR>SAPENI</ns1:SNDPOR>
  <ns:SNDPRT>LS</ns1:SNDPRT>
  <ns:SNDPFC>AG</ns1:SNDPFC>
  <ns:SNDPRN>ABAP1PXP1</ns1:SNDPRN>
  <ns:SNDLAD></ns1:SNDLAD>
  <ns:RCVPOR>BTSFILE</ns1:RCVPOR>
  <ns:RCVPRT>LI</ns1:RCVPRT>

The following example is a sample data record with plain segments. This example uses the SAP date format. Strong-typed documents can use native XML date formats, such as 2020-12-31 23:59:59.

<ns2:E2EDK01005>
  <ns2:DATAHEADERCOLUMN_SEGNAM>E2EDK01005</ns2:DATAHEADERCOLUMN_SEGNAM>
    <ns2:CURCY>USD</ns2:CURCY>
    <ns2:BSART>OR</ns2:BSART>
    <ns2:BELNR>1908207-5</ns2:BELNR>
    <ns2:ABLAD>CC</ns2:ABLAD>
  </ns2>
  <ns2:E2EDK03>
    <ns2:DATAHEADERCOLUMN_SEGNAM>E2EDK03</ns2:DATAHEADERCOLUMN_SEGNAM>
      <ns2:IDDAT>002</ns2:IDDAT>
      <ns2:DATUM>20160611</ns2:DATUM>
  </ns2:E2EDK03>

The following example is a data record with grouped segments. The record includes a group parent node, E2EDKT1002GRP, and multiple child nodes, including E2EDKT1002 and E2EDKT2001.

<ns2:E2EDKT1002GRP>
  <ns2:E2EDKT1002>
    <ns2:DATAHEADERCOLUMN_SEGNAM>E2EDKT1002</ns2:DATAHEADERCOLUMN_SEGNAM>
      <ns2:TDID>ZONE</ns2:TDID>
  </ns2:E2EDKT1002>
  <ns2:E2EDKT2001>
    <ns2:DATAHEADERCOLUMN_SEGNAM>E2EDKT2001</ns2:DATAHEADERCOLUMN_SEGNAM>
      <ns2:TDLINE>CRSD</ns2:TDLINE>
  </ns2:E2EDKT2001>
</ns2:E2EDKT1002GRP>

The recommended method is to create an IDoc identifier for use with tRFC. You can set this transaction identifier, tid, using the Send IDoc operation in the SAP connector API.

The following example is an alternative method to set the transaction identifier, or tid. In this example, the last data record segment node and the IDoc data node are closed. Then, the GUID, guid, is used as the tRFC identifier to detect duplicates.

     </E2STZUM002GRP>
  </idocData>
  <guid>8820ea40-5825-4b2f-ac3c-b83adc34321c</guid>
</Send>

Add the Request trigger

  1. In the Azure portal, create a blank logic app, which opens the workflow designer.

  2. In the search box, enter http request as your filter. From the Triggers list, select When a HTTP request is received.

    Screenshot that shows adding the Request trigger.

  3. Now save your logic app so you can generate an endpoint URL for your logic app workflow. On the designer toolbar, select Save.

    The endpoint URL now appears in your trigger, for example:

    Screenshot that shows generating the endpoint URL.

Add an SAP action to generate schemas

  1. In the workflow designer, under the trigger, select New step.

    Screenshot that shows adding a new step to logic app workflow.

  2. In the search box, enter generate schemas sap as your filter. From the Actions list, select Generate schemas.

    Screenshot that shows adding the "Generate schemas" action to workflow.

    Or, you can select the Enterprise tab, and select the SAP action.

    Screenshot that shows selecting the "Generate schemas" action from the Enterprise tab.

  3. If your connection already exists, continue with the next step so you can set up your SAP action. However, if you're prompted for connection details, provide the information so that you can create a connection to your on-premises SAP server now.

    1. Provide a name for the connection.

    2. In the Data Gateway section, under Subscription, first select the Azure subscription for the data gateway resource that you created in the Azure portal for your data gateway installation.

    3. Under Connection Gateway, select your data gateway resource in Azure.

    4. Continue providing information about the connection. For the Logon Type property, follow the step based on whether the property is set to Application Server or Group:

      • For Application Server, these properties, which usually appear optional, are required:

        Screenshot that shows creating a connection for SAP application server

      • For Group, these properties, which usually appear optional, are required:

        Screenshot that shows creating a connection for SAP message server

    5. When you're finished, select Create.

      Azure Logic Apps sets up and tests your connection to make sure that the connection works properly.

  4. Provide the path to the artifact for which you want to generate the schema.

    You can select the SAP action from the file picker:

    Screenshot that shows selecting an SAP action.

    Or, you can manually enter the action:

    Screenshot that shows manually entering an SAP action.

    To generate schemas for more than one artifact, provide the SAP action details for each artifact, for example:

    Screenshot that shows selecting "Add new item".

    Screenshot that shows two items.

    For more information about the SAP action, review Message schemas for IDoc operations.

  5. Save your logic app workflow. On the designer toolbar, select Save.

By default, 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. Learn more about the Safe Typing option.

Test your workflow

  1. On the designer toolbar, select Run to trigger a run for your logic app workflow.

  2. Open the run, and check the outputs for the Generate schemas action.

    The outputs show the generated schemas for the specified list of messages.

Upload schemas to an integration account

Optionally, you can download or store the generated schemas in repositories, such as a blob, storage, or integration account. Integration accounts provide a first-class experience with other XML actions, so this example shows how to upload schemas to an integration account for the same logic app workflow by using the Azure Resource Manager connector.

  1. In the workflow designer, under the trigger, select New step.

  2. In the search box, enter resource manager as your filter. Select Create or update a resource.

    Screenshot that shows selecting an Azure Resource Manager action.

  3. Enter the details for the action, including your Azure subscription, Azure resource group, and integration account. To add SAP tokens to the fields, click inside the boxes for those fields, and select from the dynamic content list that appears.

    1. Open the Add new parameter list, and select the Location and Properties fields.

    2. Provide details for these new fields as shown in this example.

      Screenshot that shows entering details for the Azure Resource Manager action.

    The SAP Generate schemas action generates schemas as a collection, so the designer automatically adds a For each loop to the action. Here's an example that shows how this action appears:

    Screenshot that shows the Azure Resource Manager action with a "for each" loop.

    Note

    The schemas use base64-encoded format. To upload the schemas to an integration account, they must be decoded by using the base64ToString() function. Here's an example that shows the code for the "properties" element:

    "properties": {
       "Content": "@base64ToString(items('For_each')?['Content'])",
       "ContentType": "application/xml",
       "SchemaType": "Xml"
    }
    
  4. Save your logic app workflow. On the designer toolbar, select Save.

Test your workflow

  1. On the designer toolbar, select Run to manually trigger your logic app workflow.

  2. After a successful run, go to the integration account, and check that the generated schemas exist.

Enable Secure Network Communications (SNC)

Before you start, make sure that you met the previously listed prerequisites, which apply only when you use the data gateway, and your logic app workflow runs in multi-tenant Azure:

  • Make sure the on-premises data gateway is installed on a computer that's in the same network as your SAP system.

  • For SSO, the data gateway is running as a user that's mapped to an SAP user.

  • The SNC library that provides the additional security functions is installed on the same machine as the data gateway. Some examples include sapseculib, Kerberos, and NTLM.

    To enable SNC for your requests to or from the SAP system, select the Use SNC check box in the SAP connection and provide these properties:

    Screenshot that shows setting up SNC in an SAP connection.

    Property Description
    SNC Library Path The SNC library name or path relative to NCo installation location or absolute path. Examples are sapsnc.dll or .\security\sapsnc.dll or c:\security\sapsnc.dll.
    SNC SSO When you connect through SNC, the SNC identity is typically used for authenticating the caller. Another option is to override so that user and password information can be used for authenticating the caller, but the line is still encrypted.
    SNC My Name In most cases, you can omit this property. The installed SNC solution usually knows its own SNC name. Only for solutions that support multiple identities, you might need to specify the identity to be used for this particular destination or server.
    SNC Partner Name The name for the back-end SNC.
    SNC Quality of Protection The quality of service to be used for SNC communication of this particular destination or server. The default value is defined by the back-end system. The maximum value is defined by the security product used for SNC.

    Note

    Don't set the environment variables SNC_LIB and SNC_LIB_64 on the machine where you have the data gateway and the SNC library. If set, they take precedence over the SNC library value passed through the connector.

Safe typing

By default, when you create your SAP connection, 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>

Send SAP telemetry for on-premises data gateway to Azure Application Insights

With the August 2021 update for the on-premises data gateway, SAP connector operations can send telemetry data from the SAP client library and traces from the Microsoft SAP Adapter to Application Insights, which is a capability in Azure Monitor. This telemetry primarily includes the following data:

  • Metrics and traces based on SAP NCo metrics and monitors.

  • Traces from Microsoft SAP Adapter.

Metrics and traces from SAP client library

Metrics are numeric values that might or might not vary over a time period, based on the usage and availability of resources on the on-premises data gateway. You can use these metrics to better understand system health and to create alerts about the following activities:

  • Whether system health is declining.

  • Unusual events.

  • Heavy load on your system.

This information is sent to the Application Insights table, customMetrics. By default, metrics are sent at 30-second intervals.

SAP NCo metrics and traces are based on SAP NCo metrics, specifically the following NCo classes:

  • RfcDestinationMonitor.

  • RfcConnectionMonitor.

  • RfcServerMonitor.

  • RfcRepositoryMonitor.

For more information about the metrics that each class provides, review the SAP NCo documentation (sign-in required).

Traces include text information that is used with metrics. This information is sent to the Application Insights table named traces. By default, traces are sent at 10-minute intervals.

Set up SAP telemetry for Application Insights

Before you can send SAP telemetry for your gateway installation to Application Insights, you need to have created and set up your Application Insights resource. For more information, review the following documentation:

To enable sending SAP telemetry to Application insights, follow these steps:

  1. Download the NuGet package for Microsoft.ApplicationInsights.EventSourceListener.dll from this location: https://www.nuget.org/packages/Microsoft.ApplicationInsights.EventSourceListener/2.14.0.

  2. Add the downloaded file to your on-premises data gateway installation directory.

  3. In your on-premises data gateway installation directory, check that the Microsoft.ApplicationInsights.dll file has the same version number as the Microsoft.ApplicationInsights.EventSourceListener.dll file that you added. The gateway currently uses version 2.14.0.

  4. In the ApplicationInsights.config file, add your Application Insights instrumentation key by uncommenting the line with the <InstrumentationKey></Instrumentation> element. Replace the placeholder, your-Application-Insights-instrumentation-key, with your key, for example:

    <?xml version="1.0" encoding="utf-8"?>
    <ApplicationInsights schemaVersion="2014-05-30" xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings">
       <!-- Uncomment this element and insert your Application Insights key to receive ETW telemetry about your gateway <InstrumentationKey>*your-instrumentation-key-placeholder*</InstrumentationKey> -->
       <TelemetryModules>
          <Add Type="Microsoft.ApplicationInsights.Extensibility.Implementation.Tracing.DiagnosticsTelemetryModule, Microsoft.ApplicationInsights">
             <IsHeartbeatEnabled>false</IsHeartbeatEnabled>
          </Add>
          <Add Type="Microsoft.ApplicationInsights.EventSourceListener.EventSourceTelemetryModule, Microsoft.ApplicationInsights.EventSourceListener">
             <Sources>
                <Add Name="Microsoft-LobAdapter" Level="Verbose" />
             </Sources>
          </Add>
       </TelemetryModules>
    </ApplicationInsights>
    
  5. In the ApplicationInsights.config file, you can change the required traces Level value for your SAP connector operations, per your requirements, for example:

    <Add Type="Microsoft.ApplicationInsights.EventSourceListener.EventSourceTelemetryModule, Microsoft.ApplicationInsights.EventSourceListener">
       <Sources>
          <Add Name="Microsoft-LobAdapter" Level="Verbose" />
       </Sources>
    </Add>
    

    For more information, review the following documentation:

  6. After you apply your changes, restart the on-premises data gateway service.

Review metrics in Application Insights

After your SAP operations run in your logic app workflow, you can review the telemetry that was sent to Application Insights.

  1. In the Azure portal, open your Application Insights resource.

  2. On the resource menu, under Monitoring, select Logs.

    The following screenshot shows the Azure portal with Application Insights, which is open to the Logs pane:

    Screenshot showing the Azure portal with Application Insights open to the "Logs" pane for creating queries.

  3. On the Logs pane, you can create a query using the Kusto Query Language (KQL) that's based on your specific requirements.

    You can use a query pattern similar to the following example query:

    customMetrics
    | extend DestinationName = tostring(customDimensions["DestinationName"])
    | extend MetricType = tostring(customDimensions["MetricType"])
    | where customDimensions contains "RfcDestinationMonitor"
    | where name contains "MaxUsedCount"
    
  4. After you run your query, review the results.

    The following screenshot shows the example query's metrics results table:

    Screenshot showing Application Insights with the metrics results table.

    • MaxUsedCount is "The maximal number of client connections that were simultaneously used by the monitored destination." as described in the SAP NCo documentation (sign-in required). You can use this value to understand the number of simultaneously open connections.

    • The valueCount column shows 2 for each reading because metrics are generated at 30-second intervals, and Application Insights aggregates these metrics by the minute.

    • The DestinationName column contains a character string that is a Microsoft SAP Adapter internal name.

      To better understand this Remote Function Call (RFC) destination, use this value with traces, for example:

      customMetrics
      | extend DestinationName = tostring(customDimensions["DestinationName"])
      | join kind=inner (traces
         | extend DestinationName = tostring(customDimensions["DestinationName"]),
         AppServerHost = tostring(customDimensions["AppServerHost"]),
         SncMode = tostring(customDimensions["SncMode"]),
         SapClient = tostring(customDimensions["Client"])
         | where customDimensions contains "RfcDestinationMonitor"
         )
         on DestinationName , $left.DestinationName == $right.DestinationName
      | where customDimensions contains "RfcDestinationMonitor"
      | where name contains "MaxUsedCount"
      | project AppServerHost, SncMode, SapClient, name, valueCount, valueSum, valueMin, valueMax
      

You can also create metric charts or alerts using those capabilities in Application Insights, for example:

Screenshot showing Application Insights with the results in chart format.

Traces from Microsoft SAP Adapter

You can use traces sent from Microsoft SAP Adapter for issue post-analysis and to find any existing internal system errors that might or might not surface from SAP connector operations. These traces have message set to "n\a" because they come from an earlier event source framework that predates Application Insights, for example:

traces
| where message == "n/a"
| where severityLevel > 0
| extend ActivityId = tostring(customDimensions["ActivityId"])
| extend fullMessage = tostring(customDimensions["fullMessage"])
| extend shortMessage = tostring(customDimensions["shortMessage"])
| where ActivityId contains "8ad5952b-371e-4d80-b355-34e28df9b5d1"

The following screenshot shows the example query's traces results table:

Screenshot showing Application Insights with the traces results table.

Advanced scenarios

Change language headers

When you connect to SAP from Logic Apps, the default language for the connection is English. You can set the language for your connection by using the standard HTTP header Accept-Language with your inbound requests.

Tip

Most web browsers add an Accept-Language header based on the user's settings. The web browser applies this header when you create a new SAP connection in the workflow designer, either update your web browser's settings to use your preferred language, or 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. All the actions in your logic app workflow receive the header. Then, SAP uses the specified languages in its system messages, such as BAPI error messages.

The SAP connection parameters for a logic app workflow don't have a language property. So, 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 explicitly

When you send transactions to SAP from Logic Apps, this exchange happens in two steps as described in the SAP document, Transactional RFC Server Programs. By default, the Send to SAP action handles both the steps for the function transfer and for the transaction confirmation in a single call. The SAP connector gives you the option to decouple these steps. You can send an IDoc and rather than automatically confirm the transaction, you can use the explicit [IDOC] Confirm transaction ID action.

This capability to decouple the transaction ID confirmation is useful when you don't want to duplicate transactions in SAP, for example, in scenarios where failures might happen due to causes such as network issues. By confirming the transaction ID separately, the transaction is only completed one time in your SAP system.

Here is an example that shows this pattern:

  1. Create a blank logic app and add the Request trigger.

  2. From the SAP connector, add the [IDOC] Send document to SAP action. Provide the details for the IDoc that you send to your SAP system.

  3. To explicitly confirm the transaction ID in a separate step, in the Confirm TID field, select No. For the optional Transaction ID GUID field, you can either manually specify the value or have the connector automatically generate and return this GUID in the response from the [IDOC] Send document to SAP action.

    Screenshot that shows the "[IDOC] Send document to SAP" action properties

  4. To explicitly confirm the transaction ID, add the [IDOC] Confirm transaction ID action, making sure to avoid sending duplicate IDocs to SAP. Click inside the Transaction ID box so that the dynamic content list appears. From that list, select the Transaction ID value that's returned from the [IDOC] Send document to SAP action.

    Screenshot that shows the "Confirm transaction ID" action

    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

If you experience an issue with duplicate IDocs being sent to SAP from your logic app workflow, follow these steps to create a string variable to serve as your IDoc transaction identifier. Creating this transaction identifier helps prevent duplicate network transmissions when there are issues such as temporary outages, network issues, or lost acknowledgments.

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.

  1. In the workflow designer, add the action Initialize variable to your logic app workflow.

  2. In the editor for the action Initialize variable, configure the following settings. Then, save your changes.

    1. For Name, enter a name for your variable. For example, IDOCtransferID.

    2. For Type, select String as the variable type.

    3. For Value, select the text box Enter initial value to open the dynamic content menu.

    4. Select the Expressions tab. In the list of functions, enter the function guid().

    5. Select OK to save your changes. The Value field is now set to the guid() function, which generates a GUID.

  3. After the Initialize variable action, add the action [IDOC] Send document to SAP.

  4. In the editor for the action [IDOC] Send document to SAP, configure the following settings. Then, save your changes.

    1. For IDOC type select your message type, and for Input IDOC message, specify your message.

    2. For SAP release version, select your SAP configuration's values.

    3. For Record types version, select your SAP configuration's values.

    4. For Confirm TID, select No.

    5. Select Add new parameter list > Transaction ID GUID.

    6. Select the text box to open the dynamic content menu. Under the Variables tab, select the name of the variable that you created, for example, IDOCtransferID.

  5. On the title bar of the action [IDOC] Send document to SAP, select ... > Settings.

    For Retry Policy, it's recommended to select Default > Done. However, you can instead configure a custom policy for your specific needs. For custom policies, it's recommended to configure at least one retry to overcome temporary network outages.

  6. After the action [IDOC] Send document to SAP, add the action [IDOC] Confirm transaction ID.

  7. In the editor for the action [IDOC] Confirm transaction ID, configure the following settings. Then, save your changes.

  8. For Transaction ID, enter the name of your variable again. For example, IDOCtransferID.

  9. Optionally, validate the deduplication in your test environment. Repeat the [IDOC] Send document to SAP action with the same Transaction ID GUID that you used in the previous step.

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

Known issues and limitations

Here are the currently known issues and limitations for the managed (non-ISE) SAP connector:

  • In general, the SAP trigger doesn't support data gateway clusters. In some failover cases, the data gateway node that communicates with the SAP system might differ from the active node, which results in unexpected behavior.

    • For send scenarios, data gateway clusters in failover mode are supported.

    • Data gateway clusters in load-balancing mode aren't supported by stateful SAP actions. These actions include [BAPI - RFC] Create stateful session, [BAPI] commit transaction, [BAPI] Rollback transaction, [BAPI - RFC] Close stateful session, and all actions that specify a Session ID value. Stateful communications must remain on the same data gateway cluster node.

    • For stateful SAP actions, use the data gateway either in non-cluster mode or in a cluster that's set up for failover only.

  • The SAP connector currently doesn't support SAP router strings. The on-premises data gateway must exist on the same LAN as the SAP system you want to connect.

  • In the [BAPI] Call method in SAP action, the auto-commit feature won't commit the BAPI changes if at least one warning exists in the CallBapiResponse object returned by the action. To commit BAPI changes despite any warnings, create a session explicitly with the [BAPI - RFC] Create stateful session action, disable the auto-commit feature in the [BAPI] Call method in SAP action, and call the [BAPI] Commit transaction action instead.

  • For logic apps in an ISE, this connector's ISE-labeled version uses the ISE message limits instead.

Connector reference

For more information about the SAP connector, review the connector reference. You can find details about limits, parameters, and returns for the SAP connector, triggers, and actions.

Triggers

When a message is received from SAP, do something.

Actions

Close an existing stateful connection session to your SAP system.

Create a stateful connection session to your SAP system.

Call the BAPI method in your SAP system.

You must use the following parameters with your call:

Business Object (businessObject), which is a searchable drop-down menu.

Method (method), which populates the available methods after you've selected a Business Object. The available methods vary depending on the selected Business Object.

Input BAPI parameters (body), in which you call the XML document that contains the BAPI method input parameter values for the call, or the URI of the storage blob that contains your BAPI parameters.

For detailed examples of how to use the [BAPI] Call method in SAP action, review the XML samples of BAPI requests.
If you're using the workflow designer to edit your BAPI request, you can use the following search functions:

Select an object in the designer to view a drop-down menu of available methods.

Filter business object types by keyword using the searchable list provided by the BAPI API call.

Commit the BAPI transaction for the session.

Roll back the BAPI transaction for the session.

Send the transaction identifier confirmation to SAP.

Get a list of IDocs for the transaction by session identifier or transaction identifier.

Get the status of an IDoc.

Sends the IDoc message to your SAP server.

You must use the following parameters with your call:

IDOC type with optional extension (idocType), which is a searchable drop-down menu.

Input IDOC message (body), in which you call the XML document containing the IDoc payload, or the URI of the storage blob that contains your IDoc XML document. This document must comply with either the SAP IDoc XML schema according to the WE60 IDoc Documentation, or the generated schema for the matching SAP IDoc action URI.

The optional parameter SAP release version (releaseVersion) populates values after you select the IDoc type, and depends on the selected IDoc type.

For detailed examples of how to use the Send IDoc action, review the walkthrough for sending IDoc messages to your SAP server.

For how to use optional parameter Confirm TID (confirmTid), review the walkthrough for confirming the transaction explicitly.

Add an RFC call to your transaction.

Call an RFC operation (sRFC, tRFC, or qRFC) on your SAP system.

Commit the RFC transaction for the session and/or queue.

Create a new transaction by identifier and/or queue name. If the transaction exists, get the details.

Get the details of a transaction by identifier and/or queue name. Create a new transaction if none exists.

Generate schemas for the SAP artifacts for IDoc, BAPI, or RFC.

Read an SAP table.

Send any message type (RFC, BAPI, IDoc) to SAP.

Next steps