In my previous post I introduced the concept of Customer Power Outages and, at a high level, introduced  how Outage Management Systems work.  The key take away from that blog post is that important, event driven data is passing through BizTalk and there is an opportunity use this information to provide better Customer and Employee engagement through Service Bus Notification Hubs.  Think about, conceptually how different is it from BAM Alerts?  The idea behind BAM Alerts is data is moving through BizTalk, Tracking Profiles pick it up and send it to subscribers who are interested in it via email (oversimplified…I know).  The process of collecting this information for Notification Hubs is different but now we can reach an audience that we may never had access to before.

In this post we will take a closer look into how we could actually implement a Power Outage system and include notifications to both customers and employees by using Service Bus Notification Hubs. 

Note: In some areas I have over-simplified the process in order to focus on some of the key technical aspects of Notification Hubs.

In the diagram below I have laid out the series of events that make up the architecture:

  1. Customer determines their power is out and launches the Windows 8 application on their SurfaceRT tablet in order to report their Power Outage.  The mobile client registers itself for Toast Notifications.  In this case the Customer is only interested in events pertaining to its SiteID (Customer ID) so a Tag of 0090123456789 is included as part of the Toast Notification registration. Next, the customer clicks the submit button to notify the power company of their outage. The message is sent to a Customer Outage Service Bus Queue.
  2. BizTalk is using the new SB-Messaging Adapter to connect to this Service Bus Queue and pulls down the Customer message.
  3. BizTalk will perform a transformation and send the message to the Work Order Create Queue.  Once again, the new SB-Messaging Adapter will be used when communicating with the Service Bus.
  4. Once the Work Order message has been sent to the Service Bus Work Order Create Queue, BizTalk will send a message using the Service Bus .Net Preview SDK to the Service Bus Notification Hub.  Included in this message is the tag “Airdrie” which happens to be the City were the customer, who submitted the trouble ticket, lives.  It also happens to be the area that the Power Line Technician (PLT)  is responsible for.  Only he will receive this toast notification because he is the only employee that is registered for this tag. 
  5. The PLT will now receive a Toast Notification indicating that he has a new Work Order that he needs to complete.
  6. When the PLT clicks on the Toast Notification, the PLT App is launched and he can click the Retrieve Next Order button to download the order. 
  7. Once the PLT has had a chance to assess the situation he can provide an Estimated Time of Restore (ETR) and send this information to a Work Order Update Queue that exists in the Service Bus.
  8. BizTalk will pickup this message from the Work Order Update Queue.
  9. The updated Work Order information will now be sent to the Outage Management System using the FILE Adapter.
  10. BizTalk will use the information contained in the Work Order Update message to push a Notification message up to the Service Bus Notification Hub.  As part of this message, a tag for the customer’s Site ID is populated.  In this case it is 0090123456789 which happens to be the same Site ID as the customer who initially logged the Power Outage ticket.
  11. The customer will now receive a Toast Notification indicating their Estimated Time of Restore (ETR).
  12. Steps 7 – 11 will be repeated once the PLT has restored power and a notification can be sent to the customer, when the work order has been closed in the Outage Management System, indicating that their power has been restored and give them a duration of the outage.

image

Conclusion
Hopefully this post has described in more detail how Service Bus Notifications can improve customer and employee engagement.  I promise that the next post in the series will have some code.  I just felt that if I could build a story, it would provide some worthwhile context that truly demonstrates why this Notification Hub technology is important.