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.

​Microsoft Tech Community – Latest Blogs –Read More