SSIS makes it very easily to debug your package, and also debug your custom source code. It is only a pity that you can’t unit test your own script code. I searched on the internet, but I found only how to test your SSIS (DTS) package via unit testing. I dived into this and created a generic approach for unit testing .Net code from a SSIS package.

First I researched what happens with the source code and how this will be executed runtime. The source code is stored in the package (mypackage.dtsx). Each Script Task will lead to a new project and also a new namespace. The namespace looks something like: ‘ST_1234567890abcdef01234567890abcde.csproj’. With this knowledge you can find your source code in the package, but better; also the binary, the .dll, the compiled code. Each time you change your source code, SSIS will compile the code and put the dll as Base64 string in the SSIS package. This looks like:

}]]></ProjectItem><BinaryItem Name="\bin\release\st_1234567890abcdef01234567890abcde.csproj.dll">TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAgAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
ZGUuDQ0KJAAAAAAAAABQRQAATAEDAP5jD0wAAAAAAAAAAOAAAiELAQgAAD4AAAAIAAAAAAAAHlwA…

With this knowledge, we can read the package, access the Base64 string with namespace as search item (lowercase). This Base64 string can be stored as dll on your file system. It is possible to reference this dll in a unit test project. But the problem is that the signature of the dll will change when you change your package. A better approach is to load the dll into memory and use the properties and methods using reflection. Here are some code snippets:

Load package:

XmlDocument package = new XmlDocument();
try
{
                package.Load(pathAndFileToYourDtsPackage);
}
catch (Exception ex)
{
                throw new Exception("your message");
}

Access the Base64 string

string xPathToBinary = @"//BinaryItem[@Name='\bin\release\" + namespaceClass.ToLower() + ".dll']";
XmlNode element = package.SelectSingleNode(xPathToBinary);

Save your dll

using (FileStream fs = File.Create(yourDllFileName))
{
                byte[] buffer = Convert.FromBase64String(element.InnerText);
                fs.Write(buffer, 0, buffer.Length);
}

Now you can use reflection to load your dll, instantiate the class and access methods and properties. Here are some code snippets:

_assembly = Assembly.LoadFile(_dllFileName);

string typeName = namespaceClass + "." + className;
_classType = _assembly.GetType(typeName);

_classInstance = _assembly.CreateInstance(_classType.FullName, false, BindingFlags.CreateInstance, null, yourConstructorParameters, System.Globalization.CultureInfo.InvariantCulture, null);

Now you can use methods like GetMethod, InvokeMember and GetProperty to access your methods and properties.

You can write your unit tests in a separate test project, and use above methodology to unit test your Task Scripts. For now I only see one disadvantage: you work with ‘late binding’, so you don’t have access to your methods and properties straight away. But when everything is in place and ‘green’, then it doesn’t matter anymore (my opinion).

Do you think there are other possibilities? Other approach so you can use early binding? Please let me know!

1. The MLLP adapter (part of the HL7 Accelerator) is a static adapter. You can use it in combination with the ESB Toolkit, but then you still have to define all physical ports. See an earlier blog from me how to solve this.
2. All (I think) hospital systems are working with ACK’s and NACK’s (some institutions ignore these). There are institutions who wants the ACK (or NACK) send be back by the receiving system to the sending system. The HL7 Accelerator (and thus BizTalk) is taking over this responsibility and sends the ACK to the sending system, before the receiving system receives its message (in my opinion: that is why you use a middleware product like BizTalk). In conjunction with the ESB Toolkit this is hard to implement, because the HL7 Accelerator components (Pipeline) are “living their own life” (you have some control, but not to use with the ESB Toolkit. See also some earlier posts of me).
3. I think the most important reason not to use the ESB Toolkit, is that the most systems used in an hospital are not service oriented aware. These systems are specific to a therapy or division, and holds most of the time all information in their storage, and only share information via HL7 because of the patient information or orders/invoices. This sounds like a “no” on my own question and a Hub and Spoke makes then more sense, but it is still possible to point to some services, like the patient administration (new patient, or updated information) or give an order to multiple systems, etc. So you probably have a combination of those two. Does that matter? I don’t think so, because you still have BizTalk Server as your integration tool and the HL7 Accelerator for connecting all systems.
4. Note: I’m still fan of using a canonical data model within BizTalk Server, also within the Healthcare. All systems will map to and from this data model. It will cost you some extra mappings and a small performance penalty, but at the end you can loosely couple all systems.

