Hmm.. Its the season of the whinge for lil ol me. No product likes me using it. I've got into a fight with Enterprise Library now. When we used it with BizTalk, the data block refused to work. It read the BTSNTSVC.exe.config file and seemed to pick up the loggingConfiguration file, but said that it couldnt load the config handler!! [Yes, we strong named it, GACed it, ensured the build version was correct and not 1.0.* and that the publick key name was present in the config file - all to no avail].
We got round that temporarily since we could afford to stick the component behind a web service and with the info in the web.config file, the block worked fine [In the final scheme of things, that component will indeed be a remote service so this approach is fine] . For another DB interacting DLL which we had to call directly from BizTalk, we just avoided the block altogether and wrote our own Data access layer.
Anyway, i happily installed the new release(June 05) of Ent Lib and the hands on labs and decided to check out the Logging block since we are going to use that next (and there is a good article by Andy Morrison on the same, i just need to understand the basics of Ent Lib logging first before leaping headlong into logging with BTS and EntLib together).
You can guess what happened next. Thats right. It refused to work. I got this weird error message saying that the "loggingConfiguration" section could not be found in the exe.config or the machine.config !! The stupid thing is supposed to look for the loggingConfiguration file in the bin folder, not look for a section in the exe.config file or the machine.config file.
I'm getting sick of this. Config management, logging and data access are key to my solution. Anyway, config management can be done by using the SSO (Jon Flanders and Scott Colestock have discussed it in their blogs), so i guess i'll just roll my own blocks. I cant afford to waste my time hunting down bugs in Ent Lib or any lib.
Actually, thats the name we gave one of our colleagues who got into writing custom components as one of the first things he did in BizTalk. It reflects our current emphasis too. The situation is that since we have dozens of suppliers sending flat files of various schemas. In the usual case , the simple solution is to have a single pipeline for each of them since we have to specify a schema in the flat file disassembler component. But of course, with tons of them it aint gonna be very maintainable is it? What I need is "One pipe to rule them all, and in the message box, bind them" (oh dear, that sounds like the tag line of one of the BTS Blogging gurus doesnt it?)
So we started looking around for some way to dynamically set the schema in the flat file disassembler. Found a good post on Gilles blog titled Selecting the flat file disassembling schema dynamically. It started out quite promisingly and even said "The snippet below makes usage of the not so well known class SchemaWithNone. It is so confidential that the assembly containing its implementation is only installed in the GAC. As a result, you must edit the Visual Studio project file manually to add a reference to the assembly."
Unfortunately, at a key point in the code, the detail was missing. The author created a SchemaWithNone object from the return of a custom method called SchemaFromType(). But what the method returns is not obvious at all. Is it a string? We tried writing our own method that returns a string but that didnt even compile. So we had to ditch that attempt (I did send a message to Gilles tho' cos it seems to be a good technique and i'd hate to lose it) .
I turned to the MSDN Newsgroup, posting this question and was offered a suggestion by Paul Brinkley Rogers saying
Stick a custom pipeline component in the Decode stage of your pipeline. In
the Execute method, try this:
public Microsoft.BizTalk.Message.Interop.IBaseMessage
Execute(Microsoft.BizTalk.Component.Interop.IPipelineContext pc,
Microsoft.BizTalk.Message.Interop.IBaseMessage inmsg)
{
// Assuming you've cloned your IBaseMessage param to a new message
"outMsg"
string systemPropertiesNamespace =
"http://schemas.microsoft.com/BizTalk/2003/system-properties";
string messageType = "http://yournamespace.org#YourSchemaRootNodeName";
outMsg.Context.Promote("MessageType", systemPropertiesNamespace,
messageType);
return outMsg;
}
I have to try this out. I think one of my colleagues tried it and said it didnt work with flat files and only with XML files, but i'm going to give it one more shot. In fact, I probably will try out Gilles technique once again too.
Having said all this, perhaps Martijn's Pipeline Component Wizard can help. The latest incarnation of the tool allows you to add a list of schemas to the component, so maybe, just maybe i can return a schema dynamically. (Havent tried it out yet, lets see)
If anyone has some info on these techniques or has dealt with an issue like this successfully, please let me know. I'd be very grateful for any pointers.
PS: I just came across a good article on Gilles blog titled : How do I reuse BizTalk 2004 maps outside of BizTalk ? Hmmm.. I wonder if i can make use of this somewhere else.