I’ve been following The Happiness Project for a while now (since John Lam’s mention) and I’ve really enjoyed it, especially this post on sparking your creativity.I find myself doing a mixture of many of these things when I need to let the creative juices flow, except for #8, of course. 😉
I’ll start trying to post a weekly sum up of BizTalk, .NET topics I’ve come across during the week. We’ll see how goes as I’m not the most constant blogger …
However I worked with mainly three things this week.
I’ve tested some ideas relating to an error handling pattern we like to implement in a one of our major integration projects. We’ve looked at how the new BizTalk 2006 Failed Message Routing fits in with our project. The idea is to have and Orchestration listening to the Error Message, log these and then put the failing message parts to file. We’ll then have a system that picks up the failed messages, launches them in an editor and makes it possible to resend the message after it’s been edited.
Problem arises when we get to handling exceptions in Orchestrations. Orchestrations doesn’t have the possible to use Failed Message Routing as ports does (I guess that ok, we might want handle different errors in different ways and so on.). However that means that we have to catch an error and create our own Error Message to submit to the message data box for further routing to the Orchestration handling errors (the one that logs and puts the message to file.) So far so good as long as we don’t get an General Exception! Usually when getting an General Exception, and we don’t catch it, the message gets suspended and we get a some error details giving us an idea of what went wrong. However as soon as one catches a General Exception we loose all information about the error … We’ve still haven’t found a good way of handling these errors. We just can’t afford loosing that error information!
General Exceptions are still a mystery to me. I guess that are there so BizTalk has a chance in catching exception that aren’t raised from .NET based code. But what kind of errors within an orchestration raises these kind of exceptions? I know a failure in a mapping does, what else? I’d really like this scenario to better documented. The error handling patter is based on a chapter in the Pro BizTalk 2006 book (which is a excellent book in my opinion – buy it!) but the General Exception and how to deal with it isn’t discussed there either. Any ideas, book, articles are highly appreciated!
One important thing to think of in a BizTalk solution is to not let anything either in or out that doesn’t validate (ok, there are exception to this, but generally speaking)! BizTalk has great built in support for this in the XML Validator Pipeline Component (you might also want to have a look at this code). However when working with this it’s important to understand what one is validating against and it suddenly even more important to understand every details in the schemas (external system owners usually like some technical explanation when your telling them that their messages don’t validate in your pipeline ;)). Things we run into this week is the elementFormDefault attribute. The following reading help me understanding what the attribute does:
Another thing we ran into was white space handling and the xml:space attribute. Apparently if one likes to have a node with a space in it BizTalk removes this if the element doesn’t have the xml:space attribute. so will come out as – sound familiar?
But if the schema doesn’t declare that the node will have a xml:space attribute the validation will fail! To get this working one has to get the schema declaring the the xml:space attribute and then reference it like this example. The schema from w3c (if you don’t write your own like in the article) is located here.
I’ll make this short even if it should be the longest part in this post. Basically we’re trying to archive the following:
Our solution send loads of different messages types between five different BizTalk servers. The client likes to be able to have full text search within these messages and to also be able to see all the messages in each interchange within a server.
So say for example that we receive and Order message in a flat file format. This is transformed in to a Xml message that is then routed down to two other different BizTalk servers. It should then be possible for the client to start an application, click on the Order message type, enter for example the order number (an element i in the message) and see the the full content of the different files within the interchange (in this example that would be the flat file and the Xml file) where that Order number is found.
Basically it’s does what the HAT does (with full text search and a custom GUI). In the first phase of the project we’ll have it work per server, but in the final solution this should perform over all servers … I’ll come back to this in a later post. In the mean time listen to this episode of Hanselminutes on end-to-end tracking. This will be a challenge in every service orientated architecture …
I’ve sold my iPod Nano and ordered the Creative Vision Zen:M. Now I’ll catch up on all those dnrTV Webcasts! I’ll also make sure to watch everyone of the BizTalk 2006 Webcasts during my commute to work.
Let me know if you found some of this information useful and I’ll try harder to post some like this every Friday.
This week Microsoft updated the BizTalk Server 2006 documentation. You can download it here:
http://www.microsoft.com/downloads/details.aspx?familyid=3294ddaf-9f67-409f-a92d-2f6070dc0d1a&displaylang=en
I’ll start trying to post a weekly sum up of BizTalk, .NET topics I’ve come across during the week. We’ll see how goes as I’m not the most constant blogger …
However I worked with mainly three things this week.
Error handling and General Exception
I’ve tested some ideas relating to an error handling pattern we like […]
So it looks like my Microsoft replacement has finally been hired. My buddy Chris Romp has taken over the role of BizTalk Technology Specialist for Microsoft SoCal. He’ll do a great job, but if any of my former customers are reading this, please give the poor guy a little time to get up […]
Problem:
In one of our BizTalk solution we receive purchase orders in the form of flat-file via FTP adapter from different buyers. Different Receive Locations with specific service windows are configured for each buyers. We got the solution in place, which will process the received purchase order, does some business process, routing etc, etc via BizTalk.
Recently we ended up in a strange situation, where we didn’t receive any purchase order from one particular buyer for atleast a week and nobody noticed it until the buyer called us and asked for the status via telephone. The purchase orders were lost somewhere on the wire and didn’t hit our BizTalk servers. If it had reached our BizTalk servers and once BizTalk started to process the message, then we have the full fault tolerance in place. Things like exceptions written to eventviewer, picked up by MOM and services people get notified etc, etc. In this case since we didn’t receive any message at all, there is nothing to process and nothing to notify.
What’s the solution?
If we look at what BizTalk offers out of the box, one solution I can think of is, we can configure BAM to look for activities that’s happening inside our business process, set up some BAM alerts to get notified and also ask service people to look at the BAM portal every day to monitor all the message flows.
Second option will be to implement some kind of reliable messaging between us and trading partners. Either using BTF framework or some other specification like ebXml, but this requires quite a bit of work.
In our case, we didn’t take the BAM or reliable messaging route , instead written a .NET application (quick and easy fix) scheduled via scheduled task to run every hour between 9AM to 6PM (Business hours). The .NET applications monitors the archive folder for new files and writes Error messages into the event viewer based on some business logic. The errors in the eventviewer are picked up by MOM and goes via our Service Desk channel.
So, What functionality I wish in BizTalk Server ?
In BizTalk server, if you look at the concept of Service Window, they are managed by Messaging Engine directly, I.e adapters don’t need to worry about service windows. Adapters don’t care about when to submit (Receive) messages into BizTalk and when to transmit (Send) message out of BizTalk, Messaging Engine will take care of the service window functionality. I wish there is a check box similar to the one I added to the Receive Location, Schedule Tab as shown in the below figure (Readers, be aware the functionality inside the red box is not present in BizTalk server 2006, I just manipulated the image, so don’t just go and check your Receive Locations)
If in case you can’t read it, it says “Raise Fault Message if no messages received during Service Window period“. So, whenever there is a situation where you didn’t receive any messages from your trading partner during the service window period, and “Raise Fault Message” setting is enabled for the receive location. Then the messaging engine can produce fault message, something similar to “Routing Failure” messages we receive at the moment in BizTalk 2006, with some extra promoted property. This will help us define new business process seamlessly for the condition described in “Problem” section above.
If you think its a valid request, please drop a comment for this post with your name.
Nandri!
Saravana