transaction object in a custom SSIS component Execute method

I googled, I binged I look high and low.

I am looking for an example of how to use the transaction variable of type object that gets passed into the Execute method of a custom task.

I notice that when I do have a transaction object it is of type System.__ComObject.

What I need to specifically do is take the transaction pass the object to a webservice. The webservice somehow enroll in this transaction when opening the connection, run sql. The kicker is if the package fails further down the line have the sql in the webservice rollback. Now DTC is enabled and right now if the custom task fails the package does roll back but if one custom task succeeds and another fail the custom task work is still committed.

Now if this cannot be used outside of the Execute method, I guess I can bring the webservice code into the Execute metho开发者_开发知识库d

To give some history I had to create my custom webservice task because the built in one does not support authentication.

CredentialCache with IIS vs personal development server

The built-in SSIS connection managers support this transaction object in their 'AquireConnections' calls (See http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.dts.pipeline.pipelinecomponent.acquireconnections.aspx for more details).

However it's almost certainly just a pointer to an unmanaged transaction object of some kind, and SSIS appears to offer no managed wrappers for it (ie via DtsConvert).

But I'd take one more step back and ask yourself what you think you're going to do when you get it. Enrolling webservices in transactions is non-trivial. In theory, webservices that support ws-transactions can be enrolled (and WCF provides support for this: http://msdn.microsoft.com/en-us/library/ms729784.aspx, but does the webservice you are calling?), but in practice I think I'd always try and avoid this, and instead enrol some other local, transactional resource than can get your message through in a reliable manner. Like a 'outbox' table in a DB. Or MSMQ.

It'll be a more reliable solution, and in your case much easier to enrol in the transaction.