One of the problems we face during the development of BizTalk Application is that lack of space in the main drive C:\, Since we do default installation for MSSQL and BizTalk 2004, the Data File and Log Files is of course is installed in C:\Program Files\Microsoft SQL Server\MSSQL\Data.

To solve this is we have to move all BizTalk's DB from C:\ to another drive. Another thing is, we also do have the CovastDB which is used in X12 parsing which has to be moved also.

Note: Before performing this operation you should first stop the following services:

Enterprise Single Sign-On Services

BizTalk Service BizTalk Group : BizTalkServerApplication

Covast EDI Service

Script:

sp_detach_db 'BAMArchive'
sp_detach_db 'BAMPrimaryImport'
sp_detach_db 'BizTalkDTADB'
sp_detach_db 'BizTalkEDIDb'
sp_detach_db 'BizTalkHwsDb'
sp_detach_db 'BizTalkMgmtDb'
sp_detach_db 'BizTalkMsgBoxDb'
sp_detach_db 'BizTalkRuleEngineDb'
sp_detach_db 'SSODB'
sp_detach_db 'CovastDB'

sp_attach_db 'BAMArchive',
'E:\DBDat\BAMArchive.mdf',
'F:\DBLOG\BAMArchive_log.LDF'

sp_attach_db 'BAMPrimaryImport',
'E:\DBDat\BAMPrimaryImport.mdf',
'F:\DBLOG\BAMPrimaryImport_log.LDF'

sp_attach_db 'BizTalkDTADB',
'E:\DBDat\BizTalkDTADB.mdf',
'F:\DBLOG\BizTalkDTADB_log.LDF'

 

sp_attach_db 'BizTalkEDIDb',
'E:\DBDat\BizTalkEDIDb.mdf',
'F:\DBLOG\BizTalkEDIDb_log.LDF'

 

sp_attach_db 'BizTalkHwsDb',
'E:\DBDat\BizTalkHwsDb.mdf',
'F:\DBLOG\BizTalkHwsDb_log.LDF'

sp_attach_db 'BizTalkMgmtDb',
'E:\DBDat\BizTalkMgmtDb.mdf',
'F:\DBLOG\BizTalkMgmtDb_log.LDF'

sp_attach_db 'BizTalkMsgBoxDb',
'E:\DBDat\BizTalkMsgBoxDb.mdf',
'F:\DBLOG\BizTalkMsgBoxDb_log.LDF'

sp_attach_db 'BizTalkRuleEngineDb',
'E:\DBDat\BizTalkRuleEngineDb.mdf',
'F:\DBLOG\BizTalkRuleEngineDb_log.LDF'

sp_attach_db 'SSODB',
'E:\DBDat\SSODB.mdf',
'F:\DBLOG\SSODB_log.LDF'

sp_attach_db 'CovastDB',
'E:\DBDat\CovastDB.mdf',
'F:\DBLOG\CovastDB_log.LDF'

Luckily, BizTalk 2004 and Covast still work.

In BizTalk 2004 it's possible to connect just one Receive Port an SAP enviroment.

This can be a limitation when i want to receive many kinds Idoc (p.es. DELVRY02, ZOIFSEDE01, ... ).

For solve this problem i have create a simple orchestration that receive an inbound document very simple: the figure Inbound_Message explain that.

 

This schema have an simple row that load all Idoc Received from SAP.

The orchestration give inbound document to an external assembly that read the Idoc and in the position 39 on the first row there is tha Idoc Family name. Depends this name the assembly can direct the entire Idoc in the right position (p.es. Folder, HTTP, ... ). The figure Orchestration_Idoc_Message explain that. I conseil of use a configuration file XML where put the rule of binding. P.es. the Idoc DELVRY02 must go in folder D:\DELVRY02, the Idoc ZOIFSEDE01 must go to folder D:\ZOIFSEDE01 and go on.

 

This is a very simple solution for solve the problem with unique Receive Port in binding with SAP enviroment.

 

 

 

The effective exchange of messages across different software on different machines is an absolute requirement for integration. Given the diversity of communication styles that exist, the BizTalk Server 2006 engine must support a variety of protocols and message formats. As described next, a significant portion of the engine is devoted to making this communication work. One important fact to keep in mind, however, is that the engine works only with XML documents internally. Whatever format a message arrives in, it must be converted to an XML document after it is received. Similarly, if the recipient of a document can’t accept that document as XML, the engine converts it into the format expected by the target.

Sending and Receiving Messages: Adapters

Processing Messages: Pipelines

Choosing Messages: Subscriptions

Creating business-to-business connections between trading partners is a common use of BizTalk Server today. Establishing these connections requires agreement on the communication protocol that will be used, the formats of messages that will be exchanged, and the business process that drives the interaction. Managing trading partner relationships can get complex, especially when many organizations are involved or when the players change frequently.

To allow information workers to perform these tasks, Business Activity Services include a Trading Partner Management (TPM) component. This component relies on a TPM database, as shown above, that stores information about trading relationships. Using the common Business Activity Services interface, information workers can create and modify agreements with trading partners who use BizTalk Server 2006. Each agreement describes the relationship between two parties, and the things it contains include:

• A profile for each of the partners. Each profile contains business information about the organization, such as a contact person and address, along with technical information such as the protocol (which determines the BizTalk Server adapter) that should be used to communicate with them.
  
  
• The business process itself, implemented as one or more orchestrations, along with the role each of the partners plays. One organization might act as the seller, for example, while the other acts as the buyer.
  
  
• An addendum with parameters for the business process that control the behavior of the orchestration implementing it. How these parameters are used is described in the next section.
  
  

Profiles, agreements, and addendums are all stored in the TPM database. Using the TPM component (and for addendums, the Business Process Configuration component, described next), all of thedr can be configured directly by an information worker. This allows business people to establish and modify new partner relationships without relying on developers.

Although a business analyst may not be able to create the orchestration that implements a business process,it’s not unreasonable to expect an information worker to set parameters for that orchestration. An example of where this would be useful is when an orchestration will be used with multiple partners, but each partner requires slightly different behavior. Suppose, for instance, that the maximum dollar value of a purchase order is different with different trading partners, or perhaps the maximum quantity that can be requested varies depending on the customer’s credit rating. For this type of change, business analysts could make these small configuration changes themselves.

To enable information workers configure an orchestration, the developer creating it can define parameters for that orchestration. Information workers can then set these parameters as needed, perhaps assigning different values for different business partners or different parts of their own organizations. An information worker sets those parameters using the TPM service, described in the previous section, by specifying their values in the addendum to this partner’s agreement. For agreement that reference multiple orchestrations, an addendum can be created for each orchestration.

Macro name	Substitute value
%datetime%	Coordinated Universal Time (UTC) date time in the format YYYY-MM-DDThhmmss (for example, 1997-07-12T103508).
%datetime_bts2000%	UTC date time in the format YYYYMMDDhhmmsss, where sss means seconds and milliseconds (for example, 199707121035234 means 1997/07/12, 10:35:23 and 400 milliseconds).
%datetime.tz%	Local date time plus time zone from GMT in the format YYYY-MM-DDThhmmssTZD, (for example, 1997-07-12T103508+800).
%DestinationParty%	Name of the destination party. The value comes from message the context property BTS.DestinationParty.
%DestinationPartyID%	Identifier of the destination party (GUID). The value comes from the message context property BTS.DestinationPartyID.
%DestinationPartyQualifier%	Qualifier of the destination party. The value comes from the message context property BTS.DestinationPartyQualifier.
%MessageID%	Globally unique identifier (GUID) of the message in BizTalk Server. The value comes directly from the message context property BTS.MessageID.
%SourceFileName%	Name of the file from where the File adapter read the message. The file name includes extension and excludes the file path, for example, foo.xml. When substituting this property, the File adapter extracts the file name from the absolute file path stored in the FILE.ReceivedFileName context property. If the context property does not have a value, for example, if message was received on an adapter other than File adapter, then the macro will not be substituted and will remain in the file name as is (for example, C:\Drop\%SourceFileName%).
%SourceParty%	Name of the source party from which the File adapter received the message.
%SourcePartyID%	Identifier of the source party (GUID). The value comes from the message context property BTS.SourcePartyID.
%SourcePartyQualifier%	Qualifier of the source party from which the File adapter received the message.
%time%	UTC time in the format hhmmss.
%time.tz%	Local time plus time zone from GMT in the format hhmmssTZD (for example, 124525+530).

If you have used maps in BizTalk, by now, you must know that maps are used to transform an XML message into another format. I do not intend to go into the details about BizTalk maps here, but in essence, a map is a transformation on your existing data to the output format you desire. In this article, I will illustrate an interesting feature called Dynamic Maps in BizTalk. If you are a C++ fan like me, you would be amazed at the power of polymorphism and how a call to a function, say Shape.Draw(), differs with each derived class of Shape like Arc, Square, or Circle. So I don't have to explain why dynamic mapping is important.

Quite often in BizTalk, you come across scenarios where you need to transform a message to an output format, which you can decide only after you know some information which is contained in the message itself, like destination recipient. This can be achieved by using maps in the ports itself, but as the number of parties grow and your exception handling requirements kick in, this route has some limitations. This is where dynamic mapping inside orchestrations make sense.

