Why would you want a WCF LOB SDK Adapter?

Introduction

In my last post I mentioned the registry content for registering a custom WCF LOB SDK binding as an adapter. I am still working out the details of how this should be done for a custom adapter and will be hoping how to do this in a walkthrough in a later post. 

To give you some preview of the process, the adapter class just needs to inherit from Microsoft.Adapters.Common.BizTalk from the BizTalk adapter pack rather than Microsoft.ServiceModel.Channels.Common.Adapter from the WCF LOB SDK. The abstract classes for Microsoft.Adapters.Common.BizTalk are included with the BizTalk Adapter Pack. The GUID values mentioned in the .reg file are set in the derived adapter classes and when calling the base class constructor for the adapter, WcfBtsAsdkAdapterBinding.

While it looks like it is possible to register a custom WCF LOB SDK binding as an adapter, the question comes up as to why would you ever want to do this when you can just use the custom binding in the WCF-Custom adapter anyway. This is one question I have asked repeatedly in reference to why the BizTalk adapter pack gives the developer the option of using the separate adapter rather than the bindings with the WCF-Custom adapter. At this time I am not sure if some of the scenarios I have come up with explain why the BizTalk adapter pack bindings are also exposed as custom adapters.

I wanted to take this post and describe a few scenarios that would be useful for having the capability of an adapter rather than a WCF-Custom binding.

Discussion

Deciding whether to expose a WCF LOB SDK binding vs. a full adapter is an important question that depends largely on the consumers of your data. If you want the same data and management of the connection to your data to be the same whether it is being called from .NET or BizTalk then use of the standard custom binding makes sense. You will only need to code the logic once as the custom binding. But there are typically many differences between .NET applications and BizTalk applications so it seems like there would be compelling reasons to have other settings or different settings based on whether the binding is being called from a BizTalk system. For example, SSO settings like the SSO Application Name and key should not be exposed unless the binding is being called from BizTalk. These properties will not make sense if you are providing a way to connect to your custom LOB data without going through BizTalk.

The full adapter does have a configuration limitation that prevents it from fully functioning as an equivalent to the WCF-Custom binding. The custom binding configuration exposes the custom behavior config window for all WCF-Custom adapter handler properties. At this point I am not sure if it is possible to have the custom full adapter to provide a customized property page for the adapter handler properties. Interestingly, all of the BizTalk adapter pack custom adapters have the properties button grayed out in the adapter handler window.  So it is not even possible to choose the same adapter handler configuration as found on the WCF-Custom adapter handlers so if you did use a full adapter rather than WCF-Custom you would still need to register the custom WCF behaviors in the machine.config. This could possibly be an overlooked scenario in the current implementation.

So theoretically it is possible to come up with a reasonably good scenario for splitting apart the properties and implementation based on the caller type. But due to the current BizTalk admin console limitation on the adapter handlers configuration, there may unfortunately be some tradeoffs.

Thanks,

Sample .reg file for WCF-LOB SDK Adapter registration

On the forums today someone was asking how to register a custom adapter based on the WCF LOB SDK. The question was not how to get it to show up in the bindings list for the WCF-Custom adapter, it was how to get the custom adapter to show up as an actual adapter. With the BizTalk adapter pack, the custom adapters show up both as custom bindings under the WCF-Custom adapter and as custom adapters under Platform Settings\Adapters. The WCF LOB SDK gives good examples for how to register the custom binding and there are some free tools to help with this like this one: http://regwcflobmsbuildtask.codeplex.com/. But there are not any .reg files in the samples folder for the SDK like there are for the samples found at c:\Program Files (x86)\Microsoft BizTalk Server 2010\SDK\Samples\Adapter Development\…

I developed one custom adapter using the older adapter framework for a major client to interface with the Endeca search index tool (www.endeca.com). Based on my experience working with the adapter framework, I knew there was probably a GUID value I could use to find the registry settings for registering a WCF LOB SDK adapter. So I opened the WCF-SQL adapter assembly in Reflector and found the GUID value. Then I opened the registry and searched it under HKLM\Software\Microsoft to find the registry keys for the WCF-SQL adapter. Although this was not surprising to me, it was interesting to see that many of the registry values are similar to the values given for the adapter framework settings in the .reg files of the SDK samples.

Here is the WCF-SQL adapter registry content – shown below. Here is a link for just downloading the .reg file. This seemed like a missing sample file so I will be working on taking the Contoso and Echo adapters and creating registry files for them. There are a couple logical questions about what to do to your custom WCF LOB SDK code in order to make it work with the .reg file so I will be working on that next. Having the .reg file available makes it a lot easier to accomplish the adapter registration.

