In this post I would like to start a series how we use Service Broker in our enterprise system. Today I would like to speak about target scheme that we were planning to archive several years ago, later I would dwell on how we have developed it. I will not speak about how Service Broker works, what objects it is using, as all this information can be found in MSDN.
It was planned to use Service Broker to minimize time that was taken on server side to save document. Before SB implementation during save process we made modifications to some other tables, transfer the modified records to other databases, etc. And during all this operations users had to wait till system finished all required activities. This caused documents to be saved slowly and users to be unhappy.
So, the basic target scheme can be presented somehow like this:
Few words about the scheme:
- Changes in the document trigger the addition of the message to SB queue. All needed information for message processing is packed in XML.
- 90% of messages are processed on the Web Service, which is polling message queues and then performs special activities depending on queue.
- The results are logged in separate table, so at any time we can look at results of each message processing. We also have created a form in our application giving users ability to put messages that failed with an error into the queue repeatedly. The form looks like the following and gives us the possibility to manage queues through user interface, without going to database level:
In the next post I will concentrate on advantages and disadvantages of SB, how we deal with them on the database structure level, also I will start to post some code examples.