Enabling Service Bus and SAP built-in connectors for stateful Logic Apps in Standard

[edwardyhe]

Service Bus and SAP built-in connectors in Logic App Standard contain many triggers and actions that were previously restricted to stateless Logic Apps only. Beginning in April, these triggers and actions are now available for use in stateful Logic Apps. This article explains the requirements needed to successfully use this new feature.

Some Service Bus and SAP built-in connector triggers and actions were not previously enabled in stateful workflows as they required triggers and/or actions to be performed by the same instance. This was done by default in stateless workflows but was far from guaranteed in stateful workflows previously. With the update in April, we have added a framework for stateful workflows to be able to complete these requirements, which allows us to enable these connector triggers and actions for stateful workflows.

This feature depends on communication between instances to maintain connection context. For security, the associated Logic App must be contained within a VNet, and a site configuration needs to be set. We are working to automatically set this site configuration for customers in the future. In the meantime, please follow the below instructions:

Instructions

• Enable VNet integration for the Logic App and place it in subnet

Adding VNet integration in portal.

• Update site config via ARM API.

  • HTTP method is PATCH
  • The resourceId is of the form: subscriptions/{subscriptionId}/resourcegroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/config/web
  • A sample URI for the request is: 

    https://management.azure.com/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/test-rg/providers/Microsoft.Web/sites/test-site/config/web?api-version=2021-02-01

  • Authorization is required (OAuth). The bearer token can be obtained from the portal in browser from Developer Tools (F12), and obtaining the token from any management request, for example when saving a workflow.
  • HTTP content is: {"properties": {"vnetPrivatePortsCount": "2"}}

• To prevent loss of context during scaling in, fix the number of instances available in the logic app. Set the number of always ready instances to be equal to the maximum scale out limit and maximum burst.

Preventing scale-in events.

Alternative method to update site config via Powershell

This method circumvents the need to manually obtain the bearer token.
Replace {subscriptionId} and {resourceId} with your subscriptionId and resourceId (see above for resourceId format).

  Set-AzContext -Subscription {subscriptionId}
  $webConfig = Get-AzResource -ResourceId {resourceId}
  $webConfig.Properties.vnetPrivatePortsCount = 2
  $webConfig | Set-AzResource -ResourceId {resourceId}

If you get the error:

  Set-AzResource :
  {
    "Code":"BadRequest",
    "Message":"siteConfig.ReservedInstanceCount is invalid.  Please use the new property siteConfig.PreWarmedInstanceCount.",
    "Target": null,
    "Details":
    [
      {
        "Message":"siteConfig.ReservedInstanceCount is invalid. Please use the new property siteConfig.PreWarmedInstanceCount."
      },
      {
        "Code":"BadRequest"
      },
      {
        "ErrorEntity":
        {
          "ExtendedCode":"51021",
          "MessageTemplate":"{0} is invalid. {1}",
          "Parameters":
          [
            "siteConfig.ReservedInstanceCount", "Please use the new property siteConfig.PreWarmedInstanceCount."
          ],
          "Code":"BadRequest",
          "Message":"siteConfig.ReservedInstanceCount is invalid. Please use the new property siteConfig.PreWarmedInstanceCount."
        }
      }
    ],
    "Innererror": null
  }

Workaround with:

  $webConfig.Properties.preWarmedInstanceCount = $webConfig.Properties.reservedInstanceCount
  $webConfig.Properties.reservedInstanceCount = $null
  $webConfig | Set-AzResource -ResourceId {resourceId}