Scenario

For this exercise, I am building an orchestration which identifies the destination party and loads the corresponding map and sends the message to the intended recipient after the desired transformation. For this example, I have two parties ABC and XYZ.

A Bird's Eye View of the Steps

These are the steps for implementing our Dynamic Maps. I am assuming a working knowledge of BizTalk for the solution below, as the concept is what I intend to illustrate. You can skip these steps by downloading the source from above.

• Create a BizTalk Project for Maps.
• Create all Schemas and Maps.
• Create an Orchestration Project.
• Identify the party and load the Maps dynamically.
• Set the Destination dynamically and route the message.
• Deploy and GAC the DLL.
• Testing.

Getting Down to Business ..

I have broken down the process into a series of logical steps.

Step 1: Creating your Schemas and Maps Project

You need to create a Schema and Maps project. I have all my maps and schemas in a project called Dynamic Maps. I have added three schemas to the project.

• The Generic Schema (Common Input Schema)
• ABC Schema (for my party ABC)
• XYZ Schema (for my party XYZ)

The details of the three schemas are as below. The input schema comes in with some basic information. The output schemas differ for the two parties ABC and XYZ. The three schemas are shown below.

Right click on SubscriberInfo in the GenericSchema and do a Quick promotion. This will add a property schema to the BizTalk project.

Now we build the two maps. Both the maps use some basic information from the sources schema, and add some additional information on the output side. I have used the Time functoid to get the submission time.

Step 2: Signing the DLL with a Key

You need to have a strong name for this assembly to get it loaded in the toolbox. So create a strong name and sign it. Once you have the strong key generated, reference that in the Assembly Key file value in the project properties.

Step 3: Compile and deploy the Maps project

From project properties in the Solution Explorer window, deploy the project. Check in GAC to see if the DLL is deployed. Note down the public key token from the file properties in GAC.

Step 4: Build the Dynamic Maps orchestrations

Add a new BizTalk project OrchestrationForDynamicMaps. Create a new Orchestration and name it Orch_DynamicMaps. In the Orchestration View window, create the following variables and messages. Set the value as in the table below. Leave the rest of the values as their default values.

Message / Variable	Identifier	Type	Comments
Message	Generic_In	DynamicMaps.GenericInSchema	The incoming Message
Message	Message_Out	System.Xml.XmlDocument	The outgoing Message
Variable	SubscriberInformation	System.String	Promoted Subscriber Info
Variable	tMap	System.Type	The Map value

The orchestration built looks as in the figure below. The outline of steps is detailed below. You can download the source and follow the steps conceptually.

• Add a Receive Port Receive_GenericMessage which accepts the Generic_In message declared above.
• Add an Expression Shape Identify Subscriber and set the expression value as below:

  SubscriberInformation = 
     Generic_In(DynamicMaps.PropertySchema.SubscriberInfo );