Thanks!

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{59b35d03-6a06-4734-a249-ef561254ecf7}]
@="WCF-SQL"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{59b35d03-6a06-4734-a249-ef561254ecf7}\BizTalk]
@="BizTalk"
"TransportType"="WCF-SQL"
"Constraints"=dword:0000030b
"ReceiveLocation_PageProv"="{86e62ea8-d681-4aac-a62b-f8e7dc0306b4}"
"TransmitLocation_PageProv"="{ea897b1c-08b9-4d21-87fa-223f7fc5acf3}"
"AdapterMgmtCLSID"="{dea558d0-6960-4f96-9bc7-9b3837689fc0}"
"AdapterMgmtTypeName"="Microsoft.Adapters.Sql.BizTalk.WcfBtsSqlManage, Microsoft.Adapters.Sql.BizTalk, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
"InboundEngineCLSID"="{1ad7c0c2-cdd2-4e87-922c-6e89d9f8b0e2}"
"InboundTypeName"="Microsoft.Adapters.Sql.BizTalk.WcfBtsSqlReceiver, Microsoft.Adapters.Sql.BizTalk, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
"OutboundEngineCLSID"="{6a640a11-2f39-42eb-96c7-490aac4f32f6}"
"OutboundTypeName"="Microsoft.Adapters.Sql.BizTalk.WcfBtsSqlTransmitter, Microsoft.Adapters.Sql.BizTalk, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
"PropertyNameSpace"="http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties"
"AliasesXML"="<AdapterAliasList />"
"ReceiveHandlerPropertiesXML"="<CustomProps><WcfExtensions vt=\"8\" /></CustomProps>"
"ReceiveLocationPropertiesXML"="<CustomProps><Headers vt=\"8\" /><BindingType vt=\"8\" /><BindingConfiguration vt=\"8\" /><ReferencedBindings vt=\"8\" /><ServiceBehaviorConfiguration vt=\"8\" /><EndpointBehaviorConfiguration vt=\"8\" /><InboundBodyLocation vt=\"8\" /><InboundBodyPathExpression vt=\"8\" /><InboundNodeEncoding vt=\"8\" /><OutboundBodyLocation vt=\"8\" /><OutboundXmlTemplate vt=\"8\" /><DisableLocationOnFailure vt=\"11\" /><SuspendMessageOnFailure vt=\"11\" /><IncludeExceptionDetailInFaults vt=\"11\" /><CredentialType vt=\"8\" /><UserName vt=\"8\" /><Password vt=\"8\">Encrypted</Password><AffiliateApplicationName vt=\"8\" /><OrderedProcessing vt=\"11\" /><Identity vt=\"8\" /></CustomProps>"
"SendHandlerPropertiesXML"="<CustomProps><WcfExtensions vt=\"8\" /></CustomProps>"
"SendLocationPropertiesXML"="<CustomProps><Headers vt=\"8\" /><BindingType vt=\"8\" /><BindingConfiguration vt=\"8\" /><ReferencedBindings vt=\"8\" /><EndpointBehaviorConfiguration vt=\"8\" /><StaticAction vt=\"8\" /><UseSSO vt=\"11\" /><UserName vt=\"8\" /><Password vt=\"8\">Encrypted</Password><AffiliateApplicationName vt=\"8\" /><ProxyAddress vt=\"8\" /><ProxyUserName vt=\"8\" /><ProxyPassword vt=\"8\">Encrypted</ProxyPassword><InboundBodyLocation vt=\"8\" /><InboundBodyPathExpression vt=\"8\" /><InboundNodeEncoding vt=\"8\" /><OutboundBodyLocation vt=\"8\" /><OutboundXmlTemplate vt=\"8\" /><PropagateFaultMessage vt=\"11\" /><EnableTransaction vt=\"11\" /><IsolationLevel vt=\"8\" /><Identity vt=\"8\" /></CustomProps>"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{59b35d03-6a06-4734-a249-ef561254ecf7}\Implemented Categories]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{59b35d03-6a06-4734-a249-ef561254ecf7}\Implemented Categories\{7F46FC3E-3C2C-405B-A47F-8D17942BA8F9}]

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{59b35d03-6a06-4734-a249-ef561254ecf7}\Install]
"Assembly"="Microsoft.Adapters.Sql.BizTalk, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
"DateTime"="12/28/2010 00:20:47"

WCF LOB SDK Talk at CNUG – June 16

I will be presenting my WCF LOB SDK talk I did for the Magenic CodeMastery event for the Chicago .NET User Group on June 16. This is part of a special interests group (SIG) for BizTalk – http://www.cnug.org/. This presentation is great for anyone doing WCF and working with WCF custom bindings. Although BizTalk will certainly be mentioned during the presentation, the targeted audience will be .NET developers working with WCF.

 

In my talk at Code Mastery I presented on VS 2008 but I may be switching over to VS 2010 and working with the BizTalk 2010 beta bits as part of the demo depending on how well the performance of the demo does in my testing.

 

Hope to see you there!

CodeMastery Conference Recap

Today I spoke on the WCF LOB SDK and I just wanted to say thanks for everybody who attended.

 

I was amazed by the low number of people who had built WCF custom bindings and how few people knew of ESBs within their company. Perhaps this trend was specific to the audience but interesting none the less. As promised, I am releasing the slides and sample SalesForceBinding created for my session. I am making a few tweaks to the SalesForceBinding but will be posting it here as a comment later this week.

 

Here are my slides if you are interested: PowerPoint (http://cid-62e68922e47bc425.office.live.com/view.aspx/Presentations/WCF%20LOB%20SDK%20CM.ppsx) or PDF (http://public.bay.livefilestore.com/y1pXRBwvG7-qWivjfMg5U28l5BWPTqN-Z9KO5kUGcC9GeclL8oLCfLn8r0qAUtOOFd8rGDkijPbBSe7VaJRT3_nqg/WCF%20LOB%20SDK%20CM.pdf?download&psid=1)

 

– Update –

I fixed the links above. With the Office 2010 launch there is a new PPT viewer and all the urls for my presentations changed again.

 

Thanks!

WCF LOB SDK Talk on May 26

I will be speaking at a Magenic sponsored mini conference called Code Mastery on May 26 2010. Here is a link to the site: http://codemastery.com/index.htm. Magenic is hosting a couple of these mini conferences in the regions we have offices. The site will be updated soon with more information on the sessions and speakers. It is a free event so bring a friend!

 

I will be talking about the WCF LOB SDK from both a BizTalk and general .NET user perspective. This is a technology that is fairly well known in the BizTalk community but almost completely unknown in the general .NET community. I give some introductory articles below but notice that almost everything is directly from Microsoft and on the heavily technical side. I will be reviewing some of these concepts but will also be approaching it from a practical perspective about how this technology would fit within the enterprise and how you might use it in your software projects.

 

Here are a couple of good links to get you started:

Introduction (old): http://channel9.msdn.com/posts/Charles/Sonu-Arora-and-C-Venkatesh-WCF-Line-of-Business-Adapter-SDK/

 

Install Guide with download links: http://download.microsoft.com/download/9/0/d/90d3fc09-de48-4d83-8147-e8a08275c255/InstallationGuide.htm

 

WCF LOB SDK architecture: http://blogs.msdn.com/sonuarora/archive/2007/03/26/about-wcf-lob-adapter-sdk.aspx

 

Metadata capabilities: http://blogs.msdn.com/sonuarora/archive/2007/04/04/using-adapter-development-wizard.aspx

 

 

 

WCF LOB SDK flies under the Radar – BDC Extensions Await

Recently I worked on a BDC project and I was able to get a taste for what is possible for out-of-the-box SharePoint integration with external systems. The tricky aspect of BDC web service integration is that it only works with older web services – ones that use Basic Profile. The challenge of this is that you are limited in the integration options that are available because you must rely on the older SOAP and HTTP protocols. There are Office SDK samples that showcase integration with SAP and Siebel over BDC web services or Oracle over BDC database connections, but I was wondering how I would expose PeopleSoft or some other enterprise system that cannot be reached with a Basic Profile web service or a database connection.

 

Based on my BizTalk background, I knew that I could use the PeopleSoft adapter through BizTalk and then expose a BizTalk orchestration as a Basic Profile web service that could then be consumed by the BDC. So essentially this would be like a BDC bridge over BizTalk. This is when I started exploring the WCF LOB SDK as an interesting technology because the BizTalk adapter pack 1.0 is based on this SDK and it basically provides enterprise integration over WCF. Very few people are playing with the WCF LOB SDK, mostly because I think it seems confusing and has a poor name. The SDK is targeted at BizTalk developers with its "adapter" terminology, but it is really more of a way to talk about BDC from an adapter-oriented mindset. The LOB terminology should connect in your mind the LOB aspects of the BDC. If you look at the BDC documentation, the concepts are all about connections rather than adapters, but the WCF LOB SDK redefines the adapter concept by describing it as part of the channel infrastructure. So the future for the BDC is a redefined adapter based in WCF.

 

I found a few links that tie together the BDC adapters <-> WCF LOB SDK concepts, which really give us a glimpse of how the WCF LOB SDK is going to actually become more valuable from a MOSS perspective as the MOSS product is enhanced to support WCF. Usage pattern 7 on http://blogs.msdn.com/biztalk_adapter_development/archive/2007/07/09/wcf-lob-adapter-usage-patterns.aspx mentions how future BDC enhancements will rely on the WCF LOB SDK. It looks like Jesus Rodriguez also played with some of these scenarios: http://weblogs.asp.net/gsusx/archive/2007/07/12/sharepoint-bdc-wcf-adapters-and-more.aspx. The dates on these links suggest these concepts are old news but it is still relevant because the BizTalk adapter pack 1.0 was only recently released. The plans for this SDK go way back but the vision for how it will be used in the future seem to be missing. The WCF LOB SDK gives us a vision for the future of the BDC, which should include having a better designer experience for BDC developers as well as a much richer level of connectivity and flexibility. So the ROI for the WCF LOB SDK is still down the road, but once MOSS can support WCF it will be possible to integrate these other enterprise systems like PeopleSoft straight from the BDC. This is an exciting vision for the future of the BDC technology and a great reason to get your hands dirty with the WCF LOB SDK.

 

Thanks,