Another one for the BizTalk Wish List

michael stephenson — Sun, 04 May 2008 15:36:31 GMT

I think it would be useful if maps could be applied at Receive Location level. I was working on a demo scenario the other day where I had an orchestration that was exposed to two different receive locations through a port.

The message formats coming in were different as well as the transport. Inbound it was easy I could apply 2 maps to the port and map the different requests to a common schema for the orchestration to work with.

The problem came because it was a synchronous service and when the orchestration returns a common response there is no way to work out which outbound map should be applied as both maps would have the same source document.

If the map could be applied at receive location level then this problem would be resolved as each location in this scenario would be working with its specific message format.

I would imagine this isnt that uncommon a scenario.

UPDATE:

Following feedback from Jason ive added this update to try and ensure I have explained this correctly as its a little awkward to describe.

As mentioned the process is synchronous request response. The following diagram illustrates what happens on the inbound part of this process:

As you can see the both locations pass in different message formats which are processed and then mapped in the port (using a different map for each) to a common schema. This common message is what hits the message box and is then processed by an orchestration. The two different maps are applied because they each accept a different message input type and the map which should be used can easily be resolved.

The next diagram shows what happens on the response side of this:

As you can see when the common schema for the response message is returned to the message box from the orchestration and picked up by the port for processing the 2 maps which are used to map the response back to the sender specific response message will both have the same input schema. This wont work as the map to use can not be resolved correctly.

As Jason mentioned you can work around this and infact what I did in my sample scenario was to implement a pipeline component which could execute BizTalk maps (ill discuss this in another article) this ment the mapping was in the pipeline rather than the port so the problem did not occur.

The point of this article is that the scenario here is potentially fairly common and while you can work around this problem the solution is a bit of a pain in the butt to implement so it would be nice if in future versions it was easier.

BizTalk 2006 vNext Wishlist

michael stephenson — Sun, 27 Apr 2008 15:52:52 GMT

In issue 3 of BizTalk HotRod magazine I was asked to provide a profile about myself, and also 5 things about BizTalk that I would like to see improved in the future. Ive decided to have this post where I will keep a list of similar things, things that make life more difficult and also ideas for features etc. Ill keep adding things to this and hopefully some of it might get spotted by the people who might be able to adpot the ideas for future versions.

Record the user who terminates an instance

If one of your administrators terminates an instance it would be nice if the user identity of that person was recorded. In HAT it displays the fact that it was terminated by a user. This would be much more useful for auditing purposes if it showed which user.

Tracking execution across the BizTalk Group with HAT

Unless ive completely missed this, HAT does not show which server instances execute on within a group. It would be really useful to see for message flow which servers the ports or orchestration shapes run on. You can get scenarios where say a retry would succeed or a shape only faily intermittently and this ability would help with troubleshooting as you could confirm if it is a potential machine related issue.

Expose Maps as providers

Generally you hear mixed opinions about BizTalk mapping (some like it and some dont). Ive worked on projects before where a third party mapping tool was used and this was used. What would be a nice feature would be if maps were implemented in BizTalk using a provider style pattern. This would allow you to develop custom mapping components which could implement the same interface and then be loaded into BizTalk and used as if they were a normal BizTalk map.

At present when you use a third party or custom component you usually end up having to implement a custom pipeline component to call the mapping component. If a pattern as im suggesting was available it would allow these external map providers to implement their mapping capabilities in a way that would keep your BizTalk map implementations consistent

Do we really need the pipeline designer?

As we have per instance pipeline features I think the value of the pipeline designer is now limited. An interesting discussion is should we just get rid of the pipeline artifact and its designer. The alternative would be that the bindings would contain the list of pipeline components which would be used for a pipeline. This would mean you could at runtime add a new pipeline component without having to redeploy your pipeline.

I thought about this as an idea when using the Pipeline Component Test Library which can create a pipeline in code on the fly and then execute it. This is essentially what im saying here, you would specify the make up of the pipeline on a per instance basis in the port configuration which then create a pipeline at runtime as you specify and execute it.

Be interested in anyones thoughts on this - maybe ill try and knock up a sample pipeline component which could demonstrate the concept of this by executing a pipeline within a pipeline :-)

Nested artifacts in BizTalk projects

If you have a BizTalk project and add a folder in it then add a BizTalk artifact to the folder. The artifact does not include the folder name in its namespace (the way classes would in a C# project). I think it would be very useful if it did.

Solicit Response and Errors

I think the development pattern for consuming a solicit response port and being able to handle errors in an orchestration is overly complicated. In most cases you want to do the following scenarios:

Call a service, if it gets an error log it (with some custom details) and then return a an appropriate error out of the orchestration
Call a service, if you get an error log it (with custom details) and then stop to allow manual resumption by an administrator where the service call will be replayed
And a few others

The basic problems are as follows:

If you need to resume the call because the errored response is associated with the orchestration it often just suspends straightaway without actually calling the service again (see the following thread for more info: http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx?dg=microsoft.public.biztalk.orchestration&tid=e66f9f24-a412-4ac1-ac7f-fefd7bfe08a2&cat=&lang=&cr=&sloc=&p=1)
You end up with scope shapes and decision shapes making the logic look much more complicated than it should so you can get it to compile without having all sorts of compilation error messages such as "cant send before you receive" etc

To be honest I think you just end up with an orchestration which looks a bit of a hack for a process flow which should be fairly simple

Adapter generated schemas create an orchestration

When you use the adapter metadata generation wizards to produce a schema to call your service (WCF, SQL, SOAP, etc) they always produce an emply orchestration file (which im guessing someone who has never done a BizTalk project thought would be very cool). This really annoys me because any real project is going to probably have orchestrations in a different assembly anyway. If it atleast contained a half implemented orchestration it might be useful but everyone I know just deletes them, so it would be useful if they just werent produced in the first place.

Passwords in BizTalk Admin Console/Exported Bindings

It would be really useful if you were in the BizTalk Administrator Group and you were viewing a ports configuration if you could have an option to see password type values in clear text. As you are the administrator you will have entered these credentials anyway but it allows you to confirm you have entered it correctly.

The same also applies to an administrator wanting to export the bindings, by default it should be as is, but I should have an option (if im in the BizTalk admin group) to be able to have the password type values in clear text. This saves me ages in having to go and manually change the file which I might get wrong.

These are the off the top of my head list of things for now. As things come up ill add more later.

BizTalk Wishlist

Another one for the BizTalk Wish List

BizTalk 2006 vNext Wishlist