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.