-
-
Finally submitted my entry to the BizTalk Server contest. Curious?
I created a transactional .NET adapter. This adapter allows you to submit messages to any .NET component that implements a certain interface, in a transactional manner. This means that, for example, if you access SQL Server from within your component, every operation on SQL will be in the same transaction as all message box operations. This guarantees high reliability between the message box and any transactional backend. If the transaction fails, everything will be rollbacked (including all operations on the message box) and the message transmission will be retried.
So, instead of accessing your components using an expression shape inside an orchestration, you finally might think of doing things asynchronously now! By calling .NET component asynchronously using the BizTalk Server 2004 Transactional DOTNET Adapter you can leverage the retries, backup transport, tracking and BAM features as well.
What's in the package?
- MSI installation package
- .chm documentation files
- couple of samples
- full documented source code
To show the adapter framework's inner workings, I programmed directly against the adapter framework. (Not using the SDK adapter base classes.)
Now it's up to you guys for using this: please provide me with comments, feedback. Tell me what's good and what isn't. Tell me what or how to improve... But first of all: enjoy it. It's there, it's free, it's for you!
Have fun with the pet project I've spent couple of months with:
The BizTalk Server 2004 Transactional DOTNET Adapter.
Special thanks to my girlfriend for all the patience she had!
-
-
For those of you who haven't noticed yet: Dare Obasanjo has published a refined version of the work David Orchard did about a year ago. Doing so, Dare explains best practices in designing an extensible xml schema. Writing schemas that are both forward and backward compatible is not easy, believe me. Even an experienced schema author can be tricked by some of the requirements the xml schema spec needs you to comply with.
One of the most import things to be aware of when designing xml schemas is the requirement on the xml content model to be deterministic. Some people like to refer to this as the "Unique Particle Attribution Constraint". For the normative definition of this constraint, I'd like to refer to the W3C. No one could explain this so fuzzy as they can!! MSDN does certainly a better job :-)
Even the very first xml spec itself has recommendations about this in a non normative section. For compatibility reasons with SGML. In addition section 3.2.1 in this specification says: "For compatibility, it is an error if an element in the document can match more than one occurrence of an element type in the content model."
As for the question "why"... even Tim Ewald, recently wondered why exactly xml schema had this requirement in the first place... I can only guess... but it certainly makes writing an xml parser way easier since only one single lookahead symbol is required... (While otherwise some form of backtracking is needed, which could mean an enormous perf hit!)
.NET is a good xml citizen and requires you to comply with this constraint. If you don't, you won't even be able to validate your schema. Good work guys! As close to the standards as possible!
Could someone explain to me then, why it is that "the world's leading product family of XML development tools" - laughing out loud now - doesn't even *support* detection of this constraint!!! .NET, BizTalk Server, Word and InfoPath certainly do a better job! It's not because of Xerces supporting this kind of bad schema's that they have an excuse not to implement at least a check for this critical type of content model requirements! Even worse, I came across this post in their public FAQ. They publicly state that the detection of a non-deterministic model as an error would be wrong! Pfffff... so far for the standards.
-
-
As I suppose not everyone reading my blog is reading the newsgroups on a daily basis, here's a highlight. Today, a question came up regarding the querying of the MSBTS_MessageInstance class.
Let's summarise what is possible with this WMI class:
- Retreiving all message instances that are currently available in the message box.
- Retreiving all message instances that comply with certain conditions and are currently available in the message box.
- Saving any of those messages to the file system.
What is not possible with this class?
- Saving or retreiving a message that is tracked. Tracked messages are not handled in the same way as messages that are still resided in the message box. If you want to save tracked message instances, you need to use the MSBTS_TrackedMessageInstance WMI class. Please keep in mind, when doing this, that this class does *not* support enumeration. You will need to use the MessageInstanceID in order to create an instance of it!
In addition, remember that it is not possible to use the MSBTS_MessageInstance class to make select queries based upon the content of the message context! Why? Message context is something dynamic and is not compiled into the WMI classes. The message context is accessible on the class as an XML string though... Making selects is only possible using the WMI properties on this class. Like: ServiceName, ServiceInstanceStatus, ServiceInstanceID, ServiceClassId, ServiceClass...
If you'd like to see this class in action using real life code - please check out my pet project: the BizTalk Server 2004 Tracking Playground.
Happy coding!