David Burg's Blog

This blog has moved

David Burg — Thu, 20 Jun 2019 10:39:15 GMT

The date has finally come for the move of this dev blog off the MSDN platform. After considering several options, I am moving to LinkedIn articles for sharing future updates about Azure, Logic Apps, BizTalk, B2B integration, iPaaS, XML, SAP, Flat File, .NET, APIM, Azure Functions, etc... Please go in the future to https://www.linkedin.com/today/author/daviburg Some of the blog content I am re-posting as article with updates to LinkedIn. Most of the content has not been re-posted yet remains here in a read-only archive format. Comments are also been locked as part of the blog migration, so please reach out to your customer support contact for assistance with Microsoft products and services. I would like to thank the over 2 500 users visiting this blog over the past month and hope to find them again at the new location. You can find further information about the migration of dev blogs from MSDN Services Status Twitter account: https://twitter.com/MSDNService/status/1116801471008296960

Large request upcoming support for Azure Logic App SAP Connector

David Burg — Fri, 10 May 2019 10:19:33 GMT

I've completed the development work for the support of large requests in Azure Logic App SAP Connector. With this upcoming new feature, users will be able to send requests to SAP and the On-Premises Data Gateway via an Azure Storage Blob SAS URI like this: Please note that the Blob itself and its SAS URI need to be generated prior to calling this SAP Connector Send API. Luckily, we have native Azure Storage Blob connector available to do this directly the Logic App. Furthermore to make the contract explicit, an advanced parameter for Content-Type will be added: The content type for sending requests via Blob should be set to text/uri-list: In-line request payloads are supported up to 2.5 MB. For classic in-line XML payload, the content type should be set to application/xml: However to preserve backward compatibility, the default assigned content type of text/plain will also be supported for either of classic in-line XML payload or the new request payload via storage blob SAS URI. I recommend setting the content type explicitly to avoid ambiguity in your requests. Do note that the On-Premises Data Gateway will be updated in the future to include the matching SAP Adapter code to handle the new request format, download the request payload from the Azure Storage blob and forward the request to SAP. (This update is not available at the time this blob post is been written).

Troubleshooting SAP configuration for Azure Logic App SAP trigger

David Burg — Thu, 09 May 2019 12:40:32 GMT

