Friday, March 1, 2013
Sunday, August 19, 2012
Our book is available for pre-order at PackT.
Release Date : November 2012
- First BizTalk book that is completely oriented for System Administrators
- Covers combined experiences of many renowned BizTalk Administrators from all around the world
- Written in clear concise step-by-step style and includes real world issues and solutions
Sunday, August 5, 2012
Monday, June 11, 2012
This is a follow up to my last BizTalk Anti-Pattern post
This is primarily for the Technical Recruiter.
My last contract was mutually terminated. I had worked for this client architecting their BizTalk 2006 R2 / ESB 1.0 EAI implementation. I was contracted to architect their migration to BizTalk 2010.
There was a disconnect between what the client expected and what a BizTalk Architect role does.
After I completed their 2006 R2 / ESB implementation, the client had cloned the ESB 1.0 and deployed it on web servers. Not only did they duplicate the Itinerary functionality, but they customized it. They created their own custom core components and pipeline components.
I won’t go into the details (saving these for the Anti-Pattern List). One of my tasks was to help the developers migrate their custom ESB Web Application to ESB 2.1. All their tests were failing. I was expected to help their developers.
It would benefit everyone if you would ask the client for explicit details on what they expect of a role. The client would rely on you more often to find the right person for the job..
A good source that describes the BizTalk Architect Role can be found on the TechNet Wiki.http://social.technet.microsoft.com/wiki/contents/articles/6243.biztalk-roles.aspx#BizTalk_Architect
If you search the TechNet Wiki http://social.technet.microsoft.com/wiki/, you should be able to details on other roles.
Tuesday, June 5, 2012
Just assuming is also a BizTalk Anti-Pattern
About a month ago I accepted a contract as a BizTalk Developer for a major care product service provider. The project was to incorporate United Parcel Services mapping and routing services into existing BizTalk 2009 Applications. This was a major project with a fairly large budget. They were willing to pay a fairly high rate.
Part of the scope of the project was to incorporate the Windows Azure Service Bus.
Unfortunately I did not ask any questions about their current environment. I just assumed….
It wasn’t until I started that I found out they were using BizTalk 2009 Standard.
They were not using Maps, WCF-Lob Adapters, Pipeline Components, or the ESB Toolkit. The only had a few schemas
They did everything in .Net code and WCF Services and called these services from Expression Shapes in Orchestrations
I was told that the were only using BizTalk for Guaranteed Delivery.
I demonstrated how they could easily develop this application in BizTalk without the need to write a lot of code.
They had no interest in changing their use of BizTalk. Nor were they interested in upgrading to Enterprise.