One of my favourite features of the new esb toolkit is that it is incredibly easy to extend. Already in an internal implementation I have written a custom messaging service, and implemented a custom adapter provider. Extending a messaging service is comprehensively covered here, but the documentation on the adapter provider is pretty inadequate.
Here are a couple of points that may make it easier for anyone else going down this path…
The adapter provider entry that you create in the esb config file must contain the adapterassembly attribute (unless it references an adapter that ships with BizTalk) or it will not work. The type attribute points to the actual adapter implementation, and the adapterassembly attribute points to the property schema assembly – the documentation is incorrect on this point. An example is below.
<adapterProvider name="SFTP" type="MyTestProvider.SftpProvider, MyTestProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=354cb85f9213cd3b" moniker="SFTP" adapterAssembly="MyTestProvider.Schemas, Version=1.0.0.0, Culture=neutral, PublicKeyToken=354cb85f9213cd3b" />
Consider the above example of creating an custom adapter provider for secure FTP (SFTP):
-the adapter name in BizTalk must be SFTP
- the adapter property schema namespace must be SFTP
- the adapter provider name and moniker in the esb config file must be SFTP
<adapterProvider name="SFTP" type="MyTestProvider.SftpProvider, MyTestProvider, Version=1.0.0.0, Culture=neutral, PublicKeyToken=354cb85f9213cd3b" moniker="SFTP" adapterAssembly="MyTestProvider.Schemas, Version=1.0.0.0, Culture=neutral, PublicKeyToken=354cb85f9213cd3b" />
If all these things correctly align, the ESB adapter manager should correctly promote the SFTP-related context properties from your itineraries :-)
This is nice comment
ReplyDeleteGet More Details
I like this Writing...
ReplyDeleteHand Writing