Implementation of “publish-subscribe” based integration where Dynamics CRM acts as publisher is very common. In this article, I will talk about how “Azure Service Bus Topics/Subscriptions” can be used with Dynamics CRM to create a “publish-subscribe” based integration. I will not talk about “Azure Service Bus Topics/Subscriptions” in detail but focus more on usage scenario and integration.

What is “Publish-Subscribe” Integration?

First step is to know what is “publish-subscribe” (commonly known as pub-sub) based integration. It is an integration pattern.

In simple language, in pub-sub integration, the subscribers are interested in certain messages and they keep looking for the messages at certain place called “bus”. When the publisher publishes or creates the message in the “bus”, each subscriber interested in this message gets a copy of it. There could be multiple subscribers for the same message.

 Subscribers could be interested either in a type of message or a message with certain content. When they are interested in message with certain content, content based routing is used to make that message available to the subscriber.

I recommend you read the following links to learn more about publish-subscribe and content based routing –

Publish Subscribe - http://www.eaipatterns.com/PublishSubscribeChannel.html

Content Based Routing - http://www.eaipatterns.com/ContentBasedRouter.html

 Business Scenario for “Publish-Subscribe”

Let me share couple of real scenario examples.

There is a utility company which provides water and waste management service to citizens. It has a CRM system, billing system, messaging system and mapping (GIS) system. When a customer (message) is created in the CRM system (publisher), the billing, messages, GIS systems (Subscribers) need a copy of customer data to perform follow-up tasks and automation. For instance – billing system will create a billing account for the customer, the messaging system will send welcome message with customer account details on preferred communication channel and GIS system will update customer address in the database for mapping purpose. This is an example where subscribers are interested a message type.

 

 

Another example is for content based subscription. There is a Telco company which provided services to a massive geography. It has logically divided the geography into four regions. It has a centralized CRM system but the billing system has been partitioned into four physical instances – one for each region. When the customer (message) is created or updated in the CRM system (published), it has to be updated into respective billing system (subscriber) based on the region (content) of the customer.

 

 

The following are critical components of the publish-subscribe pattern –

  1. Publisher
  2. Message (Which published and Subscribed)
  3. Content Rule (for content based routing)
  4. Bus
  5. Subscriber
  6. Last but not least “Reliability” in terms of secure message handling, guaranteed delivery, retries, error message handling, exception handling etc.

Azure Service Bus Topics/Subscriptions as “Publish-Subscribe” Engine

The Windows Azure Service Bus Topics/Subscriptions provides a light-weight but reliable and scalable platform for “public-subscribe” based integration. It has the entire ingredient for such implementation –

  1. Topic Definition (“Bus”)
  2. Subscription Definition
  3. SqlFilter (content based rule for subscription or routing)
  4. BrokeredMessage (creating and publishing messages)
  5. Reliability

If I map the first scenario from the above with Service Bus Topics/Subscriptions architecture, it looks like the following –

 

 

We need to do the following for integration –

  1. Create service bus namespace on Azure Portal
  2. Create “Topic” under service bus namespace
  3. Create “Subscriptions” under “Topic” based on number of subscribers
  4. Write “Publisher Code” which takes message data (customer in this case) from the publisher, connects with service bus and then publish message to the “Topic”
  5. “Topic” will internally create copies of the message into subscription queues based on subscriptions defined
  6. Write “Subscriber Code” which is responsible for reading message from subscription queue. It connects with service bus, takes messages from subscription queue, and connects with subscriber system to process the message for the target subscription system.

If you want to learn about Azure Topics, please refer the following link - http://msdn.microsoft.com/en-us/library/windowsazure/hh367516.aspx

How to use Topics/Subscriptions with Dynamics CRM?

Finally, let’s see how we make Topics/Subscriptions work with Dynamics CRM in simplest form. Let’s take a scenario where when contact is created or updated in Dynamics CRM – the subscribers (billing, messaging, GIS systems etc.) are interested in it.

  • First step is to create service bus namespace, Topic and Subscriptions.

 

  • Next write “Publisher Code” in plugin and register plugin for “contact” entity for create and update events. The code will connect with service bus and publish “contact” instance to the “Topic”. The code snippet will look like the following –

                        

 string _ConnectionString = "Endpoint=sb://demosb-ns.servicebus.windows.net/;SharedSecretIssuer=owner;SharedSecretValue=u5TOVcfSgWC1lKX8+KiHH/7znVP3p3pX23ddwed342edd="; 
string topicName = "demotopic";
public void Execute(IServiceProvider serviceProvider)
{
try
{
IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));

Entity entity = (Entity)context.InputParameters["Target"];

if (entity.LogicalName.Equals("contact"))
{
TopicClient Client = TopicClient.CreateFromConnectionString(_ConnectionString, topicName);

BrokeredMessage message = new BrokeredMessage(entity);
Client.Send(message);
}
}
catch (Exception)
{
throw;
}
}

 

  • Based on subscription definitions under “Topic”, the topic will create copies of the “BrokeredMessage” and assign to subscription queues.

 

  • Write “Subscriber Code” which will read “BrokeredMessage” from the subscription queue and do the message processing. This code is responsible for reading message from subscription and passing to subscriber system for processing purpose. The code snippet look like following -

 

              string _ConnectionString = "Endpoint=sb://demosb-ns.servicebus.windows.net/;SharedSecretIssuer=owner;SharedSecretValue=u5TOVcfSgWC1lKX8+KiHH/7znVP3p3pX23ddwed342edd="; 
      string topicName = "demotopic";
      string subName = "demosubscriptio";
      SubscriptionClient Client = SubscriptionClient.CreateFromConnectionString (_ConnectionString, topicName, subName);
      Client.Receive();

      // Continuously process messages received from the subscription
      while (true)
      {
        BrokeredMessage message = Client.Receive();
        if (message != null)
        {
          try
           {
              Entity entity = message.GetBody<Entity>();
              //TODO: WRITE CODE TO CONSUME THIS ENTITY INSTANCE
              message.Complete(); 
           }
          catch (Exception)
           {
              message.Abandon();
           }
        }
}

  • The big question is where to host the “Subscriber Code”. You can see that this code snippet runs in loop and looks for any message published. We need a host which can home this code snippet. There are couple of choices for host
    • SSIS Package executed using SQL Job
    • Windows Service
    • Console Application scheduled using Windows Scheduler

Conclusion

You can see it is a simple, elegant but very reliable and powerful way of implementing publish-subscribe pattern with Dynamics CRM. The implementation can have many faces and variant – I leave that to your design and scenario.

Hope you find this article useful.