Back in part 2 we talked about the MB webservice
This is a nasty old SOAP endpoint that exposes 2 methods, this first simply allows the caller to request an image resource by ID, these are passed to Explore by a plugin every time one of 6 custom entity types are modified or created.
The second accepts an XML document and maps the data to CRM entitles, primarily used for registering newsletter subscription requests and setting the relevant flags on the contact entity and for converting ‘Contact Us’ information in to Cases in CRM.
Let’s look at that second part first, why does this even exist? Well for those of you unfortunate enough to have used it, the Organization Service in version 4.0 was not very easy to work with, especially getting a website to talk to it, couple that with some specific business logic around contact creation and multiple external web developers who don’t speak .net and you can quickly see how it gets messy. We also wanted to keep the websites loosely coupled to the CRM system in case we decided to change it.
So to minimise those issues we created our own intermediate service that took a simple XML document and translated that into calls to the Organization Service whist also applying the required business logic.
The existing architecture/process is this:
- A website sends a document and waits for a response (it’s all synchronous);
- The service loads the string data in to an XMLDocument;
- The service saves a copy of the document to the local disk;
- The service processes the document making more synchronous calls to the Organization Service – averages around 5 calls per request, this takes a while – 40 to 60 – seconds is common;
- The service sends an OK or fail to the website;
- The website responds to the user.
It works but we are going to replace it few a few reasons:
- the code is horrible and very brittle;
- it is incredibly hard to unit test;
- the Organization Service is depreciated;
- its SLOW.
What are we going to replace it with?
The reasons for creating this still apply – we still have some specific business logic, we are still outsourcing all of our websites to different developers and we still want to keep it loosely coupled. We also have the additional reason that we don’t want to have all the websites changed, we want the interfaces to remain the same for now – we’ll probably update those when each of the websites next has a significant update.
In the new design the websites will pass the XML document to the same SOAP endpoint which will put the message into an Azure Storage Queue and continue with its current process.
Then an Azure WebJob running on a schedule will process those messages and push the data into CRM using the new Web APIs.
The Server hosting the SOAP Service will be retained and as each website is updated we will have them changed to push the message directly in to the Azure Storage Queue and do away with the SOAP endpoint.