Simplifying BizTalk adapters configuration using SO-Aware

Centralized configuration is one of the most attractive features of SO-Aware. The ability of managing WCF bindings and behaviors from a central location without imposing the scalability limitations of a message broker, addresses some of the key challenges of WCF enterprise solutions. This capability can be leveraged by any technology that relies on WCF configuration. Examples of those technologies are Windows Azure, SharePoint Server, BizTalk Server and specifically the BizTalk Adapter Pack.

The BizTalk Adapter Pack based on the WCF LOB Adapter SDK abstracts the interaction with LOB systems using WCF as the underlying protocol layer. Essentially, WCF adapters are implemented as WCF bindings which abstract the configuration and communication with LOB systems such as SAP or PeopleSoft. Although adapters are particularly popular on BizTalk applications, they can be used by any .NET application that requires to interact with a LOB system.

As typical WCF bindings, the adapters rely heavily on configuration to express the behavior required to interact with the specific LOB system. This configuration is quite often very complex and challenging to manage. Using SO-Aware, we could centralize the configuration of WCF-based adapters so that they can be used by the different client applications. Let's take a first look at how will this pattern work using SO-Aware. For the simplicity of this sample, we've decided to use the SQL Server WCF adapter included in the current version of the BizTalk Adapter pack.

The first step to use a WCF LOB Adapter with SO-Aware is to create a new binding type that corresponds to the adapter. The following figure illustrates this concept using the WCF-based SQL Server adapter.

After we've successfully configured the binding type, we can create new configuration for that specific adapter as illustrated in the following figure.

At this point, we can use the specific configuration on service endpoints such as BizTalk Server send ports. The following figure shows this concept.

Well, that's all we need to do to centralize the configuration of WCF-based LOB adapters. At this point, we can create new client applications (BizTalk or not) that interact with the LOB system without the need of managing complex sets of configuration.

Using SO-Aware, we can interact with all adapter with 0 configuration!!! We can accomplish that by using our configurable channel factory included as part of the current release as illustrated in the following code.

   1:  

   2:  private static void SOAwareSQLAdapterTest()

   3:  {

   4:    ConfigurableProxyFactory<TableOp_dbo_Contact> factory =

   5:                 new ConfigurableProxyFactory<TableOp_dbo_Contact>

   6:                 (new Uri("http://localhost/SOAware/ServiceRepository.svc/"),

   7:                 "SQLAdapterService(1.0)", "dev");

   8:    TableOp_dbo_Contact channel= factory.CreateProxy();

   9:    SelectResponse contactsResponse= channel.Select(new SelectRequest("*", ""));

  10:  }

Aren't you seeing the benefit already. Let's compare it to the traditional approach. The following code highlights the configuration required by a .NET client that needs to interact with SQL Server using our sample adapter.

   1: <system.serviceModel>

   2:         <bindings>

   3:             <sqlBinding>

   4:                 <binding name="SqlAdapterBinding" 

   5:                     closeTimeout="00:01:00" openTimeout="00:01:00"

   6:                     receiveTimeout="00:10:00"

   7:                     sendTimeout="00:01:00" maxConnectionPoolSize="100"

   8:                     encrypt="false" workstationId="" 

   9:                     useAmbientTransaction="true"

  10:                     batchSize="20" 

  11:                     polledDataAvailableStatement="" pollingStatement=""

  12:                     pollingIntervalInSeconds="30"

  13:                     pollWhileDataFound="false" notificationStatement=""

  14:                     notifyOnListenerStart="true" 

  15:                     enableBizTalkCompatibilityMode="true"

  16:                     chunkSize="4194304"

  17:                     inboundOperationType="Polling"

  18:                     useDatabaseNameInXsdNamespace="false"

  19:                     allowIdentityInsert="false" 

  20:                     enablePerformanceCounters="false"

  21:                     xmlStoredProcedureRootNodeName="" 

  22:                     xmlStoredProcedureRootNodeNamespace="" />

  23:             </sqlBinding>

  24:         </bindings>

  25:         <client>

  26:             <endpoint address="mssql://.//Demos?" binding="sqlBinding" 

  27:                       bindingConfiguration="SqlAdapterBinding"

  28:                 contract="TableOp_dbo_Contact" 
                      name="SqlAdapterBinding_TableOp_dbo_Contact" />

  29:         </client>

  30:     </system.serviceModel>

Now multiply this by dozens of endpoints and you can start picturing the management nightmare that we typically experience on medium to large BizTalk deployments. Centralizing the configuration also has the advantage that semi-sensitive information about the LOB systems such as the connection strings etc are saved somewhere else outside the client application