Commerce Server 2007: B2B Solution Development Overview (Series Post #2)

Designing and developing a B2B E-Commerce solution using Commerce Server 2007 and BizTalk Server 2006 and the new Commerce Server BizTalk Adapters can be fairly complex but there are a few best practices which can simplify this process. This may sound a little radical if you've never developed this type of solution before but I recommend beginning your Commerce Server development efforts with the BizTalk applications that your solution will use to communicate with the outside world, especially with your ERP system.

 

One of the most exciting new features in Commerce Server 2007 is the addition of four new BizTalk adapters that are specifically designed to make it easier to integrate Commerce Server data with other layer-of-business (LOB) systems using BizTalk Server 2006. These four adapters are designed to work with the Orders, Catalog, Inventory and Profiles subsystems, and allow Commerce Server to perform bi-directional information exchange between any number of different back-end systems. Since the overall goal of any e-commerce solution is to fulfill a customer’s order, having a means to easily integrate the web “front-end” with the ERP system’s “back-end” is vital. These new adapters make it possible to perform all sorts of real-time and near real-time integrations without writing a ton of custom code; and these adapters are not third-party “bolt-ons,” they were designed specifically for integrating with Commerce Server 2007.

As you would expect, the data received from and sent to the Commerce Server adapters is in XML format and like any other BizTalk document instance, it can be processed using all the available BizTalk tools. This includes data transformation (mapping from one schema to another), orchestration and rules engine processing, as well as transportation to external systems by other BizTalk adapters, such as the FILE, SMTP and FTP adapters. This rich functionality now allows for true integration between your Commerce Server web applications and other external systems with a minimum of development effort and cost.

Development Overview

  • Develop your integration schemas, maps, pipelines and orchestrations using BizTalk Server 2006 and the new Commerce Server adapters first. These should include outbound purchase orders, order updates, inventory updates, catalog updates, customer and organization (profile) updates, and any other information you need to exchange with your ERP system. During this work, you're likely to find out what "custom information" (not provided by Commerce Server by default) your ERP system requires to process and fulfill an order.

  • Extend the Commerce Server Orders subsystem to accommodate this "custom information" required to process and fulfill an order. This can be done by extending the Orders and LineItem classes in Commerce Server to add the custom properties and methods your application requires. The online documentation has a very good explanation of how to get started on this.

  • Create your product and inventory catalog schemas adding any "custom information" required to process and fulfill an order. This is done using the Catalog and Inventory Schema Manager tool provided with Commerce Server 2007. Add any required product- or inventory-related custom properties to your schema and test, test, test. Decide how you plan to present your catalogs to users on your site and most of all… KEEP IT SIMPLE!

  • Modify the standard UserObject, Organization and Address profile schemas to include any "custom information" required to process and fulfill an order. You'll find that not all custom information "fits" into the catalog or orders system directly. Some things (such as a customer number from your ERP system) fit into the Profiles subsystem better. So, you'll need to make some profile changes or perhaps add a few new profiles of your own.

  • Go ahead and start writing some site code using the new StarterSite or CSharp.pup as the basis for your Web site. Now that you know all the custom information that your integrated e-commerce system needs to process and fulfill an order, you're ready to begin writing your site code. You already know what an "Order" looks like and what fields your product "Catalog" holds. You also know where to get the "customer number" from your modified Organization profile. All you need to do now is put it all together with your site code.

For more details on using the new Commerce Server BizTalk Adapters, take a look at the article I wrote for Microsoft's TechNet web site last August.

Integrating Commerce Server Orders with BizTalk Server

Technorati Tags: Commerce Server 2007, BizTalk Server 2006

Share this post: Email it! | bookmark it! | digg it! | reddit!| kick it!

Commerce Server 2007: B2B Solution Development Overview (Series Post #2)

Designing and developing a B2B E-Commerce solution using Commerce Server 2007 and BizTalk Server 2006 and the new Commerce Server BizTalk Adapters can be fairly complex but there are a few best practices which can simplify this process. This may sound a little radical if you've never developed this type of solution before but I recommend beginning your Commerce Server development efforts with the BizTalk applications that your solution will use to communicate with the outside world, especially with your ERP system.

 

One of the most exciting new features in Commerce Server 2007 is the addition of four new BizTalk adapters that are specifically designed to make it easier to integrate Commerce Server data with other layer-of-business (LOB) systems using BizTalk Server 2006. These four adapters are designed to work with the Orders, Catalog, Inventory and Profiles subsystems, and allow Commerce Server to perform bi-directional information exchange between any number of different back-end systems. Since the overall goal of any e-commerce solution is to fulfill a customer’s order, having a means to easily integrate the web “front-end” with the ERP system’s “back-end” is vital. These new adapters make it possible to perform all sorts of real-time and near real-time integrations without writing a ton of custom code; and these adapters are not third-party “bolt-ons,” they were designed specifically for integrating with Commerce Server 2007.

As you would expect, the data received from and sent to the Commerce Server adapters is in XML format and like any other BizTalk document instance, it can be processed using all the available BizTalk tools. This includes data transformation (mapping from one schema to another), orchestration and rules engine processing, as well as transportation to external systems by other BizTalk adapters, such as the FILE, SMTP and FTP adapters. This rich functionality now allows for true integration between your Commerce Server web applications and other external systems with a minimum of development effort and cost.

Development Overview

  • Develop your integration schemas, maps, pipelines and orchestrations using BizTalk Server 2006 and the new Commerce Server adapters first. These should include outbound purchase orders, order updates, inventory updates, catalog updates, customer and organization (profile) updates, and any other information you need to exchange with your ERP system. During this work, you're likely to find out what "custom information" (not provided by Commerce Server by default) your ERP system requires to process and fulfill an order.

  • Extend the Commerce Server Orders subsystem to accommodate this "custom information" required to process and fulfill an order. This can be done by extending the Orders and LineItem classes in Commerce Server to add the custom properties and methods your application requires. The online documentation has a very good explanation of how to get started on this.

  • Create your product and inventory catalog schemas adding any "custom information" required to process and fulfill an order. This is done using the Catalog and Inventory Schema Manager tool provided with Commerce Server 2007. Add any required product- or inventory-related custom properties to your schema and test, test, test. Decide how you plan to present your catalogs to users on your site and most of all… KEEP IT SIMPLE!

  • Modify the standard UserObject, Organization and Address profile schemas to include any "custom information" required to process and fulfill an order. You'll find that not all custom information "fits" into the catalog or orders system directly. Some things (such as a customer number from your ERP system) fit into the Profiles subsystem better. So, you'll need to make some profile changes or perhaps add a few new profiles of your own.

  • Go ahead and start writing some site code using the new StarterSite or CSharp.pup as the basis for your Web site. Now that you know all the custom information that your integrated e-commerce system needs to process and fulfill an order, you're ready to begin writing your site code. You already know what an "Order" looks like and what fields your product "Catalog" holds. You also know where to get the "customer number" from your modified Organization profile. All you need to do now is put it all together with your site code.

For more details on using the new Commerce Server BizTalk Adapters, take a look at the article I wrote for Microsoft's TechNet web site last August.

Integrating Commerce Server Orders with BizTalk Server

Technorati Tags: Commerce Server 2007, BizTalk Server 2006

BizTalk Server 2006 Documentation in PDF Format

We have published an update to the BizTalk Server 2006 core documentation PDF here. Here are some of the juicy details:



  • The PDF is in a self-extracting zip and weighs in at about 55 megs.

  • When extracted, the PDF is about 120 megs.

  • The PDF contains almost 20,000 pages.

  • Links are highlighted in blue but are not active. Enabling links is a potential future enhancement.

  • Searching a document this size takes time.

Again, this is a single PDF file containing all of the BizTalk Server documentation. If you prefer a more granular approach, please post your thoughts.

WCF Adapter Content Forthcoming!


Thanks to my co-worker and good friend PM Sonu Arora, I will begin posting content on the WCF LOB Adapter SDK on this site. For more information on this SDK and very useful programming information, add a link to her blog at http://blogs.msdn.com/sonuarora/


 


 


The Windows Communication Foundation (WCF) Line-of-Business (LOB) Adapter SDK is a collection of runtime engine and tools to help Adapter Developers in creating service-oriented interfaces to existing LOB applications using WCF.  The goal of the WCF LOB Adapter SDK is to facilitate uniform development of reusable metadata-oriented WCF-based adapters that enable enterprise applications, databases and messaging platforms to integrate with each other.  The Adapter SDK is based on WCF and it surfaces an adapter to a LOB application as a WCF Binding. 


 


Relationship with BizTalk Server


BizTalk Server ships with BizTalk Adapter Framework which promotes creating custom adapters for use within BizTalk Server.  BizTalk adapters use the BizTalk Server Administration Console for adapter management, BizTalk Explorer for adapter configuration, and the Adapter Framework for design-time APIs.  WCF LOB Adapter SDK is the evolution of BizTalk Adapter Framework.  Since WCF LOB Adapter SDK is based on new architecture, the adapters built to Adapter SDK will continue to co-exist side-by-side with the adapter written using BizTalk Adapter Framework.    Microsoft and Microsoft’s Technology Partners have built adapters using BizTalk Adapter Framework.  The future direction recommended by Microsoft is to start using WCF LOB Adapter SDK for building new adapters. 


 


Relationship with WCF


The Adapter SDK is based on WCF.  It is exposed as a WCF Binding and implements WCF System.ServiceModel.Channels.TransportBindingElement for handling communication between a client and a service.  It extends WCF with metadata browse, search and resolve interfaces for Adapter Consumer to selectively compose the Service Description contract.  The Adapter SDK enables Adapter Developers to easily create WCF binding(s) and channel(s) for layering existing applications with service-oriented interfaces.  


Adapters differ from regular WCF transports due to these main characteristics:


          Adapters are metadata-centric


o   Require metadata at run-time


o   Require metadata cache management


o   To provide rich metadata at design-time they require search/browse/resolve protocol


          Adapters are always connection-oriented


o   Connection is very central concept for the adapter


o   Require connection pooling and connection life-cycle management


          Adapters are effectively “in-proc WCF Services”


Consuming an adapter is no different than consuming a WCF Service from the perspective of a WCF client and the adapter consumer is not required to learn a new programming model.  The client can use either the WCF Service Programming Model or WCF Channel Architecture to communicate with an adapter.


A typical WCF service programming lifecycle begins by a Service Provider defining a static service contract, implementing this contract and hosting the service.  Each service is defined entirely by a fixed monolithic contract.   This contract needs to be updated by the service provider in order to reflect any changes in the existing application. The Adapter built using WCF LOB Adapter SDK, on the other hand, surfaces the contracts on-demand by consumer.   The consumer browses through the available metadata in the adapter using the standard interfaces and then selects the operations and types for inclusion in a dynamic contract.    The metadata can be updated when the existing application change providing up-to-date interfaces for the new clients.  Adapters are more appropriate in scenarios where a non-WCF based system is being exposed for integration.


For an Adapter Consumer, the adapter can be accessed like a typical WCF Service and the consumer doesn’t have to learn a new programming model.  The same adapter developed using the Adapter SDK can be reused in multiple .NET applications including Custom WCF Client Applications, BizTalk Server, SharePoint Server and SQL Server Integration Services.  In addition, Adapter SDK provides a common facility for Adapter Developers to expose rich LOB metadata to the Adapter Consumers, who can selectively compose and create dynamic WCF contracts from this available metadata in the adapter.


 


Goals


Here are three main goals of the WCF LOB Adapter SDK


1.       Uniformity



  • No unified adapter development framework for .NET

  • Every “integration technology” implements its own adapter framework

  • Provides an abstraction layer between service oriented world and proprietary application interfaces

2.       Reusability



  • Adapters written using BizTalk adapter framework specific to BizTalk

  • Duplication of effort – e.g. at least 5 SAP adapters in Microsoft

  • Surfaces adapter as a WCF binding, widening reach

3.       Consumer-Driven Dynamic Contracts



  • Provides interfaces for browsing, searching and resolving metadata

  • Provides a service-tier that reflects changes in the existing application type model

  • Extends WCF to provide an ability to generate dynamic contracts (service description) from available metadata