by stephen-w-thomas | Sep 15, 2004 | Stephen's BizTalk and Integration Blog
Have you wanted to know what exactly BizTalk Server 2004 is doing at a giving instance? How many Orchestrations are about to Dehydrate? How about how many persistence points inside your Orchestration? Answers to these questions are easily available through BizTalk Performance Counters.
Aside on Persistence Points: Persistence Points are key when designing optimized Orchestrations. A Persistence Point is any time the Orchestration saves its current state back to the message box. The less Persistence Points you have, the better your Orchestration will perform. Persistence Points are caused by specific shapes inside your Orchestration like: Send, Parallel Action, Transactional Scopes, and others. Some more information is available in the help guide under “Persistence”
How to view the Performance Counters:
1. Go to the Start Menu and Select Run
2. Type in: perfmon and Enter
3. Performance Window should open up
4. Click on the + inside the window (or Ctrl-I)
5. Under Performance Objects, Select XLANG/s Orchestrations (note your host must be running)
6. Select the Counters from the list you want to watch, then press Add. You can get information on each by clicking on Explain.
7. Run your Orchestrations
My Favorite Performance Counters:
Orchestrations resident in memory
Pending messages
Persistence points
Running orchestrations
If you want to know exactly how many Persistence Points you have inside your Orchestration, just run it and watch the counter!
Take Away: Performance Counters in BizTalk 2004 can give you a clear picture on the current status of your Server and an idea of how well your Orchestrations will perform.
More information can be found on Performance Counters in the help guide. Just search for it.
by stephen-w-thomas | Sep 1, 2004 | Stephen's BizTalk and Integration Blog
Are you missing the feature of Application Pools that was available in BizTalk 2002? Need to limit your running Orchestrations? Well, I hope my BizTalk Design Competition submission will help you out.
I took that concept and created a Message Broker – Process Controller solution that will allow the user to limit the number of running Orchestration instances. In addition, the Orchestration parameters can be changed on the fly without stopping the Process Controller. The Process Controller can also monitor for suspended Orchestration instances and stop processing if a set limit is reached.
Core BizTalk 2004 Features Utilized
- Base Integration Pattern: Message Broker
- Custom Pipeline Component
- Property Promotion
- Content Based Routing
- Publish and Subscribe Messaging
- Direct Message Box Binding Receive Shapes
- Business Rules Engine
- Direct Interaction with External .NET Components Inside an Orchestration
- BizTalk 2004 WMI Interaction
Please see the documentation for more details. I think I have a total of 10 pages…
The download includes a MSI and the Source Code. The Source Code will install automatically through the MSI.
Download: Get the sample here! (880k)
by stephen-w-thomas | Sep 1, 2004 | Downloads
This fully documented solution shows how to use a process controller Orchestration to limit the number of running Orchestrations inside BizTalk Server 2004. This is similar to Application Pools in BizTalk 2002 that are no longer available in 2004. In addition, the rules engine is used to allow for real time updates to the number of running instances. This was an entry in the BizTalk 2004 Design Contest that ended in September 2004.
This sample shows a good use of the Business Rules Engine, Convoys, and Orchestrations.
This should work for both BizTalk 2004 and BizTalk 2006.
Get more information from the original blog post on this topic: http://www.biztalkgurus.com/biztalk_server/biztalk_blogs/b/biztalk/archive/2004/09/01/how-to-limit-the-number-of-running-orchestration-instances-in-biztalk.aspx
by stephen-w-thomas | Aug 27, 2004 | Stephen's BizTalk and Integration Blog
Topics Covered:
– Custom promoted properties inside a pipeline
– Schema Property: “Property schema base”
– Direct binding to the message box
I have spent a lot of time in the past few weeks working with promoted properties through property schemas. I was using the standard approach, to simply set the promoted properties inside the schema. This, in turn, would allow the properties to be promoted inside the pipeline with no additional effort on my part.
This led me into working with custom pipelines that promoted additional properties that are not inside my message. Once custom properties are promoted, I wanted to use these items for routing to an Orchestration.
Example: I want everything processed by pipeline X and pipeline Y to promote a property named myCustomProp that says “I belong to group A”. Then, I want all group A items to be processed by Orchestration 1. I accomplished this by writing a custom pipeline component that promotes predefined text into myCustomProp. Then, I used direct message box binding on the Receive Shape of the Orchestration to pick up message that have this property.
CRITICAL: You will need to change this property inside the Orchestration to something other then “I belong to group A” before you send the message. Otherwise, when you send it and the Orchestration will start again because it will match the subscription again.
The key point here is I want to set up a filter shape based on my new promoted property that I promoted inside my custom pipeline. This property does not exist inside the schema of my received message. I started getting the following error when I tried to build my Orchestration:
“message data property ‘MyPropertySchema.myCustomProp’ does not exist in messagetype ‘msgStart’
Ok, so what does this mean?
BizTalk is helping you out my looking inside your message and telling you ahead of time that your property does not exist. What a great feature, but in this case we do not want this enforced.
How do I fix it?
Simple solution… Although it took me hours to figure out.
There is a property that can be set on each element node inside your property schema. This property is inside the Reference sections named Property Schema Base.
What is this used for?
It is used to specify the origin of the data that will be promoted into that Element in the Property Schema. I did not realize how important this property was.
The two values for this property are:
MessageDataPropertyBase (Default) – This means the data used to populate this field will come from a message
MessageContextPropertyBase – This means the data use to populate this field may or may not exist in a message. i.e. it could be prompted inside a custom pipeline and set to values not inside the message.
Well, it turns out that setting the Property to the correct value is the key to building your Orchestration. Setting this value to MessageContextPropertyBase will allow the Orchestration build since this property will not be expected inside the message.
Take Away: When you are working with Promoted Properties that may or may not be included inside your message make sure you set the Property Schema Base property to MessageContextPropertyBase.
by stephen-w-thomas | Aug 23, 2004 | Downloads
This sample shows how to use a simple Sequential Convoy inside an Orchestration. This can be used inside an Orchestration for sequential message processing.
This sample will work in BizTalk 2004 and BizTalk 2006
Get more information from the original blog post on this topic: http://www.biztalkgurus.com/biztalk_server/biztalk_blogs/b/biztalk/archive/2004/08/23/sequential-convoys-in-biztalk.aspx
by stephen-w-thomas | Aug 22, 2004 | Stephen's BizTalk and Integration Blog
I need to start off with a note about the Parallel Sequential Convoy sample that I am working on. I am still working on it and it will probably be a few weeks before it is ready to be posted. I have a sample working that does Parallel Sequential processing of a single message type. I am now trying to get that to work with multiple message types in a single Orchestration, although I think this breaks one of the rules of convoys. In any case, please check back later for that sample.
In the mean time, here is a sample working with a Sequential Receive Convoy inside an Orchestration. This takes in an initial message to start the Orchestration. This message will tell the Orchestration how many messages to process before it ends. Rather then this approach, I could have used a time out or a set number of messages to tell the process when to end.
This sample includes a Test Harness Win Form to run the process. For set-up instructions, please see the ReatMe.txt. No executable code is included with the samples; you will need to compile the code yourself.
Download: Get the sample code here.
Key Take Home Points:
– This approach could be prone to zombies
– The Receive Port must be the same for the Start and Worker messages
– The Receive Port must be marked for ordered delivery
What’s coming next?
– A parallel sequential convoy sample
– A zombie maker “feature”
Take Away: Running the sample is kind of fun and working with convoys is cool.
by stephen-w-thomas | Aug 22, 2004 | Stephen's BizTalk and Integration Blog
Have you looked at the SDK example working with Envelopes in BizTalk 2004 for Flat Files and tried to get it to work with XML Documents? Well, I did and I found it a little trickier than I expected.
Key Take Home Points:
– De-Batching / Envelope Processing for XML Document must take place on the Receive Port. I have not been able to get it to work on the Send Port, but I am still trying.
– Properties can be promoted from the Header and demoted to the single messages
– No custom pipelines are required for Receive Port Processing as long as the Root Node Name and Namespace are unique throughout your entire deployed solutions.
DOWNLOAD: Get the sample here!
Set-up is easy, just unzip the SampleEnvelopes folder and put it on your C: drive. Then, build and deploy the SampleEnvelopes project. I use early binding so the send and receive ports will be created for you.
To run the sample, drop the start messages named StartFileInbound.xml into c:\SampleEnvelopes\In_Inbound. You will get 3 messages in the Out_Inbound folder for each start message. Also, note that the Orchestration will run 3 times. Plus, I promote and demote Header information to show how it can be passed into the single messages. If all else fails, read the ReadMe.txt file.
Take Away: Once you get the hang of XML Envelopes in BizTalk 2004 they can be a powerful tool for easy document splitting.
by stephen-w-thomas | Aug 22, 2004 | Downloads
Working with envelopes in BizTalk Server is always a little tricky. This sample shows how to use an envelope to de-batch a larger Xml message.
Some Key Take Home Points:
– De-Batching / Envelope Processing for XML Document must take place on the Receive Port. I have not been able to get it to work on the Send Port, but I am still trying.
– Properties can be promoted from the Header and demoted to the single messages
– No custom pipelines are required for Receive Port Processing as long as the Root Node Name and Namespace are unique throughout your entire deployed solutions.
Get more information from the original blog post on this topic: http://www.biztalkgurus.com/biztalk_server/biztalk_blogs/b/biztalk/archive/2004/08/22/envelope-processing-on-send-and-receive-ports.aspx
by stephen-w-thomas | Aug 19, 2004 | Stephen's BizTalk and Integration Blog
I saw a recent post on Scott’s Blog about what’s valid inside an expression shape.
It gave a helpful list of expressions that are not allowed inside the Expression Shape. I was surprised by one of the items in the list, the “if”. I had been using “if” inside an Expression Shape in the Beta. I wondered if this was no longer possible in the RTM release. So, I set up a simple sample project to test this out.
First off, you might ask: “Why would you not use the Decision Shape?”
Well, I used “if” inside the Expression Shape for a few reasons:
1. To make the visual size of the Orchestration smaller
2. To do quick Boolean checks like if a file exists
3. It was easier to drop in a quick line of “if” code rather then mess with the huge Decision Shape. Ok, this point could be debatable…
I have put together a sample testing the use of “if” inside an Expression Shape and a sample showing how “if” can not be used inside a Message Assignment Shape.
DOWNLOAD: Get the sample here!
Set up is easy, just unzip the SampleIFStatements folder and put it on your C: drive. Then, build and deploy the ExpressionIF project. I use early binding so the send and receive ports will be created for you. Then, try to build the MessageAssignmentIF project. Note the difference how the two Orchestrations use “if”. This project should not build and should say illegal use of “if”.
To run the sample, drop the start messages named Start_False.xml and Start_True.xml into c:\ SampleIFStatements\In. You will get your results in the Out directory. The Results node will be changed based on the Boolean value. If all else fails, read the ReadMe.txt file.
Key Take Home Points:
– “if” is allowed inside the Expressions Shape
– “if” is not allowed inside the Message Assignment Shape
Take Away: It is possible to use “if” outside of the Decision Shape inside an Expression Shape. But, it should be used cautiously since it could confuse developers who are looking for the Decision Shape.
by stephen-w-thomas | Aug 19, 2004 | Downloads
This simple sample shows how to use “IF” statements inside on Orchestration.
This sample will work with BizTalk 2004 and BizTalk 2006.
Get more information from the original blog post on this topic: http://www.biztalkgurus.com/biztalk_server/biztalk_blogs/b/biztalk/archive/2004/08/19/working-with-if-statements-in-an-expression-shape.aspx