Please let me know what your experiences are with the ESB Toolkit in conjunction with the HL7 Accelerator.

1. In comparison to other products, Microsoft BizTalk Server has a positive Return Of Investment and one of the lowest (if not the lowest) Total Cost of Ownership (wow, that sounds like sales, but it is true )
2. With BizTalk Server you don’t have to deal with Vendor lock-in. BizTalk Server is not open source, but there is a large community and a lot of vendors who can deliver BizTalk Server expertise. (HL7 knowledge can still be a problem)
3. BizTalk Server is not a black-box. Because of the documentation from Microsoft, bloggers, and other communities; BizTalk Server is very open.
4. Keep old systems up and running. BizTalk Server is very flexible. BizTalk Server 2009 and BizTalk Server 2010 (and older versions) are delivered with the HL7 Accelerator. See my presentation or article (Dutch) for the benefits.
   • One disadvantage: HL7 v2.6 and v3.0 are not supported (yet), but
     • 2.5 is at the moment the de facto standard, so that shouldn’t be a problem and
     • HL7 v3.0 is XML based and BizTalk Server is all about XML, so that also shouldn’t be a problem (just download the schemas from the HL7 organization site)
5. BizTalk Server has more possibilities to work with the messages in a flexible way (like translation, use custom code, enrich data via databases).
6. BizTalk Server also support other transports then only MLLP.
   • When you want to connect to a governance site which support SOAP, then with BizTalk Server a connection is easily established (eg. in the Netherlands: SBV-Z, Nictiz, etc).
7. “Use Microsoft products, unless …” (heard twice, so there must be a truth in there ) There are healthcare institutions who shift up to Microsoft platform and therefore wants to use BizTalk Server (note: this is also the case for other platforms like SAP or Oracle).

This is the list I’m aware of (in respect to the Healthcare). Do you think I’m missing something? Or do you have another opinion? Please let me know.

Next steps take place:

• Receive message from any transport and use a custom pipeline component for promoting some context properties for routing to the right process (adding a routing slip).
• Depending on the promoted property the next Orchestration will be started:
  • ReqRespOrch – Helping Orchestration for Request-Response pattern
    • Promote context property with value of Validating Process
    • Send message back to the MessageBox with initializing a correlation set
    • Wait for a while for a response (listen) with the same correlation token (because I used XmlDocument in the whole process, I had to create a specific response else the Orchestration would trigger itself straight away. This response can hold for example another Xml. Not detailed here).
    • Send the response back
  • ValidateMessage – Orchestration for validating a message. Can be started by ResRespOrch (properties set over there) or by the OneWay port (properties set over there)
    • Use XmlValidator for validating a message. In this demo I hardcoded the schema to validate against.
    • Promote the right context properties. Depending on the kind of Receive Port (OneWay or TwoWay), the BTS.Operation is copied from the incoming message to the outgoing message (Ack in this demo). Also promote the correlation token from the incoming message and update the routing property.
    • Send Message back to MessageBox
• Depending on the context properties (and with that: correlation) the message will be send back to ReqRespOrch or to a send port which has the right subscription on the context properties.

Techniques used in this Demo:

• Promoting custom context properties in a custom pipeline component
• Using correlation for returning the process back to the Orchestration
• Promote context properties within an Orchestration (use initializing correlation set on send port, you don’t have to follow this correlation set)
• Use generic documents (XmlDocument)
• Use filtering for routing messages through your BizTalk environment
• Use XmlValidator for validating messages in an Orchestration, so you have full control on the outcome of that
• Use BizTalk Deployment Framework and BizTalk Software Factory (http://bsf.codeplex.com)

This demo is very basal, but has all ingredients for a generic solution. The only thing not used here is use of configuration in Single Sign-On. I also didn’t put effort in the WebService, so this receives an ‘any’ message. And of course because this is a demo I didn’t use standards and naming conventions.

Note: because the client is using BizTalk Server 2006 (not R2) I had some limitations for myself. This solution will also working in newer versions for BizTalk Server.

You can download the demo here. Feel free to use or copy what ever you need. If you have any questions or remarks then don’t hesitate to contact me. Also when you think the above solution could work in a different way. And yes: you don’t get any warranty

Cheers…