by stephen-w-thomas | Feb 16, 2005 | Stephen's BizTalk and Integration Blog
Yesterday Microsoft released a BizTalk 2004 Adapter for MSMQ v2.0. This works with MSMQ 2.0 and 3.0.
Here are the key features from the download site:
The BizTalk 2004 Adapter for MSMQ provides support for sending and receiving messages using MSMQ 2.0 and 3.0, and takes advantage of the new features in MSMQ 3.0. Major features of the adapter include support for:
• MSMQ 2.0 and 3.0
• Multi-threading option for faster performance
• Guaranteed delivery when using transactional queues
• Reading from remote non-transactional queues
• Dynamic send ports
• Support for messages up to 2 Gigabytes in size
Download this adapter here.
by community-syndication | Feb 15, 2005 | BizTalk Community Blogs via Syndication
Get the last BizTalk Server documentation update here. As always the online help remains available at MSDN as well.
Together with this core documentation, following updated documents are also available for download:
by community-syndication | Feb 13, 2005 | BizTalk Community Blogs via Syndication
There’s four new guys on the team, and about 30 new articles, with a “Whats New” section.
Get it here…
by community-syndication | Feb 11, 2005 | BizTalk Community Blogs via Syndication
Paul Somers (winner of the BTS2004 competition) was so kind to notify me that his BizTalk Admin tool has moved here.
Reading his latest post: the BizTalk Exam certainly tests your BAM skills as well Paul 🙂
It looks like we’ve a lot of good community projects by now and more are coming up. For example: Brian Travis is working on a cool BizTalk Server Message Dashboard; based on my sample project (BizTalk Server Tracking Playground) I made available in June 2004. Hope it will be finished soon as this is cool stuff: his dashboard allows for inspecting tracked messages and context without needing HAT. Even click-through to related messages is supported. More on this as he finishes 🙂
by stephen-w-thomas | Feb 11, 2005 | Stephen's BizTalk and Integration Blog
I guess these came out several days ago. I did not hear about it until now.
Anyways, updated BizTalk 2004 Documentationisavailable here.
by stephen-w-thomas | Feb 10, 2005 | Stephen's BizTalk and Integration Blog
I have talked a lot in the past about Convoys. But, under the covers what really makes Convoy message processing different? What makes a Convoy a Convoy?
To sum it all up into one sentence: Convoys require database level message-to-Orchestration correlation independent of any running Orchestration instances.
Is this confusing? Yes. But trust me, more detailed information is coming soon on this topic. For now, I want to briefly go over the basic internals of how Convoys work in BizTalk Server 2004.
When you deploy an Orchestration:
The presence of a Convoy is detected at the time a BizTalk 2004 Orchestration is enlisted. At this point, an entry is inserted into the ConvoySets table inside the Message Box that lists the properties used in the Convoy Set. This is limited to only three properties because each property is listed in a column inside the table. The subscriptions that can activate this Convoy are marked with the uidConvoySetID for that Convoy Set.
When a message arrives:
Every time a new message arrives into BizTalk it is checked to see if it is part of a Convoy or if it should start a Convoy. If it should start a Convoy, an entry is inserted into the ConvoySetInstances table that routed messages to the correct instance. If it is part of an existing Convoy (i.e. it has the sample Convoy properties of an existing Convoy set), it is routed to the Service Instance listed inside the table. Otherwise, it just follows the normal subscription process.
Convoy Virtual Subscription:
This database level message routing creates a type of virtual subscription on top of the standard subscriptions inside the message box. This is set up internally using a series of tables.
I have put together a simple SQL query to view all Orchestrations that belong to a Convoy and what the Convoy virtual subscription properties are for those instances. I have not tested this code under all Convoy scenarios so please use caution when running the query and it may yield unexpected results. Note that for this viewer to return any data you must have running Orchestration instances that are part of a Convoy.
DOWNLOAD: Sample Convoy Virtual Subscription Viewer
CRITICAL: This application and included SQL will query critical BizTalk SQL Tables. This should not be run on production servers. Review all code prior to execution and use extreme caution when viewing any BizTalk related database tables. Use this code at your own risk.
This sample is also an excellent example of why I am a BizTalk Developer rather then a .net Developer :).
Here are some of my samples that use Convoys that can be used with this viewer.
DOWNLOAD: Concurrent Receive Convoys (post date 11/5/2004)
DOWNLOAD: Sequential Receive Convoys (post date 8/23/2004)
by community-syndication | Feb 10, 2005 | BizTalk Community Blogs via Syndication
We just released the WSE 2.0 adapter for BizTalk Server! In my opinion this is an important milestone: webservices are increasingly fast becoming the number one interoperable transport both inside and between companies. The need for security, trust and policy is crucial to further extend the wealth of scenario’s that webservices enable. I find it an exciting idea to know that Web Services within your business processes now have become just a matter of configuration! Get it here: http://www.microsoft.com/downloads/details.aspx?FamilyId=BA643360-E9DC-4FC5-8D60-8E6C5ECA7861&displaylang=en
by community-syndication | Feb 10, 2005 | BizTalk Community Blogs via Syndication
As Scott Woodgate mentioned the exam for BizTalk 2004 has been release, you can find it here
by stephen-w-thomas | Feb 10, 2005 | Downloads
This tool can be used to see the Convoy properties associated with any running Orchestration processing messages as a Convoy. Note that this queries critical BizTalk tables. Run with care. This tool works with BizTalk 2004 and BizTalk 2006.
Get more information from the original blog post on this topic: https://www.biztalkgurus.com/blogs/biztalk/archive/2005/02/11/Convoy-Subscription-Viewer-for-BizTalk-Server-2004.aspx
by stephen-w-thomas | Feb 3, 2005 | Stephen's BizTalk and Integration Blog
This is a cool feature of BizTalk 2004! It allows you to map many documents into one or map one document into many. In either case, your inputs will not equal your outputs. This type of mapping does require some up front planning and careful consideration.
First off, this type of mapping is only allowed inside the Orchestration. Basically, what the mapper does is creates a kind of multi-part message for either the input, output, or both. The parts of the multi-part message are the different input/output messages. This allows the mapper to take in or produce multiple messages.
I have only been able to create these types of maps by creating new maps using the Transform Shape inside the Orchestration. I have tried to manually create them, but I have not been able to create/replicate the multi message behavior. Also, I have not been able to find the mystery schema that the Orchestration generates when creating these new maps. Surely is has to be someplace…
How to create maps with multiple messages?
1. Create Orchestration Messages inside your Orchestration. Lets say Input1, Input2, Output2, and Output2.
2. Add a Transform Shape to your Orchestration.
3. Select Output1 and Output2 inside the Construct Shape as Constructed Messages.
4. Click on the Transform Shape. It will look like the figure below.
5. Add the needed input message under Source and output messages under Destination. Each messages needs to go on a new line inside the Transform Shape. In this case, Input1 and Input2 are added to Source and Output1 and Output2 are added to Destination.
6. Once completed, make sure the “Launch the BizTalk Mapped” is checked and hit OK.
7. The mapped will open and you will see multi messages on the Source and Destination. These are nothing more then a new schema that includes the schemas from the input and output messages.
Note: Be mindful of namespaces as I *think* they are required on all the multiple messages used by the new map.
The results would look something like this.
8. Map as needed.
You can modify an existing map to use multi messages but it will break any existing links. If you want to modify an existing map, it has to be in the same project in order to modify the map to allow multi messages. This is done by opening up the Transform Shape and adding additional messages to a new line under Source or Destination. Once modified, then it can be moved to another project.
Note: Moving the map might mess up all the namespaces and references so manual editing of the XSLT may be required. So be careful! Moving the maps works best if all the schemas used inside the map are referenced from external schemas project.
Overall: Mapping with multi messages is an extremely powerful feature when used inside the Orchestration. Although, it can be difficult to convert existing maps into maps that use multi messages.
