Geeks With Blogs

News View Michael Stephenson's profile on BizTalk Blog Doc View Michael Stephenson's profile on LinkedIn
Michael Stephenson keeping your feet on premise while your heads in the cloud

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:

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.


Posted on Sunday, April 27, 2008 4:52 PM BizTalk , BizTalk Wishlist | Back to top

Comments on this post: BizTalk 2006 vNext Wishlist

# re: BizTalk 2006 vNext Wishlist
Requesting Gravatar...
Hey Mike!

Good ideas, and I completely agree with most of them, some thoughts though -

Mapper/Provider - not sure about this one. mainly concerned about performance etc. I think in a port scenario, where things are presumably late-bound anyway, but in orchestrations it is a different story.

Pipeline components - I think the designer can sometimes provide a much richer UI with the support for the various designers, but I can't say I completely disagree. in any case - WCF has set a good model for that, hasn't it?

Generated Schemas/empty orchestrations - isn't the odx generated to declare message/port types similar to the SOAP adapter's generated items (add web reference)?

Passwrods - I know what you are saying, and it does annoy occasionally, but many people would say that some users might need protection from themselves...:-) or as someone has put it - "don't put a gun in the hand of a monkey", I often argue with people who make that point, but to play the devil's advocate - given the option, many would save a binding file with all the passwords in it without giving it a second though. we should make it as difficult as possible.
Left by Yossi Dahan on May 14, 2008 9:40 AM

# re: BizTalk 2006 vNext Wishlist
Requesting Gravatar...
I'd love to have control over persistence. There are many instances where its not needed and could boost performance significantly.
Left by isaac ferreira on Jul 15, 2008 9:21 PM

Your comment:
 (will show your gravatar)

Copyright © Michael Stephenson | Powered by: