Share via

Changes to the WCF LOB Adapter SDK in SP2

  • Article

If you’re developing your own adapters against the WCF LOB Adapter SDK, then it might be worth your while to try out the June CTP of the SP2 of the WCF LOB ASDK. There are a few minor changes, but we might make more based on your feedback.

I’m mentioning the changes from SP1 to the June CTP of SP2 in brief. For more details, you should refer to the documentation.

  • Support for VS 2008 and .NET 3.5. 
  • Pre SP2, the ASDK allowed all input channel shapes – IInputChannel, IInputSessionChannel, IReplyChannel, and IReplySessionChannel. In SP2, there is a setting exposed to the adapter, which allows the adapter to control which of the above four shapes should be allowed. This is important when the adapter is used with BizTalk, and you want to integrate the LOB transaction (assuming it understands System.Transaction) with the BizTalk MessageBox transaction – in such a situation, you only want to allow one-way channels to be used. In other cases (SAP for example), where a reply always needs to be sent back to the LOB, you might want to only allow two-way channels.
  • Pre SP2, the WSDL generated (based on the operations selected in the Metadata Search Browse (MSB) UI) was always compiled before being returned to the caller (or being converted to a WCF proxy). In some situations (e.g., where the adapter is overriding the XSD generation to return metadata for – let’s say a System.Data.DataSet) – the XSD/WSDL might not compile (even though svcutil.exe can successfully convert it to a WCF proxy). In order to allow this, a setting is exposed to the adapter which determines whether the WSDL should be compiled or not, before being converted to a WCF proxy. The advantage of compilation is that it can catch “real” errors in the wsdl.
  • There are two new QualifiedTypes added for System.Data.DataSet. (For “why two” and “why not just one”, refer to the documentation).
  • Pre SP2, when using the “Consume Adapter Service” tool in a BizTalk project, the XSD files generated had names like “MyBinding1.xsd”, “MyBinding2.xsd”, etc. Even though a “filename prefix” textbox was present, it had a couple of drawbacks - (a) the user had to provide the prefix, which might not clearly indicate what the XSDs contained, and (b) the same prefix applied to all XSDs generated during the metadata resolution of all operations selected in the UI. In SP2, it is now possible for the adapter to specify a “filename hint” for each XSD generated.