Till sofar it has been a hectic week. Loads of new information from Convergence, very busy schedules, a lot of reading to do. Luckily we get inspired at the office by “attending” a number of sessions via live streams. *w00t!*
Hopefully next year, I’m able to attend Convergence myself.
In the meanwhile, I’m working on the BizTalk alternative for the gateway I set up in earlier blog posts. In the last article I implemented the “Web API Controller” part of the gateway by configuring a receive location which takes a REST POST message and passes the JSON message to a folder, waiting to be processed further. To be honest I made a small shortcut, it would have been nicer to have the message transformed to a XML message. As usual time is my biggest enemy.
Right now I’m at a stage in which I have to implement the “dispatcher” part of the gateway.
What Adapter do I need?
When we are connecting from BizTalk to an external system we have to define a send port. On top of that send port we have to specify what adapter we are going to use. An adapter can be seen as an abstraction layer that handles the physical connection to the destination system.
BizTalk is equipped with a number of adapters out of the box. Unfortunatelly an adapter to Dynamics CRM is not a part of the standard offering. There are several vendors offering Dynamics CRM connectors (e.g. Roedl.com), but there is a price tag attached. As I mentioned in the last article, I’ll implement a custom CRM adapter myself that can be used for either CRM online and CRM on-premise.
The BizTalk SDK has some samples included of send and receive adapters. Personally I think the samples are too bloated to be a good example. I like examples to be straight to the point. The adapter I’ll be implemented will be lean and mean.
A good starting point on developing custom BizTalk adapters is:
From what I’ve read, it looks like a WCF LOB Adapter is the way to go.
Once we have build the adapter, it is a matter of hooking up the adapter to the send port, configure it and we are ready to go. However there are multiple ways of doing that.
For starters, we could replace the File adapter in the send port with the new adapter. In the short run, this might be a good solution. In the long run the simplicity might hinder us. By simply attaching the initial receive port to the new send port, we eliminate the possibility of having an Orchestration. In BizTalk land, an Orchestration is a workflow in which you can implement all sorts of logic. Unleashing the true raw power of the 500 Lbs. gorilla.
That’s why I choose to implement an additional receive port, the new receive port will read the file from the location we saved it. Once read the document will be transferred through a passthru pipeline to the new send port on which our new adapter is waiting to send out the data to CRM. The BizTalk setup will eventually look like this.
In the next part, I’ll implement the send adapter, implement BizTalk and publish the source code for the send adapter.
Stay tuned! I got some reading to do .