Using Logic App Standard to connect to SAP
1. Overview: SAP Connector ( ) is a Enterprise connector which provides a set of actions and triggers to connect to your SAP Service. Ref: SAP - Connectors | Microsoft Learn 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. 2. Connecting and Creating a Workflow: Create a new Logic App Standard. Ref: Create Standard workflows in single-tenant Azure Logic Apps with the Azure portal - Azure Logic Apps | Microsoft Learn Upload all required SAP Private DLLs as Client/SDK Assembly (.NET Framework). See below for known issue with DLLs larger than 4 MB. All SAP Libraries (like sapnco.dll, sapnco_utils.exe, libicudecnumber.dll, rscp4n.dll, also visible here SNC's sapcrypto.dll, sapgenpse.exe, slcryptokernel.dll which are discussed later below) were uploaded to Assemblies. Throws Exception: If any of these libraries are missing, the following exception will be thrown: HttpStatusCode: BadRequest ErrorCode: ServiceProviderActionFailed ErrorMessage: The service provider action failed with error code 'ServiceOperationFailed' and error message 'SAP client library is missing. Please add pre-requisites SAP .NET Connector client library assemblies to the workflow application. Detailed error message 'Could not load file or assembly '{assembly name}' Enable vnet integration and private ports by following this article: Enabling Service Bus and SAP built-in connectors for stateful Logic Apps in Standard (microsoft.com) Add an SAP Action to the workflow. Create a connection (Refer Section 2.2) and run the workflow. Throws Exception: If there is any error while connecting to SAP using the created connection parameters, it will throw below exception: HttpStatusCode: BadRequest ErrorCode: ServiceProviderActionFailed ErrorMessage: The service provider action failed with error code 'ServiceOperationFailed' and error message 'Call to SAP client library failed with error message '{error message}' '. 2.2 Creating SAP Connections: 2.2.1 Using Username and Password: You can create a simple Username and Password connection by selecting 'Auth Type' as 'Basic' and providing required fields in 'Add Connection' pane. Then click Create. 2.2.2 Using SNC You can create a SNC connection by selecting 'Auth Type' as 'Logon Using SNC' and providing required fields in 'Add Connection' pane. For SNC to work properly, you need to upload SAP Libraries namely (sapcrypto.dll, sapgenpse.exe, slcryptokernel.dll) using Assemblies pane in Azure portal. For SNC Partner Name, enter the backend's SNC name. For example, p:CN=DV3, OU=LA, O=MS, C=US . For SNC Certificate, enter your SNC client's public certificate in base64-encoded format. Don't include the PEM header or footer. Don't enter the private certificate here because the PSE might contain multiple private certificates, but this SNC Certificate parameter identifies the client certificate that must be used for this connection. 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. We recommend however that you create separate Workflow applications if you intend to authenticate with different client certificates. The PSE must have no PIN. If needed, set the PIN to empty using the SAPGENPSE utility. Then click Create. 3. Known Issues Assemblies tab doesn't allow uploading libraries above 4MB. As a workaround you can follow steps below: All SAP libraries can be uploaded to site/wwwroot/lib/builtinOperationSdks/net472/* using kudu tool. Open Kudu tool: Navigate to site/wwwroot : Create Directory lib/builtinOperationSdks/net472/ (if it does not already exist): Upload all your SAP/SNC assemblies to site/wwwroot/lib/builtinOperationSdks/net472/* : NOTE: SAP Connector is in Preview and doesn't guarantee SLA and latency requirements.
Scaling Logic Apps Standard – Sustained Message Processing System
In the previous blog of this blog post series, we discussed how Logic App standard can be used to process high throughput event data at a sustained rate over long periods of time. In this blog, we will see how Logic App standard can be used to process high throughput message data that can facilitate the decoupling of applications and services. We simulate a real-life use case where messages are sent to a Service Bus queue at a sustained rate for processing, and we use a templated Logic App workflow to process the messages in real-time. The business logic in the templated workflow can be easily replaced by the customer to actions that encompass their unique processing of the relevant messaging information. To better showcase the message processing capabilities, we will discuss two scaling capabilities, one for vertical scaling (varying the performance of service plans), and another horizontal scaling (varying the number of service plan instances). Vertical scaling capabilities of the Logic App Standard with Built-In Service Bus Connector In this section, we will investigate the vertical scaling capabilities of the Logic App Service Bus connector, conducting experiments to find the maximum message throughput supported by each of the standard Logic App SKUs from WS1 to WS3. The workflow uses the Service Bus built-in trigger, so the messages are promptly picked up and are processed in the run at par with ingress rate. like the one shown below - available at our Template Gallery. Customers can replace the Business Logic and Compensation Logic to handle their business scenarios. For this investigation, we used the out-of-the-box Logic Apps Standard configuration for scaling: 1 always ready instance 20 maximum burst instances We also used the default trigger batch size of 50. Experiment Methodology For each experiment we selected one of the available SKUs (WS1, WS2, WS3), and supplied a steady influx of X messages per minute to the connected Service Bus queue in one experiment. We conduct multiple experiments for each SKU and gradually increase X until the Logic App cannot process all the messages immediately. For each experiment, we pushed enough (1 million) messages in total to the queue to ensure that each workflow reaches a steady state processing rate with its maximum scaling. Environment Configuration The experiment setup is summarized in the table below:  Tests setup Single Stamp Logic App Number of workflows  1 Templated Triggers  Service Bus Trigger batch size 50 Actions  Service Bus, Scope, Condition, Compose Number of storage accounts  1 Prewarmed instances  1 Max scale settings  20 Message size 1 KB Service Bus queue max size 2 GB Service Bus queue message lock duration 5 minutes Service Bus queue message max delivery count 10 Experiment results We summarize the experiment results in the table below. If the default maximum scaling of 20 instances is adopted, then the throughput we measured here serves as a good reference for the upper bound of message processing powers: WS Plan Message Throughput Time to process 1M messages WS1 9000 messages/minute 120 minutes WS2 19000 messages/minute 60 minutes WS3 24000 messages/minute 50 minutes In all the experiments, the Logic App scaled out to 20 instances at steady state. � Complex business logic, which requires more actions and/or longer processing times, can change those values. Findings Understand the scaling and bottlenecks In the vertical scaling experiments, we limited the maximum instance count to 20. Under this setting, we sometimes observe "dead-letter" messages being generated. With Service Bus, messages become "dead-letters" if they are not processed within the lock duration for all delivery attempts. This means that the workflow takes more than 5 minutes to complete the scope/business logic for some messages. The root cause is that the Service Bus trigger fetches messages faster than the workflow actions can process them. As we can see in the following figure, the Service Bus trigger can fetch as much as 60k messages per minute, but the workflow can only process less than 30k messages per minute. Recommendations We recommend going with the default scaling settings if your workload is well below the published message throughput and increase the maximum burst when a heavier workload is expected. Horizontal scaling capabilities of the Logic App Service Bus connector In this section, we probe into the horizontal scaling of Logic App message handling capabilities with varying instance counts. We conduct experiments on the most performant and widely used WS3 SKU. Experiment Methodology For each experiment we varied the number of pre-warmed instances and maximum burst instances and supplied a steady influx of X messages per minute to the connected Service Bus queue, gradually increase X until the Logic App cannot process all the messages immediately. We push enough (4 million) messages to the queue for each experiment to ensure that each workflow reaches a steady state processing rate. Environment configuration The experiment setup is summarized in the table below:  Tests setup Multi Stamp Logic App Number of workflows  1 Templated Triggers  Service Bus Trigger batch size 50 Actions  Service Bus, Scope, Condition, Compose Number of storage accounts  3 Message size 1 KB Service Bus queue max size 4 GB Service Bus queue message lock duration 5 minutes WS Plan WS3 Service Bus queue message max delivery count 10 Experiment results The experiment results are summarized in the table below: Prewarmed Instances Max Burst Instances Message Throughput 1 20 24000 messages/minute 1 60 65000 messages/minute 5 60 65000 messages/minute 10 60 65000 messages/minute 10 100 85000 messages/minute In all the experiments, the Logic App scaled out to the maximum burst instance allowed at steady state. Editor's Note: The actual business logic can affect the number of machines the app scales out to. The performance might also vary based on the complexity of the workflow logic. Findings Understand the scaling and bottlenecks In the horizontal scaling experiments, when the max burst instances count is 60 or above, we no longer observe "dead-letters" being generated. In these cases, the Service Bus trigger can only fetch messages as fast as the workflow actions can process them. As we can observe in the following figure, all messages are processed immediately after they are fetched. Does the scaling speed affect the workload?   As we can see below, a Standard Logic app with a prewarmed instance count of 5 can scale out to its maximum scaling of 60 under 10 minutes. The message fetching and message processing abilities scale out together, preventing the generation of “dead-letters.� Also, from the results in our horizontal scaling experiments, we see that having more prewarmed instances does not affect the steady-state throughput of the workflow. Recommendations With these two findings, we recommend keeping the minimum instance number small for cost-saving, without any impact on your peak performance. If a use case requires a higher throughput, the maximum burst instances setting can be set higher to accommodate that. For production workflows, we still recommend having at least two always-ready instances, as they would reduce any potential downtime from reboots.Extending Logic Apps App Insight integration with Azure Workbooks
With the improvements we made in Logic Apps integration with App insight, we streamlined how various types of Logic Apps associated events get emitted and ingested into Application Insights. This change also improved how they get mapped to existing application insight concepts such as requests, dependencies, and exceptions. Azure workbooks provides a flexible canvas for data analysis and the creation of rich visual reports within azure portal. Azure workbooks also replace Azure monitoring solutions which we had been using with Consumption Logic Apps to build visual dashboards on top of Log Analytics data from consumption Logic Apps. In this blog post we are going to show how we can use Azure workbooks together with recent improvements to application insight integration to build similar rich and interactive dashboards for standard Logic Apps.
