0

I have a Azure Function scenario as follows: 1) If product = 123, then use Service Bus Topic1 2) If product = 456, then use Service Bus Topic2

I think there are 2 options to solve this:

OPTION 1: Have same Azure Function deploy 2 times (2 diff names) and each having different input/output mapping
OPTION 2: Have only 1 Azure Function but in Application Setting specify the input/output mapping. **From my understanding Application Setting is Key Value. Is this correct? if not, how can I specify complex value in this parameter **.

What is the best way to have this?

What I am thinking about is deploy same Azure Functions 2 times with different settings as follows:

  1. Azure Function 1 with Application Settings as "productid" = 123 and "sbTopic" = topic1
  2. Azure Function 2 with Application Settings as "productid" = 456 and "sbTopic" = topic2

I am wondering if there is a better way such that same Azure Function can run for any of my input/output mapping. If so, where and how do I specify my input (productid) and output (sbTopic) mapping?

EDIT 1: this is CosmosDB Trigger. Whenever we get products in Cosmos DB, i want to send to correct SB Topic

EDIT 2: I have something similar as follows:

Cosmos DB Trigger --> Azure Function --> Service Bus Topic for id=123

I am debating if I should have as follows

Cosmos DB Trigger --> Azure Function1 --> Service Bus Topic for id=123
Cosmos DB Trigger --> Azure Function2 --> Service Bus Topic for id=456
Cosmos DB Trigger --> Azure Function3 --> Service Bus Topic for id=789
which means I would have 3 AF duplicated
etc

or

Cosmos DB Trigger --> 1 Azure Function. Specify mappings (product id and sb topic) in App Settings and --> Add logic in AF such that:
if id=123 send message to topic1 ;
if id=456 send message to topic 2 etc.

khar
  • 201
  • 4
  • 12

2 Answers2

0

You should have your Pub/Sub model driven by Topic based on the Subscription Rules. The following screen snippet shows an example of this model:

PubSubModel

In the above Pub/Sub model, the Publisher fire a Topic with the application properties for additional details such as productid, type, etc. The Topic on the Service Bus can have more multiple Subscriptions entities for specific filters (Rules).

The Subscriber (in this example, the ServiceBusTrigger Function) can be triggered on the TopicName and SubscriptionName configured in the app settings.

In other words, the Subscription entity (Rules) can decided which subscriber will consume the event message. Also advantage of this Pub/Sub model is for continuous deployment, where each environment such as dev, stage, QA, pre-production, production has the same model (topicName, subscriptionName, Rules, etc.) and only connection string will specify which azure subscription (environment) is a current one.

Roman Kiss
  • 7,925
  • 1
  • 8
  • 21
  • Thanks Roman. I have something similar as follows: Cosmos DB Trigger --> Azure Function --> Service Bus Topic for id=123 I am debating if I should have as follows Cosmos DB Trigger --> Azure Function --> Service Bus Topic for id=123 Cosmos DB Trigger --> Azure Function --> Service Bus Topic for id=456 Cosmos DB Trigger --> Azure Function --> Service Bus Topic for id=789 etc or Cosmos DB Trigger --> Azure Function --> Add logic in AF such that if id=123 send message to topic1 ; if id=456 send message to topic 2 etc. – khar Jan 30 '18 at 22:28
  • I do recommend having one CosmosDBTriiger Function to publish an event to the ServiceBus Topic with additional message properties info for filtering (rules) on the Subscriptions. In other words, this function will distribute any valid events to the same ServiceBus Topic and based on the Subscription Rules can be consumed it by Subscriber. In the case, where your business requires to isolate subscribers each other, the Subscription can forward an event to another Topic specified in the ForwardTo property of the Subscription entity. – Roman Kiss Jan 31 '18 at 10:52
  • Based what I recommended, the event flows as following: CosmosDBTrigger -> AF-> ServiceBus Topic -> Subscription123 -> ForwardTo:Topic123, Subscription456 -> ForwardTo:Topic456, etc – Roman Kiss Jan 31 '18 at 10:56
0

The option suggested by @RomanKiss makes sense, and that's a "canonic" use of Service Bus topics & subscriptions.

But if you need to do what you are asking for, you can achieve that with a single Azure Function and imperative bindings.

First, do NOT declare your output Service Bus binding in function.json.

Implement your Function like this:

public static void Run([CosmosDBTrigger("...", "...")] Product product, Binder binder)
{
    var topicName = product.Id == "123" ? "topic1" : "topic2";
    var attribute = new ServiceBusAttribute(topicName);

    var collector = binder.Bind<ICollector<string>>(attribute);
    collector.Add("Your message");
}

By the way, if you deploy your function two times, you will have to put them on different lease collections, otherwise they will compete to each other, not do the processing twice. And you'll have to take care of NOT sending the message to Topic 1 when product is 123 and vice versa.

Mikhail Shilkov
  • 34,128
  • 3
  • 68
  • 107
  • In addition for this case, when the AF will route the events to the specific Service Bus Topic, the app settings can hold the mapping configuration in the following format, for example: "Default=TopicDefault | 123=Topic123 | 456=Topic456 | ... " – Roman Kiss Jan 31 '18 at 11:02