November 2007 - Posts
Well it is little known to me anyway ....
In fact I have been working with this designer in Visual Studio for the past 5 years and only discovered this feature by pure accident today. 
When working with complex orchestrations, and by complex I mean when you start to have more than a single receive and send shape, things on the designer can start to get messy when you have lines criss-crossing everywhere.
Well, no more ...
I noticed something today for the first time when looking at the Port Surface, and little button with "<<" on it.
Clicking this hides the port surface away and in turn hides away the lines connecting your send & receive shapes to the ports. Here's the same orchestration as above but this time with the Port Surface hidden.
Nice and clean and neat looking ...
Fantastic!
Now I can expand and collapse my scope and group shapes to my heart's content whilst building orchestrations; without these long lines going everywhere. When you need to access the logical ports, expand the port surface (ignore the messy lines everywhere) do your stuff and collapse it again.
It's often the smallest little thing that can make the biggest difference ....
PS. How long has this feature actually been there?
So I followed all the best practices for returning Fault messages from my Orchestration Request-Response port as found documented here ...
I then published my orchestration as a WSE service.
Then I built this funky little test driver console application that submits SoapEvenlopes to the service and ultimately to BizTalk ... all good until a fault is returned.
All you get is "Server is unavailable, Please try again later". Great!
No SoapException detail. No SoapFault. Nudda.
So where did all my hard work in creating custom Fault messages go? Seemed to have vanished into the ether.
Finally I stumbled upon a blog post by Michael Stephenson, here, that has a great comparison between how the various adapters handle this very thing.
Turns out either the WSE adapter is just dodgy or we're missing the plot somewhere along the way ...
Why do the simple Http & SOAP adapters work great and put the detail where it is meant to be, but the "more sophisticated" WSE adapter requires some nasty string manipulation to retrieve the detail embedded deeply inside a string?
Seems they've fixed this in the WcfHttp adapter. So now the question is ...
How difficult / easy is it to :
a) Upgrade my 2006 server in place to R2?
b) To change my service to a wcf service?
c) To consume this new wcf service? Will the consumers of this service have to update their code if i change this to a wcf service?
Guess I get to play a bit ... 
.
Watch this space; I'll post an update answering each of the questions above.
So with all the hype about Visual Studio 2008 that has RTM'D I rushed on over to my favorite browser and headed off to the subscriber download site; only to be greeted with the following ...
Let's hope the product is better than the download site! 
In the first post of this series (get it here if you haven't already) we started exploring what this product, that is often misunderstood, called BizTalk is all about, but before we dive to deeply into the product and start exploring all it's bits and pieces let's go right back to the beginning ...
"Let's start at the very beginning, it's a very good place to start ... " 
To really understand BizTalk as a newbie, and sometimes as a seasoned pro it helps to look at it from a simplistic point of view.
So ...
How would you explain BizTalk to your Grandma?
Why your grandma? Well it need not be her ... just pick somebody you know that seems to suffer grasping simple technical concepts, like how to operate a mouse without causing whiplash. If you can explain a complex technical product to somebody like that in such a way that they understand the purpose of the product, then anybody, even regular developers, sales people and business champions and grasp it.
I stumbled on an article posted on codeproject some time back that sums it up perfectly ...
http://www.codeproject.com/biztalk/BiztalkToGrandm...
Wicked; Even I got that!
So BizTalk is merely (ok over simplification of note ...) a customs facility for the processing of your enterprise messages; whether that is system to system or business to business ... When you want to do messaging with out of the box rules processing, aggregation, tracking, signing and encryption, reliable delivery there is only one place to go (IMHO) and that is to BizTalk Server.
Hope you enjoyed this short post in a contnuing series ...
Next time we will start to delve a little deeper into each of the "core" features of the product.
I hope this series is at least starting to answer the question ...
"What is BizTalk and why should I care"
So what is BizTalk?
Depending on who you ask you can receive a myriad of different answers ... from "It's the greatest thing released by Microsoft since Windows itself" right down to "It's the biggest load of rubbish released by Microsoft since Windows 95".
It's a product that has been around since 2000 odd and like many Microsoft products has come through a number of significant releases, improving in leaps and bounds each time; yet even now with it being on it's 4th release (or 5th if you count 2006 R2 as a full release) there are still so many that do not know what it is and do not know how it can help them.
I've been using the product now extensively for the past 5 years and almost exclusively for the past 3 and all too often I come across people, organizations, Microsoft partners, and solutions implemented with BizTalk that have quite frankly lost the plot (and the stock on it).
All too often BizTalk is blamed when an implementation goes bad .... Could this be a case of "poor workman blaming his tools"?
So this series is my attempt to explain the product in common everyday language to common everyday enterprise application developers, enterprise architects, business owners and anybody else who cares and happens to stumble upon this blog, all in the hope of shedding some light on this often misunderstood product that is all to easily perceived as the blacksheep of the Microsoft stable.
Enough with the waffle ... What is it already?
Before I can really answer this question let's take a step back and see where we're at today and the things that solution architects of today need to consider when designing, developing and implementing solutions ....
"No man is an island"
Consider that most organizations today already have their core LOB (Line of business) systems in place, whether shelf bought or custom developed - when was the last time you did a complete green-fields development of a product from the ground up and did not have to touch another system?
Not only do most core systems already exist but organizations often have a myriad of individual systems doing their own specific little thing; doing them well but doing them in isolation.
I think it is clear to see that no system is an island.
If we look at the companies we build software for; how many of those operate in isolation? Hardly any ... most companies have suppliers of some form and all have customers (else they wouldn't really exist) .
Therefore it is also plain to see that no organization is an island either.
If I look at the majority of work I am doing today it is either tying various systems together or linking various trading partners together, or a combination of both.
This has become the norm, whether I like it or not.
We've all heard the latest buzzword in ICT speak of late ... the dreaded SOA, Service orientated architecture. As organizations move toward a service-oriented world creating effective business processes that span separate systems and organizations SOA has become a very real requirement.
At the recent international SOA and BPM conference Microsoft announced "Oslo" ... no, not the city, but their strategy to hopefully bring them to the forefront of the SOA maturity space.
The Road to the Oslo technologies
Robert Wahbe, Corporate Vice President, Microsoft Server & Tools, outlined how customers can begin preparing for Oslo technologies by further leveraging technologies available now including BizTalk Server 2006 R2, BizTalk Services, .NET Framework 3.0 and Visual Studio 2005. On February 28th, Microsoft will continue the wave of innovation and launch Windows Server 2008, Visual Studio 2008, .NET Framework 3.5 and SQL Server 2008 with which customers can achieve a dynamic, scalable and reliable enterprise platform. These innovations will provide-the foundation for the next generation of SOA and Web-based applications spanning "on premise" software and ‘in the cloud' services, an approach Microsoft calls Software + Services.
taken from Microsoft SOA & Business Process
Enter stage left .... Microsoft BizTalk Server
SOA has not just become the latest buzzword for nothing; neither has ESB (Enterprise Service Bus). No, these (IMHO) have arisen from the business challenge of operating outside of your island.
BizTalk Server 2006 supports this goal and is in fact key to the Oslo strategy.
BizTalk Server allows the connecting systems across a diversity of platforms and technologies, it allows a developer to graphically create and modify process logic. The product also lets information workers monitor running processes, interact with trading partners, and perform other business-oriented tasks.
I think we can all plainly see the value BizTalk will bring to your life when you're building integrated solutions but it can be so much more too. Often when you think BizTalk you think integration and that's it .... that's where the bus stops.
Or does it? No sir ... For now I'll leave you with this post from Robert MacClean ( SA developer extrodonaire ) where he recently talks about BizTalk being a collection of tools OUTSIDE of integration....
What a novel concept; this has eluded even me up until now.
Shows you ... no product, not even BizTalk, is an island.
Until next time where I will start diving into BizTalk in more detail ...
I am currently working on this really cool integration project where I'm automating a number of business processes using BizTalk orchestrations.
The data comes in through a variety of sources and trading partners and ultimately gets pumped in Microsoft Dynamics CRM 3.0 using the adapter built by MS.
One of the gotchas that I ran into was on create / update I was getting an error coming back from CRM saying the following:
"Error Description: Input Xml is having some invalid attributes"
Marvelous! Thanks for that. Any idea which attribute is invalid? Any clues, hints would be really nice!
After digging around a bit I discovered that you can turn on debugging for this adapter by modifying a key in the registry.
“HKEY_CLASSES_ROOT\CLSID\{D38D5DCC-2B30-43b9-9C69-3BBFD0926986}”
Set the "Debug" key to true and also set the "LogPath" key to the path where you want your log files to be created; make sure your BizTalk host instance has write access to this folder, restart your host instance and hey ... presto ... out pops a log file with a message that looks similar to the following:
Attribute <new_company> has invalid datatype. 70056723456 received. Expected boolean.
Great, now I know exactly where to look and what to do. A simple 1 second fix and all my problems are gone. (ok maybe not all, but this specific one)
What I would love to know with tears in my baby blue eyes is why the exception message returned by the adapter did not originally include this detail. Why only if we're running in debug?
That would have saved me a few hours of digging and hunting around.
I guess this extends beyond just the CRM Adapter for BizTalk but on to development in general. In today's day and age is it acceptable to return "descriptive" and "useful" exception messages like this?
All too often I see throw new Exception("An error occurred."); it is a kin to sending a developer a screenshot of a message box when an error occurs and expecting them to know immediately where and why the error occurred just this once and never again ....