Blog Post

Azure Integration Services Blog
3 MIN READ

Logic Apps Standard - Service Bus In-App connector improvements for Peek-lock operations

WSilveira's avatar
WSilveira
Icon for Microsoft rankMicrosoft
Aug 05, 2024

In collaboration with Divya Swarnkar and Aprana Seth.

 

Service Bus In-App connector is bringing new triggers and actions for peek-lock operations. Those changes will allow peek-lock operations in message and queues that don’t require session to be started and completed from any instance of the runtime available in the pool of resources, removing previous requirements for VNET integration and fixed size or role instances, which were needed because of the underlying client SDK used by the connector.

 

The new trigger and actions will be the default operations for peek-lock, but will not impact existing workflows. Read through the next sections to learn more about this update and its impact.

 

New triggers

 

Starting from bundle version 1.81.x, you will find new triggers for messages available in a queue and topic using the peek-lock method:

 

 

New Actions

 

Starting from bundle version 1.81.x, you will find new actions for managing messages in a queue or topic subscriptions using the peek-lock method are added for queue and topic.

 

 

What is the difference between this version and the previous version of the connector

 

The new connector actions require details of the repository holding the message (queue name / topic and subscription name) as well as lock token, where the previous item required the message id.

 

This allows the connector to reuse or initialize a client in any instance of the runtime available in the pool of resources. With that, not only the pre-requisites of VNET integration and fixed number of role instance is remov but also the requirement of the same Message Receiver that peeked the message being the workflow that execute all the actions is removed. For more information about the previous connector requirements, check this Tech community post.

 

What is the impact of existing workflows that used the previous version of the Service Bus actions?

 

The previous actions and triggers are marked as internal actions now. This is how Logic Apps indicates that the actions define in existing workflows are still supported by the runtime, both at design and workflow execution, but shouldn’t not be used for new workflows.

The impact for you as a developer is:

 

  • Workflows with old version of the trigger and actions will show normally in the designer and be fully supported by the runtime. This means that if you have existing workflows you will not need to change them.
  • The runtime do not support the new and old version of the actions in the same workflow. You can have workflows that uses each version independently, but you can’t mix and match version in the same workflow.

 

This means that if you need to add Service Bus actions in a workflow that already have actions from the previous versions of the connector, all actions must be changed to the new workflow. Notice that all properties from the old version exists in the new one, so you can simply replace the individual actions, providing the required parameters.

 

What happens with my workflow require session support?

 

If your workflow requires session, you will be using the existing trigger and actions that are specific for session. Those actions are the same from the previous version, as the underlying SDK doesn’t provide the support to execute action against a message in a repository that is session enabled from any client instance. 

 

That means that the VNET integration requirement, which existed for session in the previous connector, is still required. The requirement for fixed number of role instances have been removed in a previous update, when the connector received the concurrency support. You can read more about the Service Bus connector support for sessions here.

 

What happen if I am using the Export Tool to migrate my ISE Logic Apps?

 

As customers are still running their last effort to migrate Logic Apps from ISE to Logic Apps Standard, with many migration processes underway, we decided to keep the previous version of the Service Bus connector as the migrated connector. The reason for that decision was that lots of customers are still actively migrating their ISE logic app fleet, with some workflows already migrated, others still being migrated. Having two different connectors coming from the same export process would confuse customers and complicate their support during runtime.

 

After the ISE Retirement is completed, we will update the export tool to support the latest version of the connector.