• Add a Decide and check if SubscriberInformation == "ABC" or SubscriberInformation == "XYZ", and a branch for termination.
• Add an Expression Shape and name it Set Map and put the value.

  Change the public key token value to the value you noted down previously.

  tMap = System.Type.GetType("DynamicMaps.Map_ABC, 
           DynamicMaps, Version=1.0.0.0, Culture=neutral, 
           PublicKeyToken=f85be9e4dd36fb1d");

• Add a Message Shape and do the dynamic transformation and dynamically set the Send port. These are the magic lines:

  transform (Message_Out) = tMap(Generic_In);
  Dynamic_Send(Microsoft.XLANGs.BaseTypes.Address) = 
       "FILE://C:\\Ports\\ABC\\%MessageID%.xml" ;

• In the second branch for subscriber XYZ, we set the map to the map for XYZ and change the public key.

  tMap = System.Type.GetType("DynamicMaps.Map_XYZ, 
           DynamicMaps, Version=1.0.0.0, Culture=neutral, 
           PublicKeyToken=f85be9e4dd36fb1d");

• Now we need to construct the message like ABC's. Alternately, you can construct the message in the Expression Shape directly, but you would need to add the construct keyword.

  construct Message_Out
  {
      transform (Message_Out) = tMap(Generic_In);
      Dynamic_Send(Microsoft.XLANGs.BaseTypes.Address) = 
              "FILE://C:\\Ports\\XYZ\\%MessageID%.xml" ;
  }

• Add a Send port which sends out a message of type System.Xml, and use that to send the transformed file to your desired destination.
• Compile and deploy the project.

Note: In essence, what we have done in the step above is to use the reflection feature in .NET and find the type of the Map. Then we use the variable and invoke the transformation by using the BizTalk internal keyword transform. BizTalk does all the hard work of loading the assembly dynamically for our use and unloading the assembly later, and all that plumbing that you otherwise need to write. Don't you love BizTalk now?

Step 5: Testing and Output

You can drop the two test files and you will get two different outputs for the same file based on changing the subscriber.

I have the inputs and outputs as below:

• Input file for party ABC

  

• Output for party ABC

  

• Input file for party XYZ

  

• Output for party XYZ

  

Step 8: A few notes on the output

The output is self explanatory, and you will notice that for identical inputs except for the party name, the output was different based on the maps used. We used a Time functoid to generate the time, and the other values came from fixed strings. And last but not the least, I confess, I am not 22 as the example file indicates or misleads, way older than that! My wife was quick to point that one out.

Points of Interest

Although in this example we have used a simple Decide shape to figure out which map to load, in real life implementations, this could be a database helper class which returns the name of the map assembly from a SQL database or a similar design. This design is useful since you can add more maps and systems even after the original system has gone live. This is possible because you can add a new subscriber into the database and have a new DLL with the corresponding schema and maps. This provides a loose-coupling which is highly desired in these scenarios.

Gotcha's

In the declaration of the variable tMap, I could not get it to be defined as System.Type from the dropdown. I had to open the .odx file in Notepad and set it manually after choosing a random type initially.

Exceptions

A very common exception would be:

Error in accessing the part data or one of its fragments. 
The part or fragment may not exist in the database.

When this happens, make sure you have both the assemblies deployed and they are present in the GAC. Also check that the ports are created and the Receive port uses an XML transmit pipeline and the Send port uses a pass-through transmit pipeline.

BizTalk Server—SOA implementation

The value of implementing BizTalk Server with SOA is apparent when you consider how one might achieve the development and operational benefits specified previously. To begin with, we can examine the inefficiencies of the development process and the ways in which BizTalk Server addresses them.

Traditional programming methodologies do not adequately translate the conceptual model of an application or business process (that is, a design specification) into an executable form. While development notation systems such as UML allow a business analyst to document functional specifications and Use Cases using a structured methodology, a programmer still has to interpret this documentation and translate its intent into a different language and structure. This manual and highly interpretive conversion process is characterized by its inefficiencies—most notably its recursive revision cycles. After the business processes have been accurately translated into procedural code, another issue typically presents itself: the behavior of the code is less predictable than the behavior of the business process it models. This volatility results from the nature of procedural code implementations. Bound to a machine execution model, procedural code is an opaque embodiment of processes that encapsulate multiple levels of tightly coupled, interdependent functionality. Consequently, procedural code is prone to program errors that are often difficult and time-consuming to identify and repair. Understandably, then, when software is operationally stable, subsequent modifications are discouraged—often to the point of requiring modifications to business processes just to accommodate the limitations of the rigid code.

A BPM/EAI development environment allows the business analyst and the programmer to collaborate in a common workspace on a visual model of the process that combines and correlates their respective contributions. The programmer and analyst create the application by arranging high-level objects representing messages, messaging events, business rules and logic, information flows, activities, operations, transformations, and subprocesses, using a drag-and-drop graphical user interface. The model itself directly generates an executable run-time assembly of the process. This methodology provides significant development efficiencies and life cycle flexibility by minimizing the ambiguities and recursive revision cycles inherent in traditional methodologies. Furthermore, the implementation mechanisms for highly complex functions, such as transactions requiring two-phase commit, roll-back ACID transaction support, and nested and parallel operations, are built in functions of the objects; thus, eliminating the need to write complicated procedural code to implement these capabilities.

To better illustrate the SOA development methodology the following steps describe the procedure for creating an application in BizTalk Server that adheres to this paradigm:

1.	Create the documents involved in the application/process as well as their respective schema definitions. This is accomplished in the Schema Editor, a BizTalk Server module accessed from within Visual Studio .NET. The Schema Editor enables you to define the structure and semantic metadata that “declares” the meaning, functions, and processing requirements of the content of a document (an “instance”) that is created from the schema. When BizTalk Server receives an instance of a document, the process to which the document is associated validates the document content against its schema definition to ensure the document’s form and content conform to the schema and the application’s processing requirements. BizTalk Server Schema Editor creates a W3C-compliant XSD document as well as a visual tree node reference model of the schema. Following is an example of the Schema Editor that shows the tree node model of the schema in the left panel and the XML representation of the document schema in the right panel.
2.	Create and define the transformation requirements for any document interchanges. In applications that are composed of loosely coupled interactions between XML objects, document transformation becomes a functionally exposed mapping subprocess. In BizTalk Server this subprocess is created in BizTalk Server Mapper. The transformation maps are used to process and convert the content and structure of any source information (based on its schema representation) into any target document format, such as a report. BizTalk Server Mapper visually displays the source and destination information formats using the schema tree node model used by BizTalk Schema Editor. Information is mapped from one or more nodes in a source schema to one or more nodes in the destination schema by drawing links between the nodes. Functoids, which provide additional conversion, processing, and abstraction capabilities (looping, cumulative, date and time, iteration, and so forth), are graphically implemented by linking one or more source nodes to a functoid, and then linking the functoid to one or more destination nodes. Each transformation map (as well as the referenced source and target schemas) becomes a BizTalk Server project resource that is subsequently embedded into an orchestration as a process step and compiled into the orchestration assembly. Maps can be reused and modified as needed to implement any number of transformation requirements and they be deployed within any number of orchestrations. The maps created by BizTalk Server Mapper are based on XSLT, an open standards protocol for transforming XML information.
3.	Specify the business logic governing event execution. If the business logic is simple, it can be embedded as an expression directly within a BizTalk Server orchestration decision step. If the business logic is complex, the BizTalk Server Rules Composer can be used to create and process the sophisticated rule sets. Each rule set (or “Policy”) drives a specific activity or function and becomes a resource object embedded into a BizTalk Server orchestration. Consistent with the overall BizTalk Server architecture, transparency and loose coupling govern the creation and implementation of business rules. A rule set incorporated within a BizTalk Server orchestration can be viewed, modified, or completely replaced both at design and run time, without affecting any other process operation or interrupting running instances of the affected process. The flexibility that an exposed and componentized rule engine provides for modifying business processes is of fundamental significance. In conventional application development, business rule logic is embedded in procedural code and is not accessible for modification without changing the code itself. Because most modifications to a business process life cycle pertain to changes in business rules (as opposed to technology-related modifications), the ability to isolate business rules entirely from procedural code, or any process implementation mechanisms, dramatically improves the efficiencies of managing and adapting business processes throughout their life cycle. BizTalk Server Rules Composer supports the creation of domain-specific vocabularies for defining business rules, and its functionality is exposed through public interfaces, making it extremely flexible and extensible. The following is an illustration of the BizTalk Server Rules Composer module.
4.	Determine and implement requirements for message preprocessing and post-processing. This is accomplished in the BizTalk Server Pipeline Designer module. Accessed through the BizTalk Server orchestration workspace, the Pipeline Designer module is used to implement the interchange requirements for encryption, authentication, and data format conversion with external applications and parties. A pipeline is a sequence of processing operations that take place before a message is received by, or dispatched from a process orchestration or message data store. A “receive pipeline” accepts an incoming message, decrypts or decompresses it as required, disassembles the message into its parts, converts it into an XML document as specified in the BizTalk Server Schema, validates the message, and authenticates the identity of its sender. When a message passes through a pipeline, it is transferred to the BizTalk Server MessageBox store. A “send pipeline” performs the same operations as the “receive pipeline,” but in reverse. It assembles, formats, encrypts, compresses, and digitally signs a message as required by the external recipient.
5.	Compose and orchestrate the application/process steps. This takes place in BizTalk Server Orchestration Designer, the main workspace within Visual Studio .NET where an overall BizTalk Server application is developed and implemented. A process orchestration diagram is created by dragging and dropping object shapes found on the Orchestration Toolbox and linking them together. These shapes represent process activities such as receive, invoke, sequence, flow, link, and source. These shapes are used to compose and execute message flows, messaging events, business rules, activities, operations, transformations, and subprocesses. The following figure illustrates a BizTalk Server orchestration diagram that implements the following workflow process steps: • The process application (a BizTalk Server orchestration) receives an inventory order replenishment request (“Request’). • The process application checks the quantity of items ordered. If the order contains more than 500 items, it is denied. If the order contains 500 or fewer items, it is accepted. • If the order is declined, a notification is created (“ReqDenied”) and sent to the person who placed the order. • If the order is accepted, the original order request is submitted to an ERP system for processing. See full-sized image Composing the illustrated process diagram involved dragging and dropping the following shapes from the Toolbox and then modifying them: • Placed a Receive shape at the top of the design surface and named it Receive_Req. • Placed a Decision shape directly beneath the Receive Shape and named it CheckQuantity. The Decision shape automatically creates two activity branch shapes (If or Else) The If shape is renamed Decline. The Decline shape is linked to an expression editor in which the XPATH expression “RequestInstance.Item.Quantity > 500” is created. This XPATH expression will function as the “If” rule that specifies the denial criteria for the order request. • Placed a Construct Message shape below the Decline shape and named it Construct_ReqDenied. • Placed a Transform shape within the Construct_ReqDenied shape. • Placed a Send shape below the Construct_ReqDenied shape and named it Send_ReqDenied. • Placed a Send shape below the Else shape and named it Send_REQToERP.
6.	Link the design shapes to implementation objects. When the process steps are diagrammed, the next step involves linking the shapes to the objects required to implement the process. The objects may include the actual message documents, port locations where the messages are sent and received, and transport mechanisms required to move the messages. This linking stage is also performed in the Orchestration Designer. In the sample orchestration diagram, when a running process receives an instance of a Request document (note the Receive shape that initiates the process), the process will validate the document’s content against its schema definition to ensure the document’s form and content conform to the schema and the application’s processing requirements. If the Request document does not conform, the Transform subprocess embedded in the Construct Message process references an XSLT transformation map that converts the Request document to a ReqDenied document, as described in the second step.
7.	Where applicable, define parties and their respective roles and link to orchestration functions. This is accomplished in BizTalk Server Explorer, a tool that provides configuration information for the orchestrations and external components that make up a specific BizTalk Server project. Organized in a hierarchical tree structure, Explorer is used to configure the relationships and interactions of the project orchestrations to other project components such as roles, parties, send and receive ports, and receive locations. After all the logical steps are implemented in an orchestration diagram, a Visual Studio .NET run-time assembly (DLL file) is generated from a “build” of the orchestration diagram. This assembly may be implemented as an application on its own, or included as a component of a larger BizTalk Server solution. A BizTalk Server solution (a process application) includes one or more Visual Studio .NET projects that contain BizTalk Server components such as schemas, orchestrations, transformation maps, and pipelines. From the example discussed earlier, the schemas for the Request and ReqDenied documents and the transformation map are combined in a discrete BizTalk Server project that builds a compiled assembly. The BizTalk Server orchestration diagram that details the process workflow is also a discrete BizTalk Server project within the same solution. By referencing (encapsulating) the schema and map assembly, the diagram can incorporate the schemas and map as functional objects. All of the BizTalk Server project assemblies for a solution are then deployed and installed as an executable application under the management of the BizTalk Server run-time engine.

SOA—Underlying Technologies

Having discussed how an application is developed and implemented using the high-level tools within BizTalk Server 2004, we can now relate this development methodology to the underlying technologies that facilitate the Service Oriented Architecture (SOA) paradigm. As noted earlier, the fundamental principles of SOA are exposed functionality, document messaging, loose coupling, and platform independence.

XML provides the transparency and application independence and uses metatags to “declare” the meaning and function of data. The premise of XML is to convert program-dependent data into self-describing, program-independent data. This applies not only to content, but also to instructions for processing the content.

XML Schema provides semantic consistency and interoperability. XML Schema is a specification that formally defines an extensive array of data type primitives and structural components for creating XML documents; it serves as a dictionary of abstract elements, attribute entities, and organizational rules. Creating XML documents that conform to a schema “dictionary” has a significant advantage: the meaning, function and use of a document’s content is comprehensible to, and operable by, any XML-enabled application that can access the document’s underlying schema. Every industry-specific initiative to develop a common vocabulary and set of procedures for the exchange and processing of information is based on XML Schema. In fact, the XML Schema even serves as the basis for Web services protocols.

The Web services protocols, Simple Object Access Protocol (SOAP), and Web Services Definition Language (WSDL) provide the capabilities and messaging facilities required to bind and execute programmatic functionality anywhere, on any platform, without the need for custom code. The significance of the Web services specifications is that they provide the first truly workable architecture for building complex, interoperable computing processes over the Internet.

SOAP is an XML-based messaging protocol used to encode documents for transporting over a network. A “SOAP client” inserts an XML document into a SOAP envelope and posts it using HTTP (referred to as marshalling) to a “SOAP listener” that accepts the delivery. SOAP messaging has a number of benefits:

•	The SOAP client and listener applications are simple constructs. A SOAP client can be easily embedded as a routine in any program or Web page, and the URL endpoint can serve as the SOAP listener.
•	By using HTTP as its transport mechanism, a SOAP message can go anywhere, use existing SSL facilities for authentication and encryption, and make the most of the infrastructure scale of the World Wide Web.
•	Everything in the message, the SOAP envelope, the message header, and the body is expressed in XML, thus making the whole object entirely transparent. Because the semantics and structure of the documents are fully exposed, extensive validation, manipulation, routing, and transformation functions can be applied to the documents without writing application code to do so. Unlike CORBA, a Web services network endpoint (an HTTP, URL, or other address) can support multiple XML formats, providing a real polymorphic interface that will not break down with new versions.
•	Because HTTP is one of the transport mechanisms used by SOAP, a Web Service method call can be made to and from any Web-enabled computer anywhere in the world. Consequently SOAP has the potential to construct distributed computing processes on the same massive scale as the World Wide Web.

Web Services Definition Language (WSDL) is a specification for describing, communicating, and invoking programmatic functionality through a message exchange or remote procedure call—both of which use the SOAP protocol and XML encapsulated information. A WSDL document resides at a URL location and is linked to the actual program module located elsewhere. Almost any programmatic function within an orchestration, or accessed from an orchestration, can be exposed as a Web service: a database look-up, the invocation of a complex business rule, or the entire orchestration process itself. Because the public Web services interfaces are not dependent on the private implementation of the program, it is easy to construct applications that are highly modular and distributed.

The Business Process Execution Language (BPEL) is a vendor-neutral mechanism for describing the behavior of business processes. Originally created by Microsoft, IBM, and others, the latest version of this technology is currently being standardized by a larger group working through OASIS. The goal of this short paper is to explain the value of BPEL and to briefly describe how Microsoft supports BPEL in Microsoft® BizTalk® Server 2004.

BPEL is focused on describing business processes as interactions among web services. Consider a business process spread across multiple execution environments. In this example, the process runs partially on BizTalk Server 2004 and partially on an integration server from another vendor running on Windows or some other platform. The figure below illustrates how BPEL can be used to describe the interaction between the two implementations.

As the figure shows, a BPEL definition can be used first to formalize the public interactions between the two parties participating in this business process, then to generate a baseline implementation of those interactions. Two implementations are generated in this scenario, one targeting BizTalk Server 2004 and a second targeting the other integration server. Each contains the behavior for the system’s appropriate role in the business process. BizTalk Server 2004 might execute the buying half of the process, for example, while the other integration server executes the selling half. The role of BPEL is to define the web service interactions involved in this process. The focus is on the information exchange that must take place to successfully carry out the process.

This example of a business process split between two integration servers illustrates BPEL’s primary value: facilitating interchange[1] of web services-based business processes. While BPEL doesn’t define a complete business process, it does provide a vendor-neutral way to describe interactions of the process with external web services and complementary processes implemented across multiple systems.

Along with the example just described, there are several other scenarios where BPEL can be useful. They include the following:

n        A large organization such as a retailer or manufacturer might wish to specify the process its suppliers must implement to sell to it. This kind of hub-and-spoke arrangement, common in business-to-business (B2B) interactions, can be made easier using BPEL. The large buyer at the hub might use BPEL to describe the business process that its suppliers must implement, then distribute this definition to those suppliers. The BPEL definition precisely specifies the required interactions with the hub organization, and so each supplier can use it as a starting point for implementing its side of the process.

n        An organization might wish to implement an internal business process that relies on several existing applications, but allow this process to be deployed on any of several different integration servers. To allow this kind of enterprise application integration (EAI), the organization could define the basics of the process in BPEL, then use that common definition as a starting point for implementing the process on servers from one or more vendors.

n        Libraries of best-practice business processes can be created, allowing intellectual property to be captured and reused more effectively. For organizations building a process from scratch, standard BPEL solutions like these can be a useful starting point.

n        An industry-specific standards organization could provide BPEL templates to its members to help ensure industry-wide support for agreements on how to conduct electronic business. 

Microsoft’s support for BPEL is consistent with the other web services standards efforts in which the company participates. All of these standards, including SOAP, the Web Services Description Language (WSDL), and the various WS-* specifications such as WS-Security, are focused on building a common integration fabric across vendor boundaries. None of them, including BPEL, defines an execution environment for implementing applications that use these standards. Instead, this choice is left up to each vendor. For Microsoft, of course, the execution environment is the .NET Framework.    

One way to understand BPEL’s usefulness is to view this business process language in much the same light as WSDL. WSDL is useful because it defines an abstract interface to concrete implementations, exposing only what’s necessary for these implementations to interoperate. One implementation might be built in C# on the .NET Framework, while another might be built in Java on a J2EE-based platform, yet interoperability is possible using WSDL and a standard protocol such as SOAP. Similarly, BPEL is useful because it allows an abstract definition of a business process that can be implemented using the .NET Framework, a J2EE-based platform, or something else. By specifying the web services-based interactions the process requires, BPEL effectively aggregates a business process around multiple WSDL endpoints. It makes interworking possible at the business process level rather than just the level of individual web services.

The value of BPEL is based on two fundamental attributes of the technology. First, because BPEL makes no assumptions about the environment in which a business process will execute the technology is completely platform-neutral. The second fundamental attribute that makes BPEL valuable is the language’s complete focus on process-oriented abstractions. Rather than mix these higher-level concerns with the more detailed constructs found in traditional programming languages such as C# and Java, BPEL allows a clean separation between defining the business process itself and implementing the finer-grained business objects (probably written in C#, Java, or a similar language) that this process invokes.

Once these core attributes are clear, it’s obvious why BPEL does not—and should not—provide language bindings for directly invoking .NET or Java objects. Doing this would destroy BPEL’s value by eliminating both of the attributes just described: the language would no longer be platform-neutral, and it would also no longer allow a clean separation between the higher-level abstractions of process modeling and the low-level details of implementing business objects. In fact, BPEL’s creators deliberately omitted these kinds of implementation-oriented capabilities, focusing instead on coordinating service-level interactions using interchangeable XML. While a BPEL definition can specify a business process’s interactions with services and other processes, it provides only a starting point for fully implementing that process.

The truth is that the name “Business Process Execution Language” is something of a misnomer, since BPEL’s primary value lies more in the interactions it defines than in its execution capabilities. Implementations of business processes depend on capabilities that are specific to a particular execution environment. Because of this, implementing complete business processes in a truly portable way is not one of BPEL’s goals. Even if a vendor claims to provide a “BPEL execution engine”, the reality is that proprietary platform-specific extensions are necessary to support full implementation of business processes. Even process implementations created for these BPEL-based systems are not easily portable to other execution environments. 

With the release of BizTalk Server 2004, Microsoft is the first platform vendor to support BPEL in an integration server product. In this new version, customers can import a standard BPEL definition that defines the public aspects of a business process, then use the full power of the BizTalk Server 2004 execution environment built on the .NET Framework to implement and run that process. Similarly, customers can define the web service interaction aspects of their business process in the product’s Orchestration Designer, using just the features found in the BPEL specification, then export this process to standard BPEL. Microsoft adds no proprietary extensions to BPEL.  

Given its role as an interchange technology, BPEL will be far more useful when other vendors also support it. In the short run, the initial adoption of BPEL will be slow until these implementations are completed.  Yet because of its broad industry backing, other vendors will support the language in the near future. Once this occurs, BPEL is likely to play an important role in implementing business processes that span multiple execution environments.

he potential of the service-oriented enterprise is huge. Service-oriented architecture (SOA) will simplify the building, managing, and maintaining of distributed systems, in part because the technologies you will use to build these new systems are standards-based, thanks to the collaborative efforts of companies like IBM BEA, and Microsoft. Working together has enabled them to establish many Web services specifications, including WS-Security, WS-Addressing, and WS-Policy.

In this article I will focus on one Web services specification that is critical, yet has been largely overlooked: the Business Process Execution Language for Web Services (BPEL4WS, or BPEL).

I will describe why BPEL is important and what it offers you if you are implementing Web services today or planning to in the future. I'll also present concrete examples using BizTalk^® Server 2004. I'll discuss the various advantages of BPEL throughout the article, but for a quick look at some of the most important ones, see the sidebar "Benefits of BPEL." For background on all the great benefits of SOA, take a look at Aaron Skonnard's Service Station column in the February issue of MSDN^®Magazine.

From Object-Orientation to Service-Orientation

With the ability to easily integrate with and invoke Web services comes the problem of the coordination and management of messages as they are routed from service to service. As time passes, it will become increasingly unlikely that any interesting business processes will execute in a single message exchange. Traditionally, implementing business logic meant writing code (C++ or C#, for example). With BizTalk Server, however, many common requirements can be realized without coding a single line. It seems reasonable to code manually when dealing with a few services, but this becomes more problematic as the number and complexity of services increases. Enter BPEL—the first step towards abstracting the collaboration and sequencing logic out of platform-dependent code and into a formal process definition based on XML, WSDL, and XML Schema.

Successful SOA implementations require reusable logic and service autonomy. In order to achieve them, you need to start thinking of applications as the collaboration of message exchanges. Of course, when you begin exposing application functionality as services, you relinquish a certain amount of control because you no longer know how your services are being employed or even who is using them. I'll take a look at how you can come to grips with that fact later on in this article.

If I were to describe business orchestration in musical terms, the orchestra would be made up of Web services, BPEL would be the sheet music, and the composer would be the coordinator or business process manager (BPM). Designing an application architecture that fits this description using ubiquitous standards in such a way that the specifications themselves do not intrude on the process is the great challenge in Web services today. BizTalk Server is the solution to that problem. Let's look at how BizTalk Server uses Web services, BPEL, and Web Services Enhancements (WSE) as parts of a BPM solution.

The New Lingua Franca

As I mentioned, BPEL is one of a number of technologies that provides a rich Web services infrastructure. Each of the specifications (some still waiting for vendor implementations and consequently widespread adoption) addresses a different area of concern. BPEL was submitted to OASIS last year, where it is currently undergoing finalization (see www.oasis-open.org). However, you can take advantage of a growing number of major specifications right now in your orchestrations and Web services by using WSE and BizTalk Server in tandem.

BPEL gives Web services architects the kind of flexibility that the open database connectivity standard (ODBC) gave database architects. That standard enabled uniform data access regardless of the actual database used. BPEL also enables a process to be defined in one environment and executed in another. Another advantage is that it clarifies business processes and enables the designers of the business processes to define the orchestrations themselves (more on this shortly).

There are a couple of different methods by which the BPEL specification can be implemented. For example, you could run the BPEL through an interpreter the way a scripting language is executed, or you could convert or compile it into a more efficient format prior to execution.

BizTalk Server takes the second approach and realizes a number of benefits from doing so. BizTalk Server enables the import of BPEL 1.1-compliant processes and converts them to XLANG/s, the Microsoft process definition language. XLANG/s has been supported in all previous versions of BizTalk Server, thus it provides important backward compatibility. XLANG/s also provides many of the common facilities required to implement processes such as mapping, conversion, and transformation functions. Currently the BPEL standard only allows such functionality to be exposed as additional services. This can incur performance overhead without runtime optimization.

BizTalk Server goes even further than merely converting to XLANG/s by actually compiling the converted XLANG/s into .NET assemblies prior to execution, resulting in a five-fold performance improvement over the previous version of BizTalk Server.

Perhaps the main reason BPEL has received less attention than other specifications is that most vendors (including Microsoft) do not expect it to be created the same way you create WSDL or XSD—using an XML editor. Instead, tooling in BizTalk Server provides a rich graphical process editor to create orchestrations—the Orchestration Designer.

Support for interoperability in BizTalk Server enables BPEL documents to be imported and turned into orchestration (.odx) files. An orchestration can then be viewed and edited graphically in the designer and even exported back to BPEL if required. This allows companies or business units to share a business process quickly and easily, even if they run on completely different hardware and operating systems. This can make enterprises much more agile, particularly where changing a process could result in taking advantage of a brand new market opportunity.

By focusing on interoperability, BizTalk Server embraces BPEL without being constrained by it. Consider, for example, that the major processing requirement in messaging systems is transformation—the conversion from one format or structure to another. BPEL can't do this in the standard, but BizTalk Server can.

To give you an idea of what's going on behind the scenes, take a look at the code in Figure 1. It's important to bear in mind that BPEL is a substrate that binds pre-existing Web services together and is not intended to be used to implement the services themselves. This is one of the reasons that the feature set in BPEL is constrained to simple expressions and constructs. BPEL allows you to form new Web services through recombination and enables the assembly of complex business processes.

A BPEL definition generally requires two other document types, WSDL and XML schema, and BizTalk Server orchestrations are no exception to this. Figure 2 shows the relationship between them. BPEL extends WSDL to both provide and consume Web services in an abstract way. This enables one of the great strengths of WSDL, namely the ability to separate the abstract message and port information required at composition time from the physical binding and address details required at invocation time. The WSDL and XSD for this example are given in Figure 3 and Figure 4.

A cursory examination of the BPEL vocabulary in Figure 1 reveals many familiar concepts such as scoped variables and type-compatible assignments. BPEL also provides logical constructs such as conditionals, loops, and parallel processing. The BPEL in Figure 1 needs little explanation. The basic constructs are termed activities in BPEL, the full list for which is provided in Figure 5. Because of the flexibility an XML-based representation provides, activities can be combined and nested in interesting ways. This process is particularly suited to a graphical design environment.

Many BPEL features relate to timing and synchronization. The loosely coupled, highly latent world of Web services requires a much more casual attitude to sequence and time than do regular applications. To see what I mean, think about how an orchestration runs. Waiting for a message is a passive activity and something in the orchestration will almost certainly have to wait for the appropriate message to appear. BizTalk Server deals with messages by implementing subscriptions. An orchestration can subscribe to a particular message type, and all messages received go into a persistent store called the message box, implemented using SQL Server^™. The message box is examined and the subscribed orchestrations are executed by the runtime. This results in orchestration instances being created, each running with its own state. This is important for reasons I'll discuss shortly.

The next activity I want to discuss is the invoke activity. It enables an orchestration to call a Web service to help fulfill the implementation of the process. This functionality is present in BizTalk Server with the Send and Receive shapes. In the example in Figure 1, I am simply invoking a Web service that will add two numbers and return the sum. The expected WSDL definitions are referenced to provide the necessary binding and context. This case is a little contrived, but it does illustrate the ability to decouple externally exposed services from changes to internally defined services.

For example, this internal service could be replaced with another one or the schema changed to alter the message structure without affecting the caller in any way. Such encapsulation is important in order to achieve reuse of existing services as components of a larger orchestration. A public Web service for a bank that enables the transfer of funds between accounts will consist of internal invocation and collaboration of a number of different systems internally. Exposing these internal systems APIs to the outside world often leads to brittleness and can be highly insecure.

Instead, an orchestration can be used to provide a facade to bridge the outside world and your internal systems in a loosely coupled way. This is a common requirement in enterprise application integration (EAI) scenarios and typically employs content-based routing. Bear in mind that orchestrations in BizTalk Server do not have to be exposed as Web services. They can be run by a variety of means using different configurations. An orchestration's trigger may be an XML document dropped via FTP into a watched file system folder, for example.

It should be apparent by now that a messaging system has a large number of requirements that are not directly related to the execution of any one particular service. Because these requirements cut across all services, they are driving the creation of BPM software infrastructure. BizTalk Server is both a BPM and integration product. It consists of around 1.8 million lines of managed code. This gives a good indication of the size of a BPM application—you don't want to start writing one yourself.

If you're going to build business processes using existing services, you need to have those services in place first. But that's not the reality for most companies today, so it's critical to make your services generic and reusable, rather than services targeted to a particular consumer. Adopting an interface-first design approach makes this much easier to achieve.

The visibility of the actual running business processes represents a huge step forward and with BizTalk Server you can create a new process by linking together available "shapes" in the graphical editor. These shapes map naturally to BPEL activities already described and allow a process to be modeled by dragging and dropping these activities onto the designer surface. Developers can do this using Visual Studio^® .NET 2003, and business analysts can use Visio^® to design orchestrations. As you can see in Figure 6, the receive shape (labeled ReceiveMessage) is synonymous with the BPEL Receive activity. Similarly, the send shape (labeled ReplyMessage) maps to the Reply activity in BPEL. The goal is that each type of user has the best tools for their own familiar environment yet they share the same artifacts.

Now let's consider a more complex scenario. One of the assumptions made explicit with distributed service-based systems is that they will occasionally fail. By their nature, timeouts can occur due to network latency or the endpoint being unavailable, for example. Messages may not be delivered, may be delivered multiple times, or may be delivered in an unexpected order. These characteristics make transactions problematic as the traditional approach of using atomicity to guarantee consistency and isolation through a two-phase commit scheme (such as that provided by the Microsoft Distributed Transaction Coordinator, or MS DTC) cannot be employed. With the WS-Transaction specification there will be a comparable solution, but even then there are many cases when transactions spanning organizational boundaries are not appropriate. A different approach taken in BPEL is based on the notion of compensation.

Compensation enables long-running transactions (LRTs) to be managed so that if failure occurs, a defined compensatory action will be invoked. One example is an airline reservation system. In booking a ticket, you may have to provide payment before your seat on the flight can be confirmed. This process could take several seconds. If the seat cannot be confirmed, the payment must be refunded so that it appears that the transaction never took place. LRTs are the mechanism by which Web services can achieve this state. Because of this, the term LRT is somewhat of a misnomer as it isn't really a transaction at all. Each action and compensatory action taken is distinct from the others. BizTalk Server implements this scheme and logically ties this unrelated activity coordination together to manage it and attempt to prevent inconsistencies. Note, though, that this is not a fail-safe mechanism because it does not preclude the possibility that inconsistencies could occur. It is also important to realize that this is not a failing of BizTalk Server itself; rather it is due to the pragmatic approach taken in dealing with failures within a loosely coupled distributed system.

Another problem Web services introduce is the lack of shared knowledge or state. This should be viewed as a strength because it reduces any dependency or unnecessary knowledge by one component of another. It does, however, require a different approach to solving a perennial problem. For example, an LRT may consist of a fire-and-forget style of asynchronous message being sent. It may be expected, though, that at some point in the future the service to which the message was directed will respond in a callback-style pattern or "solicit-response." When this occurs, the original orchestration must correlate the inbound message with the original outbound one. BPEL provides support for this with correlation sets. Correlation sets in BizTalk Server are based on the notion of specific process instances, as I mentioned earlier.

You must mark an orchestration in BizTalk Server as able to be activated in order to indicate that it can be the start of a new process instantiation. From that point on, if an activity is executed that causes the orchestration to suspend execution, it can be resumed later when the callback comes in. BizTalk Server supports this BPEL feature by allowing the receipt of a message and correlating it back to the original in-flight suspended orchestration instance. As the callback message is likely to differ from the original one that initiated the orchestration, BizTalk Server also provides the facility to alias correlation information. This allows unique data items to be identified across different message types in order for the BizTalk Server engine to associate them. This is achieved through property promotion, that is, the process of annotating the schema type being used with the relationships between different elements or complex types with the same meaning.

For example, a customer ID may be present in all messages but is unique to a particular customer. Because of this uniqueness property, it can be used to correlate different messages to a single orchestration instance even though in one message type it may be called CustID while in another message type, it may refer to the same entity called Customer.

BPEL contains other examples of synchronization activities all supported in BizTalk Server. One of the more interesting is the pick activity, which BizTalk Server provides via the Listen shape (see Figure 5). This activity allows the selection of a logic path based on the message type received. An orchestration that can receive one of several different messages can use this activity to wait until the first message is received and continue down a particular path based on its type. This is useful when you are dealing with a number of partners using different message structures but the semantics of the actual business process being created are the same for each.

Boundaries

As I've said, BPEL should be viewed purely as an orchestration language, and this is where the interoperability benefits lie. Because of this, BPEL imposes some restrictions on the expressions allowed in conditional activities and assignments. In order to discourage its use in implementing the actual business logic of a service the specification actually mandates that only simple expressions are allowed. This is because its stated purpose is to control the execution of the business logic components, namely the Web services.

Consequently, a BPEL orchestration cannot accomplish much by itself. A BPEL orchestration cannot actually implement a business process. Instead, it acts as a coordinator by passing messages from system to system, employing other services along the way. The orchestration only knows how to call, consume, and manage the calling of the other Web services and nothing more. BPEL is also just a specification, not a product.

For it to be useful, it has to exist as an implementation on a specific platform and that means implementation-specific code will be written to integrate with and extend it. This is likely to change as the specification process continues on to recommendation status, with the possibility that concessions will be made to provide for some of the common requirements in a standard, interoperable way. These current limitations make it possible to define orchestrations in BizTalk Server that cannot be expressed in BPEL. Although this is unavoidable, the extensibility BPEL allows will likely lead to greater improvements in this area over the next few years, and in particular, will lead to greater interoperability.

 

E' il primo maggio la data fissata da Microsoft per il rilascio di BizTalk Server 2006, la prima major release dal marzo 2004 della piattaforma di BPM (Business Process Management) che punta a facilitare le operazioni di integrazione in modo tale che gli utenti possano effettivamente focalizzarsi sulla gestione dei processi di business. Steven Martin, director of product management per BizTalk, ha spiegato a questo proposito che: “Rendere estremamente semplice l'integrazione di basso livello ha consentito ai clienti di passare più tempo a parlare dei processi di business end-to-end... Ora la maggioranza dei clienti che licenziano il prodotto lo stanno utilizzando per indirizzare le problematiche di gestione dei processi di business, che abbracciano applicazioni o processi totalmente nuovi, erogati attraverso applicazioni composite”. BizTalk Server 2006 supporterà SQL Server 2005, Visual Studio 2005 e Virtual Server 2005, e sarà disponibile in una versione a 64 bit.

Per gli amministratori, ha continuato Martin, BizTalk 2006 include una nuova console di gestione unificata progettata per fornire una vista su un processo di business in una singola finestra. Lato sviluppatori, il nuovo rilascio include invece uno strumento per consentire l'aggregazione di parti di un processo in modo tale da poterlo mettere in produzione come singola applicazione. Gli utenti, infine, avranno la possibilità di monitorare l'attività di business con la realizzazione di un portale per misurare le prestazioni dei processi rispetto a indicatori predefiniti.

Nel pacchetto Microsoft ha inoltre deciso di includere 12 adattatori (tra i quali quelli per le applicazioni J.D. Edwards, Oracle e PeopleSoft) come parte del costo di licenza base anziché richiedere agli utenti di comprarli a parte.

To customize BTARN to connect to Elemica, you must follow these steps:

• Install BTARN Hotfixes
  
  
• Edit the process configuration
  
  
• Edit agreements
  
  
• Download project files
  
  
• Update Microsoft.Solutions.BTARN.RNIFReceive.dll
  
  
• Update Microsoft.Solutions.BTARN.RNIFSend.dll and set the BTARN configuration for client certificates
  
  

The changes to Microsoft.Solutions.BTARN.RNIFReceive.dll and Microsoft.Solutions.BTARN.RNIFSend.dll have been made in the RNIFReceive.csproj and RNIFSend.csproj project files that are part of the WebApplication.zip. You can download these projects from http://go.microsoft.com/fwlink/?LinkId=46195. Use these projects as is instead of creating them from scratch.

This document describes the above steps in detail.

Install BTARN Hotfixes

Edit the Process Configuration

Edit Agreements

Download the Project Files

Update Microsoft.Solutions.BTARN.RNIFReceive.dll

Enable Client Certificate Authentication in BTARN

Update the Microsoft.Solutions.BTARN.RNIFSend.dll and Set the BTARN Configuration for Client Certificates

Microsoft BizTalk Server 2004 offers development tools for designing and implementing business processes as orchestrations. Once you've implemented a BizTalk orchestration, you can publish the orchestration as a Web service through the built-in Web Services Publishing Wizard. The wizard generates an ASP.NET Web services (ASMX) endpoint based on the schema types used in the orchestration. Then consumers can query the generated ASMX endpoint to retrieve the Web Services Description Language (WSDL) definition representing the orchestration's service contract. Once the WSDL contract is accessible, any Web services-enabled consumer can integrate with the orchestration.

This general development process assumes that the service contract is typically an orchestration byproduct defined by the BizTalk Server developer. The reverse scenario, however, is also important—where a pre-existing service contract (in the form of a WSDL definition) must be implemented and adhered to by a new BizTalk orchestration. This article discusses some of the issues surrounding BizTalk Server's support for Web services, while providing helpful guidance and some practical techniques for implementing existing WSDL contracts in your BizTalk orchestrations.

BizTalk Server Messaging Basics

Service Contracts and Collaboration

Mapping Orchestrations to Services

BizTalk Server Web Services Publishing Wizard

BizTalk Server WSE Web Services Publishing Wizard

BizTalk Server BPEL Import Wizard

Implementing a Conforming Web Services Layer

Where Are We?

RosettaNet is a non-profit organization whose goal is to standardize on open e-business processes for document interchange. The organization consists of the world's leading information technology (IT), electronic components (EC), semiconductor manufacturing (SM), and solution provider (SP) companies. XML is used as the core technology to provide a common medium of business-to-business communication between organizations, departments, and trading partners.

Microsoft BizTalk Server 2004 helps companies efficiently and effectively integrate systems, employees, and trading partners through manageable business processes, enabling them to automate and orchestrate interactions in a highly flexible and highly automated manner.

Microsoft BizTalk Accelerator for RosettaNet (BTARN) 3.0 combines prebuilt support for all current RosettaNet Partner Interface Processes (PIPs) with a suite of development, testing, management, and rapid deployment tools to significantly reduce the time and resources required to build, deploy, and manage RosettaNet-based integration with trading partners.

The Microsoft BizTalk Adapter v2.0 for mySAP Business Suite provides the means to enumerate all IDoc, BAPI, and RFC calls (including customized IDocs) and allows the user to select multiple IDocs, BAPIs, and RFCs for each adapter instance. It also provides the means to enumerate IDoc, BAPI, and RFC schemas and convert these schemas into BizTalk Server 2004-compatible XSD schemas.

BizTalk Server 2004, along with BTARN, provides a business process platform for implementing the RosettaNet standard and includes the capability to integrate messages between companies from various industries who are involved in using heterogeneous back-end systems. The PIPs are XML-based RosettaNet document specifications (or schemas) that are used as a core to mapping messages between a RosettaNet document and other system formats such as those used by SAP and Siebel systems.

Throughout this document, we use a RosettaNet 3A4 Purchase Order Request document and an SAP ORDERS05 IDoc. BizTalk Server is used to integrate and map between these two formats. This sample extends the capability of the Microsoft BizTalk Server 2004 solution and provides an example of message exchanges by integrating RosettaNet transactions interfacing with the SAP systems using Microsoft BizTalk Accelerator for RosettaNet 3.0 and the Microsoft BizTalk Adapter v2.0 for mySAP Business Suite.

RosettaNet Partner Interface Processes

Microsoft BizTalk Adapter v2.0 for mySAP Business Suite

SAP ORDERS05 IDoc Schema

RosettaNet Purchase Order Request (3A4) Schema

Mapping the RosettaNet 3A4 Schema to the ORDERS05 Schema

Microsoft BizTalk Accelerator for RosettaNet 3.0

Overall Architecture

PIP 3A4_ORDERS05 Orchestration

Web Client Interface

SAP Transactions

Introduction

Automating and maintaining business processes in a dynamic and cost-effective manner has proven to be a difficult endeavor for even the most technically sophisticated organizations. However, a new application development and integration methodology has evolved that effectively addresses these issues. Known as Service Oriented Architecture (SOA), the methodology is based on XML and Web services technologies and has been incorporated into Business Process Management and Enterprise Application Integration (BPM/EAI) platforms.

The SOA paradigm has redefined the concept of an application. An application is no longer an opaque, procedural implementation mechanism. Instead, it is an orchestrated sequence of messaging, routing, processing, and transformation events capable of processing the exposed declarative properties of rich (XML) documents.

A workflow process, integration scenario, or trading partner interaction are specialized classes of the SOA paradigm distinguished only by the nature of the participants involved, the point of execution, and the participants’ individual security requirements. BPM/EAI platforms that incorporate the SOA paradigm are highly compelling because they provide numerous development and operational benefits:

•	They alleviate significant development inefficiencies and impediments to effective life cycle maintenance.
•	They facilitate the flexible “loose coupling” of components on a highly distributed basis.
•	They permit the addition, removal, and reconfiguration of any process activity or component without disrupting the process.
•	They are fundamentally oriented to supporting long-running, asynchronous transactions that scale well.
•	They ensure the applications are well documented and visible because the process activities, components, and functions are exposed and self-describing.
•	They enable the extensibility and reuse of both application components and entire applications.
•	They maximize the network infrastructure of the Internet and the protocol standards of the World Wide Web.

Approaching a development environment based on the SOA paradigm does require a reorientation in the concepts and methodologies of application development. In this document we describe the fundamental SOA concepts and development methodologies. We then explore how the Microsoft® EAI development environment, BizTalk® Server 2004, implements these concepts and methodologies within two particular contexts: the design, behavior, and functionality of the applications that are created; and the development process itself. Finally the document describes how the BizTalk Server development tools, which are integrated with Visual Studio® .NET, provide a bridge between the .NET framework architecture and the SOA paradigm.

BizTalk Server—SOA implementation

The value of implementing BizTalk Server with SOA is apparent when you consider how one might achieve the development and operational benefits specified previously. To begin with, we can examine the inefficiencies of the development process and the ways in which BizTalk Server addresses them.

Traditional programming methodologies do not adequately translate the conceptual model of an application or business process (that is, a design specification) into an executable form. While development notation systems such as UML allow a business analyst to document functional specifications and Use Cases using a structured methodology, a programmer still has to interpret this documentation and translate its intent into a different language and structure. This manual and highly interpretive conversion process is characterized by its inefficiencies—most notably its recursive revision cycles. After the business processes have been accurately translated into procedural code, another issue typically presents itself: the behavior of the code is less predictable than the behavior of the business process it models. This volatility results from the nature of procedural code implementations. Bound to a machine execution model, procedural code is an opaque embodiment of processes that encapsulate multiple levels of tightly coupled, interdependent functionality. Consequently, procedural code is prone to program errors that are often difficult and time-consuming to identify and repair. Understandably, then, when software is operationally stable, subsequent modifications are discouraged—often to the point of requiring modifications to business processes just to accommodate the limitations of the rigid code.

A BPM/EAI development environment allows the business analyst and the programmer to collaborate in a common workspace on a visual model of the process that combines and correlates their respective contributions. The programmer and analyst create the application by arranging high-level objects representing messages, messaging events, business rules and logic, information flows, activities, operations, transformations, and subprocesses, using a drag-and-drop graphical user interface. The model itself directly generates an executable run-time assembly of the process. This methodology provides significant development efficiencies and life cycle flexibility by minimizing the ambiguities and recursive revision cycles inherent in traditional methodologies. Furthermore, the implementation mechanisms for highly complex functions, such as transactions requiring two-phase commit, roll-back ACID transaction support, and nested and parallel operations, are built in functions of the objects; thus, eliminating the need to write complicated procedural code to implement these capabilities.

To better illustrate the SOA development methodology the following steps describe the procedure for creating an application in BizTalk Server that adheres to this paradigm:

1.	Create the documents involved in the application/process as well as their respective schema definitions. This is accomplished in the Schema Editor, a BizTalk Server module accessed from within Visual Studio .NET. The Schema Editor enables you to define the structure and semantic metadata that “declares” the meaning, functions, and processing requirements of the content of a document (an “instance”) that is created from the schema. When BizTalk Server receives an instance of a document, the process to which the document is associated validates the document content against its schema definition to ensure the document’s form and content conform to the schema and the application’s processing requirements. BizTalk Server Schema Editor creates a W3C-compliant XSD document as well as a visual tree node reference model of the schema. Following is an example of the Schema Editor that shows the tree node model of the schema in the left panel and the XML representation of the document schema in the right panel.
2.	Create and define the transformation requirements for any document interchanges. In applications that are composed of loosely coupled interactions between XML objects, document transformation becomes a functionally exposed mapping subprocess. In BizTalk Server this subprocess is created in BizTalk Server Mapper. The transformation maps are used to process and convert the content and structure of any source information (based on its schema representation) into any target document format, such as a report. BizTalk Server Mapper visually displays the source and destination information formats using the schema tree node model used by BizTalk Schema Editor. Information is mapped from one or more nodes in a source schema to one or more nodes in the destination schema by drawing links between the nodes. Functoids, which provide additional conversion, processing, and abstraction capabilities (looping, cumulative, date and time, iteration, and so forth), are graphically implemented by linking one or more source nodes to a functoid, and then linking the functoid to one or more destination nodes. Each transformation map (as well as the referenced source and target schemas) becomes a BizTalk Server project resource that is subsequently embedded into an orchestration as a process step and compiled into the orchestration assembly. Maps can be reused and modified as needed to implement any number of transformation requirements and they be deployed within any number of orchestrations. The maps created by BizTalk Server Mapper are based on XSLT, an open standards protocol for transforming XML information.
3.	Specify the business logic governing event execution. If the business logic is simple, it can be embedded as an expression directly within a BizTalk Server orchestration decision step. If the business logic is complex, the BizTalk Server Rules Composer can be used to create and process the sophisticated rule sets. Each rule set (or “Policy”) drives a specific activity or function and becomes a resource object embedded into a BizTalk Server orchestration. Consistent with the overall BizTalk Server architecture, transparency and loose coupling govern the creation and implementation of business rules. A rule set incorporated within a BizTalk Server orchestration can be viewed, modified, or completely replaced both at design and run time, without affecting any other process operation or interrupting running instances of the affected process. The flexibility that an exposed and componentized rule engine provides for modifying business processes is of fundamental significance. In conventional application development, business rule logic is embedded in procedural code and is not accessible for modification without changing the code itself. Because most modifications to a business process life cycle pertain to changes in business rules (as opposed to technology-related modifications), the ability to isolate business rules entirely from procedural code, or any process implementation mechanisms, dramatically improves the efficiencies of managing and adapting business processes throughout their life cycle. BizTalk Server Rules Composer supports the creation of domain-specific vocabularies for defining business rules, and its functionality is exposed through public interfaces, making it extremely flexible and extensible. The following is an illustration of the BizTalk Server Rules Composer module.
4.	Determine and implement requirements for message preprocessing and post-processing. This is accomplished in the BizTalk Server Pipeline Designer module. Accessed through the BizTalk Server orchestration workspace, the Pipeline Designer module is used to implement the interchange requirements for encryption, authentication, and data format conversion with external applications and parties. A pipeline is a sequence of processing operations that take place before a message is received by, or dispatched from a process orchestration or message data store. A “receive pipeline” accepts an incoming message, decrypts or decompresses it as required, disassembles the message into its parts, converts it into an XML document as specified in the BizTalk Server Schema, validates the message, and authenticates the identity of its sender. When a message passes through a pipeline, it is transferred to the BizTalk Server MessageBox store. A “send pipeline” performs the same operations as the “receive pipeline,” but in reverse. It assembles, formats, encrypts, compresses, and digitally signs a message as required by the external recipient.
5.	Compose and orchestrate the application/process steps. This takes place in BizTalk Server Orchestration Designer, the main workspace within Visual Studio .NET where an overall BizTalk Server application is developed and implemented. A process orchestration diagram is created by dragging and dropping object shapes found on the Orchestration Toolbox and linking them together. These shapes represent process activities such as receive, invoke, sequence, flow, link, and source. These shapes are used to compose and execute message flows, messaging events, business rules, activities, operations, transformations, and subprocesses. The following figure illustrates a BizTalk Server orchestration diagram that implements the following workflow process steps: • The process application (a BizTalk Server orchestration) receives an inventory order replenishment request (“Request’). • The process application checks the quantity of items ordered. If the order contains more than 500 items, it is denied. If the order contains 500 or fewer items, it is accepted. • If the order is declined, a notification is created (“ReqDenied”) and sent to the person who placed the order. • If the order is accepted, the original order request is submitted to an ERP system for processing. See full-sized image Composing the illustrated process diagram involved dragging and dropping the following shapes from the Toolbox and then modifying them: • Placed a Receive shape at the top of the design surface and named it Receive_Req. • Placed a Decision shape directly beneath the Receive Shape and named it CheckQuantity. The Decision shape automatically creates two activity branch shapes (If or Else) The If shape is renamed Decline. The Decline shape is linked to an expression editor in which the XPATH expression “RequestInstance.Item.Quantity > 500” is created. This XPATH expression will function as the “If” rule that specifies the denial criteria for the order request. • Placed a Construct Message shape below the Decline shape and named it Construct_ReqDenied. • Placed a Transform shape within the Construct_ReqDenied shape. • Placed a Send shape below the Construct_ReqDenied shape and named it Send_ReqDenied. • Placed a Send shape below the Else shape and named it Send_REQToERP.
6.	Link the design shapes to implementation objects. When the process steps are diagrammed, the next step involves linking the shapes to the objects required to implement the process. The objects may include the actual message documents, port locations where the messages are sent and received, and transport mechanisms required to move the messages. This linking stage is also performed in the Orchestration Designer. In the sample orchestration diagram, when a running process receives an instance of a Request document (note the Receive shape that initiates the process), the process will validate the document’s content against its schema definition to ensure the document’s form and content conform to the schema and the application’s processing requirements. If the Request document does not conform, the Transform subprocess embedded in the Construct Message process references an XSLT transformation map that converts the Request document to a ReqDenied document, as described in the second step.
7.	Where applicable, define parties and their respective roles and link to orchestration functions. This is accomplished in BizTalk Server Explorer, a tool that provides configuration information for the orchestrations and external components that make up a specific BizTalk Server project. Organized in a hierarchical tree structure, Explorer is used to configure the relationships and interactions of the project orchestrations to other project components such as roles, parties, send and receive ports, and receive locations. After all the logical steps are implemented in an orchestration diagram, a Visual Studio .NET run-time assembly (DLL file) is generated from a “build” of the orchestration diagram. This assembly may be implemented as an application on its own, or included as a component of a larger BizTalk Server solution. A BizTalk Server solution (a process application) includes one or more Visual Studio .NET projects that contain BizTalk Server components such as schemas, orchestrations, transformation maps, and pipelines. From the example discussed earlier, the schemas for the Request and ReqDenied documents and the transformation map are combined in a discrete BizTalk Server project that builds a compiled assembly. The BizTalk Server orchestration diagram that details the process workflow is also a discrete BizTalk Server project within the same solution. By referencing (encapsulating) the schema and map assembly, the diagram can incorporate the schemas and map as functional objects. All of the BizTalk Server project assemblies for a solution are then deployed and installed as an executable application under the management of the BizTalk Server run-time engine.

SOA—Underlying Technologies

Having discussed how an application is developed and implemented using the high-level tools within BizTalk Server 2004, we can now relate this development methodology to the underlying technologies that facilitate the Service Oriented Architecture (SOA) paradigm. As noted earlier, the fundamental principles of SOA are exposed functionality, document messaging, loose coupling, and platform independence.

XML provides the transparency and application independence and uses metatags to “declare” the meaning and function of data. The premise of XML is to convert program-dependent data into self-describing, program-independent data. This applies not only to content, but also to instructions for processing the content.

XML Schema provides semantic consistency and interoperability. XML Schema is a specification that formally defines an extensive array of data type primitives and structural components for creating XML documents; it serves as a dictionary of abstract elements, attribute entities, and organizational rules. Creating XML documents that conform to a schema “dictionary” has a significant advantage: the meaning, function and use of a document’s content is comprehensible to, and operable by, any XML-enabled application that can access the document’s underlying schema. Every industry-specific initiative to develop a common vocabulary and set of procedures for the exchange and processing of information is based on XML Schema. In fact, the XML Schema even serves as the basis for Web services protocols.

The Web services protocols, Simple Object Access Protocol (SOAP), and Web Services Definition Language (WSDL) provide the capabilities and messaging facilities required to bind and execute programmatic functionality anywhere, on any platform, without the need for custom code. The significance of the Web services specifications is that they provide the first truly workable architecture for building complex, interoperable computing processes over the Internet.

SOAP is an XML-based messaging protocol used to encode documents for transporting over a network. A “SOAP client” inserts an XML document into a SOAP envelope and posts it using HTTP (referred to as marshalling) to a “SOAP listener” that accepts the delivery. SOAP messaging has a number of benefits:

•	The SOAP client and listener applications are simple constructs. A SOAP client can be easily embedded as a routine in any program or Web page, and the URL endpoint can serve as the SOAP listener.
•	By using HTTP as its transport mechanism, a SOAP message can go anywhere, use existing SSL facilities for authentication and encryption, and make the most of the infrastructure scale of the World Wide Web.
•	Everything in the message, the SOAP envelope, the message header, and the body is expressed in XML, thus making the whole object entirely transparent. Because the semantics and structure of the documents are fully exposed, extensive validation, manipulation, routing, and transformation functions can be applied to the documents without writing application code to do so. Unlike CORBA, a Web services network endpoint (an HTTP, URL, or other address) can support multiple XML formats, providing a real polymorphic interface that will not break down with new versions.
•	Because HTTP is one of the transport mechanisms used by SOAP, a Web Service method call can be made to and from any Web-enabled computer anywhere in the world. Consequently SOAP has the potential to construct distributed computing processes on the same massive scale as the World Wide Web.

Web Services Definition Language (WSDL) is a specification for describing, communicating, and invoking programmatic functionality through a message exchange or remote procedure call—both of which use the SOAP protocol and XML encapsulated information. A WSDL document resides at a URL location and is linked to the actual program module located elsewhere. Almost any programmatic function within an orchestration, or accessed from an orchestration, can be exposed as a Web service: a database look-up, the invocation of a complex business rule, or the entire orchestration process itself. Because the public Web services interfaces are not dependent on the private implementation of the program, it is easy to construct applications that are highly modular and distributed.

Conclusion

The Business Rule Framework within BizTalk Server represents an innovative implementation of the Service Oriented Architecture (SOA) paradigm. Every individual and combined level of functionality has been designed to be exposed, independent, and capable of being loosely coupled. Any policy component (vocabulary or rule set) can be viewed or changed at any time, without affecting any other process operation or running instance of the affected process. Furthermore, policies are compiled into Visual Studio .NET assemblies directly from their semantic and declarative XML definitions, thus eliminating the need for any procedural implementation programming. The substantial development and life cycle efficiencies that this individual capability engenders are validation of the Service Oriented Architecture paradigm.

The flexibility that an exposed and componentized rule engine provides for modifying business processes is significant. In conventional application development, business rule logic is embedded in procedural code and cannot be modified without changing the code itself. And code changes, which consume both time and resources, often result in unpredictable program behavior. Clearly the ability to isolate business rules entirely from procedural code, or any process implementation mechanisms, dramatically improves the efficiencies of managing and adapting business processes in response to new requirements or business conditions.

The development process within Orchestration Designer is, in itself, a lesson in exposed functionality and loose coupling. By providing developers with the ability to visualize complex business logic and its respective implementation mechanisms, the Orchestration Designer makes software development more manageable and less abstract. Each logical process step is coupled to a discrete implementation mechanism that contains self-documenting methods. Functionally transparent and isolated, each object property within the solution (orchestrations, schemas, maps, and so forth) is accessible from the host Visual Studio .NET environment or directly through its XML representation. Furthermore, the completed orchestration can generate a Business Process Execution Language (BPEL) document of the entire process.

Because a BPEL instruction set is an XML representation of a process with a precise language and grammar structure, it provides a readable and understandable instruction set for documenting a process. The value of this cannot be overstated; historically, poor documentation prevented software and processes from being readily modified and adapted. In fact, the process shapes in Orchestration Designer symbolize basic and structured BPEL elements such as receive, invoke, sequence, flow, role, link, and source. A process developed in BizTalk Server Orchestration Designer can be exported as a BPEL document and be imported into any other BPEL-compliant application. Conversely, a BPEL document can be imported into BizTalk Server Orchestration Designer to generate an orchestration diagram. The standardized interchange of process instructions can potentially facilitate collaborative business process development between business partners.

The application of the SOA paradigm in BizTalk Server 2004 clearly illustrates how the value of XML functionality has accrued:

•	XML and XML Schema have enabled the creation of the Web services protocols SOAP and WSDL.
•	BPEL functions on top of the core Web services protocols and facilitates the inclusion of additional XML functionality (such as business rules or processing logic) within processes.
•	Each process is independently valuable, but when combined with other processes has the potential to facilitate wholesale efficiencies and provide innovative solutions to numerous challenging problems. It is an object lesson in the whole being greater than the sum of the parts.

Because BizTalk Server Orchestration Designer is embedded within Visual Studio .NET, it bridges two frameworks: SOA and .NET. The .NET framework consists of two main parts: the common language run time (CLR) and a unified set of class libraries. The class libraries include ASP.NET for Web applications and Web services, Windows Forms for smart client applications, and ADO.NET for loosely coupled data access. The .NET framework provides a highly productive, standards-based environment for integrating existing information technology investments with next-generation applications and services. When combined with the higher-level abstractions of XML functionality and the visual design facilities found in BizTalk Server, the result is a development and deployment environment that offers unprecedented capabilities and efficiencies. Furthermore, it provides a coherent way for developers to indoctrinate themselves in the SOA methodologies while leveraging their .NET expertise.

We are entering an era of computing where information will be detached from, and completely independent of applications but where the structure, composition and behavior of each will be fundamentally identical. Information will be generated and published without knowledge of how it will be consumed or used. Applications will both consume information and methods, and be consumed. Processes will be capable of configuring and modifying themselves. Entirely new applications, new business models and new ways in which information will define our experiences will evolve from the Service Oriented Architecture paradigm.

As with any paradigm shift, SOA must be justified by the benefits it provides. The evidence is clear. Those who have adopted the SOA development model have realized dramatic development efficiencies, accelerated return on investment, and increased resource availability. Although XML, Web services, and BPM/EAI platforms impose a new conceptual model on business process development, the technologies required to implement and deploy this model are established and proven Microsoft products that have been augmented to support this new paradigm.