When you create a Logic App with the SAP connector trigger "When a message is received from SAP", the configuration of SAP is non-trivial, especially for engineers not familiar with SAP. The first step is to create the connection itself. As you add for the first time either a trigger or an action from the SAP connector it will prompt you to create a connection, which if you don't all the connection parameters quite right may fail. In case you do not get all the error details in the Logic App Designer, enable network tracing under the F12 debugging tools of your internet browser (details for Edge network tracing here, details for Chrome network tracing here). Reproduce the connection creation failure and look for an HTTP call failure, look then at the response payload for that failure. You might find there for instance a failure to locate assembly SAP .NCo, and need to follow prerequisite step of download and install the latest SAP client library. You will need from SAP the program id to which you will register your RFC Server, aka tp partner in SAP terminology. If you don't have one already, create a new TCP/IP type connection in SM59 opcode (Configuration of RFC Connections) of the SAP Logon GUI. The activation type for that new destination must be "Registered Server Program". When you use the SAP built-in "Connection Test" for that RFC connection prior to creating the Logic App with the SAP trigger, you should get an error "Program ID not registered". This is also the error you get if you disable or delete the Logic App later. Then you enter the required details of your registration in the Logic App SAP trigger - SAP gateway host, service name or port, program id. Optionally you may provide a filter array of SAP action URIs so only specific RFC/BAPI/IDOC calls are sent to your Logic App. Once you save your new Logic App with its trigger, the RFC Server registration will happen. As you save the Logic App the trigger registration call is asynchronous. So you need to look at the trigger history (under the Logic App Summary Evaluation) to confirm it was successful. This is an example with a failed registration, that was followed by a successful registration, followed by a successful call by SAP of Logic Apps (the entry tagged 'Fired'). Here is the input details of a subscribe call for a new trigger: You may have succeeded saving the Logic App itself because the connection and parameters were valid as far as Logic App can assert, but the asynchronous registration may fail, which Logic App designer doesn't know. Here for instance the On-Premises Data Gateway was not connected to the VPN on which the SAP system resides, so the registration call timed out on failure to reach the IP address: Then connecting the OPDG to the SAP VPN, the registration succeeded. Note the specific response code 'Created', indicating that the OPDG did not have such SAP webhook registered before and created it accordingly: Note also the renewal internal of 5 minutes. This is to ensure that if the OPDG malfunctions for some reason, such as event of the hosting machine restarting, the webhook registration is repaired within 5 minutes of the OPDG coming back online. If you have an high availability setup of the OPDG, the fail-over OPDG will receive the renewal notice and realizing the webhook is not in its list will create it again. Here is an example respond for a renewal when the registration was already active (no call made to SAP in this case), note how the response code is different, 'OK' and not 'Created': In case you are troubleshooting your OPDG, have restarted the machine or the service and want to test the subscription call immediately, you can disable and re-enable the Logic App with the SAP trigger to force the immediate call to subscribe. Now with the Logic App registered as RFC Server on the given program ID, you can return to SAP Logon GUI and test the connection successfully: You can then proceed for a more thorough test by calling an actual RFC in SE37, Function Module op code. Don't forget to provide the matching Program ID as RFC target system. A good start is STFC_CONNECTION. See details of that in earlier post about responding back to SAP. Now sometimes the trigger registration by Logic App succeed and yet the SAP connection test still fails. You may be able to locate with the help of a SAP BASIS engineer error in the SAP Gateway logs such as: LOCATION SAP-Gateway on host SAP*****.*****.cloudapp. net / sapgw00 ERROR registration of tp DAVIBURG-P722 from host ??? not allowed TIME Tue May 07 18:49:57 2019 RELEASE 753 COMPONENT SAP-Gateway VERSION 2 RC 720 MODULE D:/depot/bas/753_REL/src/krn/si/gw/gwxxrd.c LINE 4184 COUNTER 900142 A couple of configuration aspects of SAP should be investigated in such case, starting with the SAP gateway security parameters. Please refer to the SAP documentation https://help.sap.com/doc/saphelp_nw73/7.3.16/en-US/48/ad5b358bc96744e10000000a421937/content.htm?no_cache=true Also, the SAP user account you are using to connect to SAP must be allowed to register as RFC Server. The user account may have for instance the role SAP_BC_AI_LANDSCAPE_DB_RFC to authorize this. This can be configured in either of SU01 (single user) or SU10 (bulk edit of users).

SAP Connector update, Gateway update release, SNC support, Strong/Safe Type

David Burg — Fri, 03 May 2019 16:52:20 GMT

Wow, what a day! An update to the On-Premises Data Gateway containing many improvements for SAP Connector for Azure Logic Apps is now live at: https://www.microsoft.com/en-us/download/details.aspx?id=53127 Furthermore we are deploying the update to the SAP Connector at this moment. We expect the deployment to reach all regions by early next week. Then, with the combination of both these updates you have now support for Kerberos-based SNC (Secured Network Communication). Also included the availability of Strong Typing vs "Safe" Typing, as described in earlier posts in this blog. We've improved the error response model of the connector to follow error condition response. Please note that the gateway update works in concert with the connector update for that, for the gateway will generate the specific exception details which the connector will use to fill the content of the error response. Also included the improvement to error response from Logic Apps to SAP described in earlier post.

Responding back to SAP from Logic App

David Burg — Wed, 17 Apr 2019 13:06:40 GMT