Updated Aug 19, 2024
Version 2.0
Connectors
Logic Apps
Messaging
  • WSilveira's avatar
    WSilveira
    Icon for Microsoft rankMicrosoft
    Aug 08, 2024

    Hi MitchAbel is under deployment, so you should be seeing it available in the next weeks.

    The docs suggest [1.*, 2.00) meaning anything between version 1 and 2.00. You can find the bundle under which your app is running by going to one of the workflows in the overview page - you will see it under Runtime Version:

     

     

    In this example the Runtime Version is 1.70.96, which is the current latest version. Next version is going to be a variation of 1.81

  • MitchAbel's avatar
    MitchAbel
    Copper Contributor
    Aug 08, 2024

    This is great news WSilveira! Question around when this will appear.

     

    You say bundle version 1.81.x. Is that GA now? Is there any documentation around setting the bundle version outside of the default docs which suggest [1.*, 2.0.0)

     

    How does one check what bundle version the app is picking up? Somewhere in Kudu?

  • Sahin365's avatar
    Sahin365
    Copper Contributor
    Aug 14, 2024

    Manually did changes to the workflow(s) to move to the new connector (with Suffix V2) and replacing messageId with lockToken in VSCode. But when I open the designer afterwards, I see this:

     

    and 

     

     

    How do I get the parameter section of an action and the service bus trigger back to work?

     

  • WSilveira's avatar
    WSilveira
    Icon for Microsoft rankMicrosoft
    Aug 14, 2024

    Sahin365 , can you share the previous version and the new version of the workflow, so we can compare - you can send it via email, or share a gist directly with me.

  • WSilveira's avatar
    WSilveira
    Icon for Microsoft rankMicrosoft
    Aug 14, 2024

    Sahin365, another thing to take in consideration is that if you are making those changes locally, in VS Code, the bundle is only deployed to VS Code after it has been deployed to all regions (so VS Code bundles are the last one to be deployed). This deployment is still finishing in the cloud, so only after that you will have it available in VS Code.

     

    You can confirm that you have the right bundle in the cloud by checking the following folder:

     

    C:\Users\<username>\.azure-functions-core-tools\Functions\ExtensionBundles\Microsoft.Azure.Functions.ExtensionBundle.Workflows

     

    This will be available to be used once you find the following folder there: 1.81.24 or later. This is when you will have the new version of the connector available.

  • Sahin365's avatar
    Sahin365
    Copper Contributor
    Aug 15, 2024

    WSilveira. Before I share any workflow.json with you, I have checked the extensionbundles folder  for the workflow bundle and the latest version is 1.70.96. Is there any way to manually add it or to force update it?

  • WSilveira's avatar
    WSilveira
    Icon for Microsoft rankMicrosoft
    Aug 15, 2024

    Sahin365, 1.81.x is been deployed to VSCode tomorrow according to our current deployment train. I would suggest trying tomorrow or Friday and check after that.

  • Sahin365's avatar
    Sahin365
    Copper Contributor
    Aug 15, 2024

    WSilveira I have an additional question (We already have a running support ticket), but I was asked to check this blog.

    We have been facing affinity issues, even though we followed the documentation, and got support and were pointed out to these new connectors.

     

    For most of our integrations, the update of the connectors seem to work fine. However, when we use sessions for messages (between 2 logic apps in order to pick the right message based on a session id), it seems that we are forced back to the old connectors (messageid). These do not work with the new ones (locktoken). We also need to do changed in the code editor because the properties differ based on the selected approach. But the old connectors give us the affinity issue, which happen more than often.

     

    So,

    With this update we try to use this action:


    But we are not able to complete the message with this action:

    Which under the hood became  completeQueueMessageV2 operation (with lock-token). 

     

    We get the error:

     

     

     

     

    {
  "code": "ServiceProviderActionFailed",
  "message": "The service provider action failed with error code 'BadRequest' and error message 'It is not possible for an entity that requires sessions to create a non-sessionful message receiver. TrackingId:xxxxxxxxxxx_B0, SystemTracker:gi::G2:xxxxx:amqps://xxx.servicebus.windows.net/-xxxxxx;43:48:49:source(address:/sbq-xxx-in,filter:[]), bi::in-connection226763(G2-6416)::session226764::linkxxxxxxx, Timestamp:2024-08-15T13:59:33 TrackingId:xxxxxxxexxxxxxxx_G2, SystemTracker:gateway10, Timestamp:2024-08-15T13:59:33\r\nFor troubleshooting information, see https://aka.ms/azsdk/net/servicebus/exceptions/troubleshoot.'."
}

     

     

     

     

     

    This leaves a session based message on the queue, without any option to remove it. This seems to be a limitation with v2/preview actions. In my opninion the 

    getMessagesFromQueueSession shouldn't be there if you cannot remove it from the queue.

     

    Any thoughts would be appreciated.

  • SartajSingh1730's avatar
    SartajSingh1730
    Copper Contributor
    Oct 10, 2024

    HI WSilveira 

     

    To use concurrency control for Service Bus built-in connector the following two settings are also required for V2 Triggers

     "operationId": "peekLockQueueMessagesV2" as documented under Concurrency support for Service Bus built-in connector in Logic Apps Standard
     

    My question is basically do the concurrency-support-for-service-bus-built-in-connector-in-logic settings also apply to the Service Bus built-in connector V2 Triggers as documented here?

     

    1.  

     

          2. Update host.json through code viewUntil the feature becomes available through designer, you also need to update batch setting in                   host.json file.  To open host.json file, open your Standard Logic Apps, and select under Development Tools : Advanced Tools > Go >                 Debug console > CMD. In the file system open, site\wwwroot. You can update host.json using the command line or Edit button.

     

    Thanks

    Sartaj