This blogs shows how to set up Topic Subscription Filters. Specifically, I will continue to record my experiences migrating a BizTalk interchange. In the same way as my last post this is a beginners guide to using Topics.
Azure solution overview
Formerly in that post I show an overview before talking about a pre-processing logic app. To summarize this logic app transforms an incoming message to a canonical order and sends it to a Topic. This time I will guide you through the design of Azure Service Bus Topic.
One of the tenets of the migration is to reuse as much as possible from the original BizTalk design. While this might not give the minimal Azure cost, I think it ensures that we follow good integration practices.
Thus the BizTalk design sends all the canonical orders to the message box. Subsequently, a publish-subscribe mechanism sends these order to send ports using the supplier code in the message. A supplier code maps to a AS2 party agreement. In brief this post describes this party resolution design.
How can we use Azure components to do the same thing? An Azure Service Bus Topic implements a publish/subscribe model. A topic receives messages via subscriptions. Each Topic Subscription optionally implements a filter that specifies which messages it will receive. In contrast to a service bus queue, this allows multiple receivers to receive the same message. The filter on the Topic subscriptions catches the message. A receiver picks up from a specific Topic subscription. The rest of this post describes how to use this to mimic the BizTalk design.
Setting up Azure Topic Subscription Filters
The first thing to remember is that we want to set up Topic subscriptions that map to AS2 parties. Many supplier codes can map to a party. I will use the Azure portal to create the Topic subscriptions.
Firstly I set up an Azure Service Bus. This time I chose a standard or premium tier because these are only ones that support a topic. Secondly provision a topic with the default settings. Thirdly create the Topic subscriptions on the topic. Microsoft document all these steps here.
At this point the Topic subscriptions look like.
I only show 3 Topic subscriptions for simplicity. The final implementation may have more than 20 Topic subscriptions, one for each AS2 party.
Topic Subscription Rules contain the filter. I could not find any way to add rules to the Topic subscriptions in the Azure portal. Hence I resorted to using the Service Bus Explorer tool on GitHub. This unfortunate because it makes the development experience a bit clunky. At the end of the day this is not of concern because the final deployment will use Azure Arm templates. Deploying Topic subscriptions via arm templates can create rules too.
Topic Subscription Filters are like SQL where clauses. Thus Contoso has a filter like “suppliercode = 1” and Fabrikam has a filter like “suppliercode=2”. The suppliercode property is 1 and 2 respectively. Both of these rules are on the same subscription because they both go to the same party. The supplierpo-contoso-sub only receives orders containing a supplier code of 1 or 2. There is another topic subscription which only receives orders with a supplier code of 11859 or 27352.
Setting up Topic Subscription Actions
Finally is the right hand box above I add a new property value for the EDI agreementname. I will use this later when I create the AS2/EDIFACT order. Thus the expression “SET agreementname=BidvestAU-Fabrikam-EDI” adds a new property to the message. This is an example of a Topic Subscription Action.
To summarize I shown above how to set up an Azure Topic subscription with rule filters and actions.
Catching orders that don’t have a matching Topic Subscription Filter
What happens if there is no matching filter when a Topic Subscription receives a message? In this case the message is lost. If the Enable
In contrast, the BizTalk behaviour if there is no matching subscription is to suspend the message. Now if there is no matching party agreement for the order then the ERP receives an negative functional acknowledgement(NACK). In other words, I need a way of catching orders that don’t have a matching topic subscription filter.
If you create a topic subscription , it contains a default rule with a filter of “1=1” to begin with. All my topic subscriptions delete this, adding a specific filter on suppliercode only.
My solution creates a Topic Subscription called au-supplier-dev-topicnosubscribers-sub which has a NOT IN filter that contains all the suppliercode’s. To put it differently, all orders without matching subscriptions on a suppliercode go to this subscription instead. This I not ideal because adding a new suppliercode Topic Subscription filter requires that we change this filter.
Conclusion
A walkthrough of Topic Subscription filters shows how you can use the Service Bus Explorer to set them up. The examples show a equality, NOT IN and a SET filter expression. Finally with the topic subscriptions in hand, setting up the post-processing logic app subscribers can begin .
Monitor Azure Service Bus and Achieve end-to-end message tracing in every business transaction stage along with necessary properties.
Explore more on Service Bus Namespace – Standard or Premium Tier?
