Or, as it was called: “Top 10 Things to Know When Integrating with Line of Business Systems”.
The quick Saravana Kumar beat me to posting about this, but that does not mean I cannot reiterate it. The presentation was hosted by the Swedish BizTalk User Group (Johan and Mikael of course) and was presented by Richard Seroter, BizTalk MVP and nice guy, and Kent Weare, also a BizTalk MVP and nice guy (I see a pattern here).
Notice that a white shirt was the thing to wear on stage. They looked a bit like a cult…
So, what were the top 10 things to know? Here they are:
#1: Strategically use adapters, proxies and direct APIs.
This means that you should be aware of the fact that there might often be more than one way to integrate with a system. Depending on your needs (QoD or EAI) you should opt for different strategies.
#2: Be creative when client library can’t be used for security.
The most obvious of this is letting credential information tag along though a Azure Service Bus service, but there are other examples. Creative does not have to mean “not secure at all and totally dangerous”, but you have to present it well to the security guys for it to seem creative and not barking mad.
#3: Sometimes you need a data/protocol proxy in front of BizTalk
I guess we have all been there. You are presented with a service, or a schema or file that simply will not work with BizTalk. The most famous of these are web services that use the xs:any to be “dynamic” and “agile”.
In these cases you might need to build something to serve BizTalk in a way that the data is digestible. A personal example is a service that read data from a com-port and sent incoming messages to an MSMQ-queue (thanks to Kjell Almgren).
#4: Reliability may not be pretty
A picture of an old Volvo was the symbolism of choice. But again it ties into #3 and highlights the solution using MSMQ, but hey it worked and still does. You might not create a new database just to act as a buffer as a first step during development but as you encounter problems with lost messages and overflow, you implement it. Much to the annoyance of the people that takes over after you. But: It does not have to be pretty.
After this we had a bit of a break, during which Saravana had the opportunity to demo his new creation BizTalk 360. It’s well worth a look. Personally I wonder what the next version will be called, 360 2.0, or BizTalk 720. I also had the pleasure of discussing the presentation with both Richard and Saravana.
So, after some salad, soft drinks and socializing Kent started round 2.
#5: Consider both Polling and Notification techniques
This, for me, is something to remember. Often I don’t even consider notification as it tends to be a bit hard to do. However Kent reminded us how easy it is to use notification from an SQL server using the WCF-SQL adapter. It might still be hard using other adapters though.
#6: Understand when to use Batch and Real time interfaces
Once again this is a very good thing to remember when you try to architect a solution. “Does this have to run in a batch?” “Can I use real time or will it bog down the AS/400 machine?”.
#7: Use asynchronous communication when possible
Another great tip and something to live by in order to shorten response times and latency in every solution. If the message does not have to be validated and possibly sent back for revision, then use asynchronous communication. Please.
#8: Data access strategies
This really needs to be illustrated by the great picture from the lecture.
It shows how data access might not be as straight forward as one might think.
Kent works in the utility business and integrates with one of the most up-tight systems around the world (not his words).
Now this system has fairly good ways for integration but … it has it’s issues, as presented by himself in a really useful webcast from 2009.
He talked about an example in which they had to exchange data in triplicate every time something was updated. One file containing the data, one for archiving and another to signal the system that the first file had been posted. A smart solution to a big problem, but not the straightest line of the three on the picture.
#9: Securing LOB interfaces
If I am honest I cannot remember the particulars about this point.
#10: Don’t integrate anything that feels unnatural
Illustrated by fries and mayonnaise (which is great by the way). Kent’s main point here, I would say, is that if it something in your gut is telling you that these systems should not integrate, then you are probably right. They might just be too different or handle completely different data.
Lastly I would like to a nice guy as well and point out that the coming book is a must read for those of us integrating LOB systems. I will surely order it since I, as a swebug attendee, get a discount.
Now I am off to view some movies and also give Richard a tip.