Logic App SAP connector all the logs to capture for troubleshooting and requesting support


Here is a review of holistic logs applicable to SAP connector for Azure Logic Apps.

I have previously blogged how to enable NCo library tracing, in which I mentioned both the Logic App run history and Gateway logs as well. I am not repeating here the NCo logging details and rather expand on other logs.


From the Logic App run history you should include the full response text / output. It is fine to include a screenshot for the formatting and coloring, but please do include the string itself as we can faster do text search for know issue or code reference based on the text than if we have to recreate the string by copying each character from a picture. Do include your subscription id, resource group, the Logic App name (and id if you know how to get it) and run id.

If you are participating to the SAP trigger preview or if that feature is generally available when you read these and your issue is with the trigger, do review the trigger history for response and failures as it is separate from the run history.

If the issue happens in the Logic App designer - for instance as you are picking a SAP action URI or entering connection properties / trying to create a new connection - open the debug console with F12, go to the network tab and spot failed requests in red. Again do copy the full response text to speed up our support to you:

Often SAP issues are specific to a unique SAP action / RFC / BAPI / IDOC, be sure to include the SAP action URI for which you experience the problem. Also do help us locate the SAP action in the designer picker hierarchy, as SAP systems often include a very large number of possible actions.

In the gateway logs you should be able to locate SAP message requests with this:

[DM.GatewayCore] Deserialized GatewayXmlWebRequest, executing

And exception trace matching to your error alike this:

Microsoft.PowerBI.DataMovement.Pipeline.Diagnostics.XmlProcessorException: The timeout expired while trying to get a connection;

(The specific exception text will vary.)

Do include the full exception stack in your support request. Note that there will be two stacks and the second one like below is particularly useful to us:

  TemplateMessage: Error processing XML for the LOB Operation

GatewayPipelineErrorCode=DM_GWPipeline_Gateway_XmlPropertyParseException --->
Inner exception chain: System.TimeoutException
System.TimeoutException: The timeout expired while trying to get a connection

Server stack trace: 
   at Microsoft.ServiceModel.Channels.Common.Design.AdapterExceptions.ThrowTimeoutException(String exceptionMessage, Object source)
   at Microsoft.ServiceModel.Channels.Common.Design.TimeoutHelper.ThrowIfTimeoutExpired(String exceptionMessage, Object source)
   at Microsoft.ServiceModel.Channels.Common.Design.ConnectionPool.GetConnection(Guid clientId, TimeSpan timeout)
   at Microsoft.ServiceModel.Channels.Common.Design.ConnectionPool.GetConnectionHandler[TConnectionHandler](Guid clientId, TimeSpan timeout, MetadataLookup metadataLookup, String& connectionId)
   at Microsoft.ServiceModel.Channels.Common.Channels.AdapterRequestChannel.OnOpen(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at System.ServiceModel.ICommunicationObject.Open()
   at Microsoft.Integration.LobServiceBroker.WcfRuntime.SendToLob(String message, String messageAction, AdapterBinding adapterBinding, String address, String userName, String password, String clientId, String messageId)
   at Microsoft.Integration.LobServiceBroker.Broker.SendMessage(String payload, Dictionary`2 properties, String userName, String password, String address, AdapterBinding binding)
   at Microsoft.Integration.LobServiceBroker.Broker.SendToLob(String payload, Dictionary`2 properties)
   at Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.GatewayXmlWebProcessor.ExecuteLobRequest(GatewaySerializationContext responseContext, GatewayXmlWebRequest gatewayXmlWebRequest, Boolean checkCredentials)
   --- End of inner exception stack trace ---

Do note the inner exception from the above stack, this is useful for the next advanced step.

We can write more targeted fix and unit test against the troublesome code by extracting input parameters from a memory dump. Below are instructions on how to capture it at the moment a specific exception occurs.

We would suggest to capture exception dump for “System.FormatException” [replace with the inner exception found in the gateway log]. Could you please help to setup the debugdiag rule as below and send us the dumps if the rule is triggered?

Action Plan
===========
Use DebugDiag to configure rule for “System.FormatException”.
1. Download Debugdiag from http://www.microsoft.com/en-us/download/details.aspx?id=49924 and install on the problematic machine.
2. Click Start menu -> All Programs->Debug Diagnostics Tool 2.0 ->DebugDiag 2.0 Collection. Click Add Rule (If Select Rule Type Window popped already, go to step 3 directly)
3. Select Crash and click Next

4. Select A specific process and click Next. (Ensure your script not restart the DWG service for repro)

5. Select the Microsoft.PowerBI.EnterpriseGateway.exe and Click Next
6. In Advanced Settings, Click Exceptions….

7. Click Add Exception…

8. Select the E0434352 (CLR (.NET) 4.x Exception) item. In the Exception Type, please input “System.FormatException” manually.
Please NOTE, this is case sensitive. Follow the screen snapshot to configure it (Action Type is “Create Full Userdump”, Action Limit is “3” – ignore that the exception type in this sample screenshot is different):

9. Click OK and Click Save & Close

10. Click Next:

11. Click Next:

12. Click Finish:

13. And the crash rule should be activated as follow. When the issue reoccurs, please check the “Userdump Count” to see if crash dump generates during the issue. Please help to monitor the server and check if dump files generate at the issue reoccurrence.

Comments (1)

  1. Mikael Sand says:

    Very useful and just really hard core for those of us that need to debug/trace in this level. Good stuff!

Skip to main content