So you've registered SAP as a trigger in Azure Logic Apps, enabling SAP to call it as for any other RFC. But how do you parse the SAP request and respond back to it with actual content and not just a vanilla OK? If you enable the support for multiple RFCs by your Logic App for SAP to call, you need to arrange your logic by Action Uri, that trigger output json parameter which will contain which RFC got call by SAP. For this example we'll just consider a single RFC as a simplification - STFC_CONNECTION. The trigger has been configured for this one only, using the trigger input parameter action URI which causes the SAP Adapter in the On-Premises Data Gateway to act as a filter rejecting calls to other RFCs by SAP. [You can see an example of that in the summary picture at the bottom of this post.] The next step is to get the XML payload of the SAP RFC call. This is in the trigger output Content parameter @triggerBody()?['Content'], but natively as a string (because Json doesn't have a type for XML). So you want to cast the type to XML with @xml(triggerBody()?['Content']). Now Logic App knows this is XML as visible in the designer run history view: To manipulate the XML we can use the X-PATH native support, and here we'll extract the SAP RFC STFC_CONNECTION request text value with @{xpath(xml(triggerBody()?['Content']),'string(/*[local-name()=\"STFC_CONNECTION\"]/*[local-name()=\"REQUTEXT\"])')} Now we can use this extracted value to form a dynamic response to SAP with @{variables('REQUTEXTValue')}, such as in @{variables('REQUTEXTValue')}Received Calling from SAP Logon we can see the dynamic echo response: For a more complete manipulation of the input request, consider converting the request XML to Json (https://docs.microsoft.com/en-us/azure/logic-apps/workflow-definition-language-functions-reference#json) or transforming the XML with XSLT (https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-enterprise-integration-maps). Here is the designer view for this whole Logic App:

New Logic App connector error responses to SAP

David Burg — Tue, 16 Apr 2019 14:28:17 GMT

The next update to On-Premises Data Gateway SAP Adapter component for Azure Logic Apps SAP connector will include implementation of error condition translation to ABAP exception or BAPI return depending of what is available in the invoked RFC metadata. This will come in use when using the SAP trigger of the connector (when a message is received from SAP - https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-using-sap-connector#receive-from-sap) and an error condition is met, such as the RFC is excluded per the user provided SAP Action filter array, such as when the response XML payload is not valid, etc. For basic RFCs where no BAPI return is available, an ABAP exception will be raised. This will be the case for STFC_CONNECTION and alike RFCs. For RFCs with BAPI return, both SAP TABLE and STRUCTURE types (table and export directions) will be supported, for all of BAPIRETURN, BAPIRET1 and BAPIRET2 types. BAPI_PO_GETITEMS is an example of RFC using BAPIRETURN type table. APAR_EBPP_BALANCES is an example of RFC using BAPIRET1 type export structure. 1119_getdetail is an example of RFC using BAPIRET2 type table. In the SAP Logon GUI you need to open the returned table to see the response details: When the error response is not sufficient to determine the issue, refer to the SAP extended logs for the , which you can enable per the new SAP log file section of earlier blog post https://blogs.msdn.microsoft.com/david_burgs_blog/2018/08/15/new-extended-log-file-for-sap-connector-in-on-premises-data-gateway-coming-in-september/.

SAP Type handling connection parameter

David Burg — Wed, 03 Apr 2019 11:52:11 GMT

From our internal testing, the new connection parameter (Safe Typing check-box): The change is about to merge to our master branch for deployment in the following days. The update to the connector in the cloud will work in pair with a pending update to the On-Premises Data Gateway, while remaining backward compatible with current version of the gateway.

Continued: Strongly typed date, time and numerical fields from SAP DATS, TIMS and NUMC support in Azure Logic Apps SAP connector

David Burg — Fri, 29 Mar 2019 17:06:30 GMT

We're about to release the type handling improvements for Azure Logic App SAP connector previously announced here. The connection will have a new Boolean (true-false) parameter “SafeTyping”, enabling to treat DATS and TIMS as string rather than their XML equivalents xs:date and xs:time (where xmlns:xs="https://www.w3.org/2001/XMLSchema"). This is an opt-in behavior as we encourage our user to use strong types for early detection of issues. BizTalk Server users will recognize the name but be aware this only applies to date and time, not to NUMC as per earlier note we are handling NUMC as text value and not attempting to coerce them into integers.

     "SafeTyping": {
       "type": "bool",
       "uiDefinition": {
         "displayName": "Safe Typing",
         "description": "Use strong types if false, otherwise use string as safe type.",
         "tooltip": "Enables safe typing, which treats types as string instead of strong types (e.g. Date, Time, Datetime), relaxing type and value validations.",
         "constraints": {
...
           "required": "false",
...
         }
       },
       "defaultValue": "false"

     }

This parameter will affect the behavior of all of schema generation, send message (both the payload been sent and the response been received) and trigger. For schema, with “SafeTyping” enabled, the DATS and TIMS SAP types will map to XML string fields with length restrictions only, like this:

With strong typing (default of “SafeTyping” false), DATS and TIMS will map to the more straightforward XML types: Then for sending messages, SAP DATS and TIMS response with “SafeTyping” enabled will look like this: 99991231 235959 With strong typing (default of “SafeTyping” false), DATS and TIMS will comply to matching XML type format: 9999-12-31 23:59:59 See https://www.w3schools.com/XML/schema_dtypes_date.asp for reference. Samples for minimum values 00010101 000000 vs 0001-01-01 00:00:00 Of interest is the default value by SAP for these fields when the fields are not null: 00000000 000000 vs 00:00:00 Our strong type handling here maps SAP’s default date of 000000000 to XML nil because XML does not allow year, month or date value of 0 and does not have a special initial value other than nil equivalent to SAP’s all zeroes. TIMS SAP default of 000000 is a valid XML time value of 00:00:00. The same applies when SAP has all spaces stored in the DATS – TIMS fields, XML time will come up as 00:00:00 but date will be nill. Note that for NUMC fields the original 0s from SAP will be preserved and no trimming will occur. E.g.: 0 Will be now: 00000 Also we had a bug not translating the SAP null values to XML nil. We use to generate empty string values like this: Which will now be corrected to: Allowing to distinguish between empty string and null values.

Logic Apps SAP connector BAPI support - going under the hood

David Burg — Wed, 06 Mar 2019 10:54:59 GMT

In the series of posts about Logic Apps SAP connector I am talking today about some details of the implementation for the support of BAPIs. Similar to my recent post on IDoc action url and schema generation (IDoc post), when you are using BAPIs with Logic Apps SAP connector, you will need an action URL to identify the BAPI such as: https://Microsoft.LobServices.Sap/2007/03/Bapi/BUS6010/CHECK/BAPI_ACC_ACTIVITY_ALLOC_CHECK

https://Microsoft.LobServices.Sap/2007/03 is the namespace prefix for SAP uri in BizTalk & Logic Apps;
/Bapi is the node for all BAPIs (vs /Idoc, /Rfc, etc.);
/BUS6010 is the Business Object upon which the BAPI acts;
/CHECK is the Method performed on the Business Object;
/BAPI_ACC_ACTIVITY_ALLOC_CHECK is the RFC backing the BAPI action.

Business Object tree for picking the BAPI is built using the response to RFC RPY_BOR_TREE_INIT (external documentation link) with no input filter, looking at the output table BOR_TREE. SHORT_TEXT field is used for the names of sections and objects. A section is any row which CHILD field value is non-zero. You can use the PARENT field for a given Business Object if you need help figuring out which node it will show under in the picker UI of Logic Apps Designer. Method will be queried using RFC SWO_QUERY_METHODS (external documentation link) with the Business Object passed as value for the input parameter OBJTYPE and X value for input parameter TEXT to get the text output as well. The returned INFO table will be read, filtered to ABAPTYPE F only. The field METHOD contains the Method name we will use. This same response will provide the backing RFC name in the field ABAPNAME. Note that Business Object name, Method name and RFC name are all passed through .NET XmlConvert.EncodeName to ensure no illegal XML character conflicts. We may be using SWO_QUERY_API_METHODS in the future to enable a BAPI query feature.

Logic App SAP connector IDoc support - going under the hood

David Burg — Mon, 04 Mar 2019 21:52:46 GMT

While working on a customer inquiry, I recently investigated the details of our logic for IDoc support, including browsing which are available in the SAP system, forming the hierarchical view to pick an action URL from and generating the metadata / XML schema for the request-response payload. The following details are not a public contract, rather insights as to the current implementation which may help the readers in their use of the connector and troubleshooting of possible issue. These details are subject to change as we work on performance or functional improvements, while the external interface would remain the same. Programmatically the SAP Adapter for Logic Apps SAP connector is using RFC IDOCTYPES_FOR_MESTYPE_READ (gets the list of IDoc types, filter criteria * i.e. wildcard for all, external doc link), IDOCTYPES_LIST_WITH_MESSAGES (a bit strange way we are getting the SAP version release list, e.g. 700, 720, …), IDOC_RECORD_READ (gets the control segments and more by IDoc record types version, e.g. 2 or 3 - external doc link for the version here, external doc link for the RFC), IDOCTYPE_READ_COMPLETE (gets the specific idoc e.g. DELVRY01, ACC_DOCUMENT03) which can then be reproduced in SAP GUI using SE37 (Function Builder) F8 Test Function Module. When you look at an action URL for an XML request message sent to or received from SAP via the connector, like this: https://Microsoft.LobServices.Sap/2007/03/Idoc/3/DELVRY01//702/Send

/Idoc is the root node for all IDocs (vs. /Rfc, /TRfc, etc);
/3 is the record types version for common segment definitions obtained via IDOC_RECORD_READ;
/DELVRY01 is the IDoc type which definition will be read with IDOCTYPE_READ_COMPLETE;
/702 is the SAP version release.