Migrating from using the Biztalk 2006/R2 adapters to the WCF based adapters

The Biztalk Adapter pack beta2 (mentioned in the post below) contains three adapters - one for Siebel, one for mySAP and one for Oracle DB. If you are already using the Biztalk adapters that shipped with Biztalk 2006 and Biztalk 2006 R2 and would like to migrate to using the newer adapters here is what you must know:

1. The message schemas that are generated by the adapter pack adapters are different from the schemas generated by the older adapters. There are many reasons why we had choose this the main one being that we had keep the new schemas compatible with WCF (so that it could be deserialized into proxy classes). The older schemas were not compatibile with WCF.

2. Once you install the new adapters you will not see a port of type "SAP" or "OracleDB" or "Siebel" like with the older adapters. When configuring a send port or a receive location, you would need to choose the port of type WCF-Custom and within that choose the correct binding (SAPBinding, SibelBinding or OracleDBBinding) as the WCF custom binding.

Due to the above if you have an existing orcestration that is working in Biztalk 2006 or 2006 R2, to migrate to using the new adapters, you would need to regenerate the schemas (implying any maps built using the schemas would have to be recreated) and re-configure the send and receive ports. The format of the xml messages that the adapter receives and sends have also changed (implied by the schema changes). This is true of almost all scenarios that are being migrated from using the old adapters to using the new adapters.

The only exception to this is the IDoc scenario that would work with the new SAP adapter. The schemas generated by the new adapter for the IDocs would be different but you can continue to have the new adapter work with an existing Biztalk solution by just changing the send or the receive port to send or recieve a "string" typed IDocs. Refer to the seperate blog post which describes this scenario with an example.