Saturday, August 8, 2009

Customized BAM Service

I am working on building a service that would be used by many components across the system to capture data for BAM monitoring. I am looking for ways expose the service in a generic way so I don't have to mention too much information about the activity that the service user would be populating (not even the name of the activity). I used this tool to generate typed objects, developed by Darren Jefford.

Any Thoughts

Sree

Wednesday, September 3, 2008

Got Certified

After countless days of planning and not doing it, I finally did it. I got me a MCTS in BizTalk 2006. But after doing it I wonder if its worth it. I am sure many who did take the test are thinking the same. I have two and a half years of experience with BizTalk and did not have to break a sweat during the test.

This is what I did as a preparation for the test.
  • I read the book Wrox Professional BizTalk Server 2006 cover to cover. I read it once out for my job and once for prep with the test.
  • I followed Saravana Kumar's diary as a last min prep.
  • I read BizTalk community blogs on a regular basis.
Good luck with the test.

Later

Saturday, December 22, 2007

Building pure subscription based orchestrations

I was new to BizTalk until about an year and half ago. I started out building orchestrations like I used to write object oriented code. It took me a couple of months to really get my head around the power of message oriented programming and how much development and maintenance flexibility it provides.

I follow most of Marty's suggestions in my applications (except for the one about multipart messages.... not really a fan of them). One thing I like the most is direct-bound orchestrations.

I had great experiences with developing orchestrations that pick messages from message box and drop them back on it. This would provide an application where orchestrations are completely independent of each other. Just using filter expressions on receive shape and direct bound receive and send ports in an orchestration would accomplish this.

Advantages
  • No ports to configure after deploying the orchestrations.
  • Small processing (orchestrations) that can be modified and deployed independently.
  • Ease of testing.
  • Highly extensible in adding additional processes with least difficulty.
  • Flexibility of processing a single message parallelly in different ways.
  • No performance sacrifice.

Disadvantages
  • Filter expression on an orchestration receive can only be changed at design-time
  • Possible infinite looping if message flow and filter expressions are not designed properly
Implementation
Lets look at this type of development a little closer.

OrchestrationA and OrchestrationB are subscribed to messageT with a promoted property action = A and action = B respectively. According to the business process, messageT needs to be processed by orchestrationA and then orchestrationB. The action property will be set to B in orchestrationA. If this is set using a literal string, the orchestrations are still tightly bound. Meaning when the filter expression on orchestrationB changes, orchestrationA needs to changed too.

Extend Publish/Subscribe
The last couple of assignments I handled, I used BRE and database to assign the action value. Using BRE I had rules based on content of the message to assign action value. A lesser dynamic way would be to use Key/Value pair from database, and use the key in orchestration. Check out the new ESB guidance source code which provides an iternary concept on the message which is far more extensible.

Testing
Since each orchestration is a unit of process, this can be tested independently and extensively. I have used BizUnit and its Extensions to test my BizTalk processes. Following are some things to keep in mind.
  • Since each process is subscription based you should stop all orchestrations except the one you want to test to avoid unnecessary processing on the message. Even better, have orchestrations run on different hosts (which is how you would want them anyway) and stop all hosts before running unit tests. As you run the tests have the hosts and orchestrations start/stop as you need them (by using HostConductorStep and OrchestrationConductorStep)
  • Each process can be validated with the values in the resulting output message. This can be achieved by creating send ports with file adapter (or other where you can read the message) and filters equivalent to the output message.
  • You can also automate your tests and have a specific order in which they run