BizTalk Server Contest Entry

Finally submitted my entry to the BizTalk Server contest.  Curious?

I created a transactional .NET adapter.  This adapter allows you to submit messages to any .NET component that implements a certain interface, in a transactional manner.  This means that, for example, if you access SQL Server from within your component, every operation on SQL will be in the same transaction as all message box operations.  This guarantees high reliability between the message box and any transactional backend.  If the transaction fails, everything will be rollbacked (including all operations on the message box) and the message transmission will be retried.

So, instead of accessing your components using an expression shape inside an orchestration, you finally might think of doing things asynchronously now!  By calling .NET component asynchronously using the BizTalk Server 2004 Transactional DOTNET Adapter you can leverage the retries, backup transport, tracking and BAM features as well.

What's in the package?

  • MSI installation package
  • .chm documentation files
  • couple of samples
  • full documented source code

To show the adapter framework's inner workings, I programmed directly against the adapter framework.  (Not using the SDK adapter base classes.) 

Now it's up to you guys for using this: please provide me with comments, feedback.  Tell me what's good and what isn't.  Tell me what or how to improve...  But first of all: enjoy it.  It's there, it's free, it's for you!

Have fun with the pet project I've spent couple of months with:

The BizTalk Server 2004 Transactional DOTNET Adapter.

Special thanks to my girlfriend for all the patience she had! 

4 Comments

  • Hi Christof,

    To start with, nice adapter. I am looking into possibly using it with one of our upcoming projects. The project will have a scenario, were we will be sending messages to remote BT Servers via MSMQ\MSMQT and updating a SQL table. The object will be to update the SQL server, but only commit the transaction, if we know MSMQ\MSMQT has taken control of the message. I was also wondering, how difficult it will be to modify your adapter to work with request\response. We have a SQL Adapter that I wrote (Not as well as yours though) that sends messages to SQL and receives a HashTable as a response. The HashTable has a few Identity column values that I need for references. I then add the HashTable to a Message Context and return the message. The thing I really like about your implementation, is that The DotNet Dll needs only implement an inteface to work with your adapter, were as I make a reference in the project to the dll, and call it directly.



    In addition, I was wondering if you know if it is possible to use a receive file adapter in a transactional manner. I want the adapter to copy the file to a temp location, before it is deleted from the original location. I need the functionality to ensure I do not lose a message in the extreme case of a catasrophic failure while the message is being passed to the pipeline, and before it is persisted. At the moment I deal with this in an external windows service. In BTS2002 this is fine, because we have a windows cluster for redundancy, and the service is a cluster resource. In BTS 2004, we do not need the Windows cluster, and we want to modualize (via seperate pipeline components) all of the features we have in the service, such as logging (We would log to BAM) and Uncompressing files. But, this all hinges on the ability to garrantee that if we have a failure at any point, we won't lose the original message.



    Look forward to hearing your thoughts



    Todd

    toddsu@clalit.org.il

  • Hi Todd,



    please read my last post for any comments on the .NET adapter. I hope you liked it. Please keep those comments coming!



    Making the FILE adapter "transactional" would not be feasible I guess... You'll need to implement your own one to do this decently. I you plan to, let me know if you need any help. What exactly do you plan to do in your pipelines that would possibly cause the message to become corrupt? If your first pipeline component would log the message, you're fairly save aren't you?



    Best regards!

    Christof

  • Christof,

    I like the idea of using an asyncronous queue to receive the response, and will look into implementing this. The reason we receive a response, is that we have a logging system, and we update the record in the log with the identity field of the SQL record that was inserted in the process. This just makes correlation for the project managers a lot easier, and reduces the amount of questions I have to answer.



    In addition, I have finished the file adapter. Basically it takes the file and writes it to a temp folder before actually deleting the file and submitting it to the BTS. We felt we needed this, not because the message might become corrupt, but as a saftey measure in case of a power outage while the message is being streamed into the pipeline. I know the odds of this happening are slim, but seeing as how we are dealing with medical records, better safe than sorry. If you would like, I will send you my adapter code.



    Todd

  • Hi Todd,



    let me know how you proceed. I think many people would be interested in the "enhanced file adapter" :-) So, if you file like sharing this I can only encourage you to do so. I will be happy to do some promotion on my blog :-)



    Best regards!

    Christof

Comments have been disabled for this content.