how to send a message to azure service bus Topic (subscription using) Logic app send message connector? - azure

I have a Azure service bus Topic with two subscriptions.
I want to send a message to topic from logic app using send message connector. How to send the message to a specific subscription.
Now it takes only topic name and does not have property to accept subscription name, how can i implement the same.
thanks in advance.

Unfortunately, that is not possible (just not with logic apps, but in general)
This is how a topic and subscription works.
A Service Bus topic provides an endpoint for sender applications to
send messages.
Each subscription of a topic gets a copy of the message sent to the topic.
Topics and subscriptions provide a one-to-many form of communication.
Having, said that you can configure filters at the Subscription end. This will facilitate receiving only those messages meeting the criteria from the central pool. When you want a specific subscription to receive it. You could send the message such a way that it matches the filter condition.
So, something like this :
Image Source
100 messages are sent to the topic, but are split to each subscription as 30,45,25 based on the filter rule. the messages that did not meet filter are not made available to the subscription.
In your case, you need set filters for both the subscription. Trigger the message such a way that it matches only for one of the subscription.
Alternatively, if it is going 1:1 - you could make use of the Queue.
References to set up filters at subscription level :
Filters Service Bus
Filtering the Service Bus
Stackthread on the implementation

A subscription in Service Bus is an isolated view into the messages of a Topic, essentially a copy of the messages private to the subscription. This allows multiple consumers to process topic messages without competing with one another.
You can't publish messages messages directly to a subscription, only to the topic that the subscription is associated with. All subscriptions associated with the topic will have access to the message.
If you are looking to send messages for a single consumer (or a set of competing consumers), a Service Bus queue may be a better fit for your scenario.

Related

Send message to specific subscription instead of topic in Azure Service Bus

Is it possible to send a message to a specific subscription instead of a topic in Azure Service Bus? I would like to send a message only to one subscription of a topic (which means all subscriptions will receive the message). It is somehow possible in the Azure portal (see screenshot), and I was wondering if it's possible with the REST API (or C# skd).
option to send to a subscription in Azure Portal
Messages are never sent to a subscription. You always publish/send to a topic and subscriptions receive the messages that satisfy the criteria specified for each subscription via subscription rules. If you need a specific message type/payload to be received by only a single subscription, you need to specify the rules on that subscription to be the only subscription to evaluate the rules to true.
Alternatively, use a queue. A queue is good for a scenario when you know the receiver.

Architecture routing from a message between 2 responders

I read myself a bit about azure service bus. There many examples how I can set it up, create a queue and get information from the queue.
Now I have a question. When I have a second responder (for example an azure function / With different functionality) I must create a new queue? Or how is routing from the message between these two responders.
Regards
If you want your message to be received and processed by more than one receivers, you should look into Service Bus Topics.
Service Bus Topics are meant for one to many mapping, where a message sent to a Topic can be received from different Subscriptions.

Azure Service Bus Topic subscription concurency

I have following requirement
Message published to the Topic/Queue
Multiple consumers subscribed to the Topic/Queue. So our requirement is to only one consumer should listen to the message. That means no other consumer can get the same message.
I feel queue would be the best fit. But I have advise from our architect to check whether we can achieve it from Topics?.
So any body please let me know whether we can achieve it through Topics and also pros and constrains?
Thanks.
Azure Service Bus Queue is a single message queue. You send it a message and the message receiver will get the message and be able to process it accordingly. Each message will only be handled once.
Azure Service Bus Topic is a more robust message queue than Azure Service Bus Queue. With Topics there can be multiple Subscriptions configured to catch messages based on a Filter. If multiple Subscriptions have a Filter that matches an incoming message, then each of those Subscriptions will get a copy of the messages. With Topics it's up to you to configure the Subscription Filters according to your projects needs.
If you know a message only needs to be handled once in your system and the message queue is being used by a single message receiver application (single or multiple hosted instances) then Azure Service Bus Queue is likely the tool for the job.

durable subscriber pattern with azure service bus

I'm looking to use Azure Service Bus with topics but need to handle the scenario where a subscriber might not be listening for a message it's interested in (e.g. server being rebooted etc.). This is the typical durable subscriber pattern as described here http://www.eaipatterns.com/DurableSubscription.html.
What I can't work out is how to apply this with Azure Service Bus and I can't seem to find any examples or discussion of this in the documentation. Is this something that Azure service bus provides or should I start looking at alternatives to Azure Service Bus?
This is built straight into Service Bus. As long as a subscription is created it is durable. You create a topic and then create one or more subscriptions. One or more consumers then listen to a subscription when they are active. If they go inactive, such as the server being rebooted, then the subscription stores the messages until a consumer comes back up and asks for one.
Service Bus would only be nondurable if you were creating and destroying subscriptions on the fly as each consumer becomes active or becomes inactive. If there are no subscriptions then messages sent to a topic are lost. Once you create a subscription, any messages sent to the topic (if they pass any filters applied) will be available on the subscription regardless if there are any active consumers using that subscription. Subscriptions exist until you remove them or, if you have the idle removal feature turned on, they surpass the idle deletion time.
You can verify this with a simple console application, or using LinqPad to set up code that does the following:
Create a topic.
Create a subscription on that topic (no filters)
Send a few messages to the topic.
In a different script or console app, create a MessageReceiver for that subscription and pull down the messages.
The messages within a subscription are durable for the life of that subscription, until they are processed (completed, etc.), they are forwarded somewhere else or they expire.
I am not sure where you looked for documentation, following are good to read:
1) http://azure.microsoft.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-topics-subscriptions/
2) http://code.msdn.microsoft.com/windowsazure/Simple-Publish-Subscribe-d406eb03

Can Azure Service Bus offer Message Journaling?

Can Azure Service Bus be set up to journal successfully received messages, like MSMQ can? If so, how?
While Azure Service Bus does not explicitly have a Journal sub-queue, this scenario is easily achievable by using a Topic and 2 Subscriptions. Service Bus support publish-subscribe patterns so you can create a Topic and have the same send APIs/semantics as a Queue and then create 2 subscriptions say called "Destination" and "Journal". By default Subscriptions have a TRUE filter so receive all messages sent to a Topic, and you can receive from these subscriptions just as you would from a Queue.
More details are available here:
http://www.windowsazure.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-topics-subscriptions/

Resources