BizTalk AS2 EDI

This article will briefly discuss about the AS2 & EDI support in BizTalk 2010.

Unlike the earlier versions, BizTalk 2010 has extensive native support for EDI message processing & also AS2 protocol support.

BizTalk 2010 introduces new concepts for Trading Partner Management (TPM) such as Partner profiles & Agreements. We would now be able to define the trading partners involved in the B2B process as Parties in BizTalk with separate business profile created for each party.Seperate Agreements could be created for different protocols such as EDI(X12/EDIFACT)/AS2  between two different parties .

The reason behind Business profile is, to have different profiles created for different units/teams within the same Party, so that different units/teams within the same parties can have different agreements defined on different protocols.

For example Company A has 2 business profiles created for Sales & Marketing units.

Let’s say, Company A – Sales unit connects with Company B - Sales unit using AS2 /X12 and Company A – Marketing unit connects with Company B - Marketing unit using AS2/ EDIFACT, then there will be separate Agreements created for each business profile.

Now , we know the terminologies of TPM such as Parties, Business Profiles, Agreement, Message Protocols (EDIFACT, X12) & communication protocol AS2.Its time to see the steps involved in creating & configuring a basic TPM solution between 2 parties (Let’s say Company A & Company B).

1.     Decide the message protocol .I am going with X12 for this article. But, there are only few differences between X12 & EDIFACT.

2.     Decide & list the type of transactions & documents between the parties. BizTalk provides schemas for almost all of the transaction types. I will go ahead with X12 04010 856, which is the shipment notice schema.

3.     Decide the format of transactions (XML, EDI).This will make a difference in choosing the right Pipeline in the send/receive ports. The default pipelines available for AS2 processing are AS2Send/AS2EdiSend & AS2Receive/AS2EdiReceive respectively for XML and EDI.If you want to generate the message in edi format then we should use AS2EdiSend, otherwise it will be AS2Send.

4.     Define the mapping rules for the EDI transactions. This step is very important and complicated during the entire process, as we should have the mapping implemented properly in BizTalk to generate the EDI message, as desired.

5.     Create & configure TPM (Parties, Business Profiles & Agreements).Parties and business profiles will be created for CompanyA & CompanyB .Separate agreements will be created for AS2 & X12 .The AS2 agreement will have configuration settings to specify whether the messages needs to be signed/encrypted/compressed, whether to request for MDN and also to associate the send port, which will be used to send the message to CompanyB. Based on the settings for signing & encryption, certificates should be configured at send port level.

6.     Once all above are done, we can create & deploy the BizTalk artefacts needed for the entire process.

This might include

-         Creating internal shipment schema for CompanyA

-         Adding the existing X12 04010 856 schema provided by BizTalk.

-         Create mapping between the two schemas.

-         Create orchestration, if it is necessary. Otherwise, the mapping can be configured in the send port.

-         Create & configure the necessary physical receive & send ports.

-         Build & deploy the project.

So, briefly, CompanyA creates internal shipment notice which matches its internal schema & the same is mapped against X12 04010 856 schema. The generated EDI message is validated, assembled & encoded by the AS2EdiSend pipeline and delivered to the CompanyB‘s HTTP/HTTPS url configured in the send port. The AS2 specific message context is included from the Agreement defined between the 2 parties. The Agreement also helps in specifying the Transaction set validation rules, character set and separators and so on.

If we need to receive an MDN back from the CompanyB, for the X12 04010 856 message sent, we can configure the same in the Agreement and with the help of 2-way send port, the MDN can be received in BizTalk.

Hope this article helps to understand the basis of AS2/EDI processing with BizTalk 2010 & the high level steps involved in implementing a solution. Thanks for reading & Good Luck!!!

My Initial reading(All I know so far) on WCF-SQL Adapter with BizTalk 2010

In this article, I am going to briefly describe about the various benefits of using the new WCF-SQL Adapter, released as part of the BizTalk Adapter Pack 2010.

I have been working on SQL Adapter with the BizTalk 2004/2006 versions & all I used to use is generating the SQL schema from the stored procedures for the DML operations (SELECT, INSERT, UPDATE & DELETE) .I have been hit with few issues during my personal experience with SQL Adapter. Few of them,

·         The schema generated using SQL adapter is not very flexible.Means, I can’t promote or distinguish fields. Factors include, the adapter generates them as either attributes or record nodes. I need to tweak the schema manually, to convert them into elements & then I can either promote or distinguish.

I am not going to compare the SQL Adapter with WCF-SQL, just for the above mentioned issues.

But I am going to describe the features & benefits of WCF-SQL over SQL Adapter.

WCF-SQL Adapter Features

·         SQL Server DB can be exposed as WCF service to external clients – exchange of SOAP messages for request-response.

·         Support for performing DML operations directly on to the SQL tables. The schema generated will have the same number of fields as the table & u have the option to generate separate schema for separate DML operation. These schemas make it very simple and easier for mapping SQL to/from other message formats.

·         Support for strongly typed stored procedure. In the SQL Adapter, the stored procedure should return the result set as XML AUTO, XMLDATA .otherwise, we will have pain in generating the schema. With WCF-SQL adapter, we can generate schemas from stored procedures without FOR XML. Also, the schema generated will have the list of fields which are returned in the result set. For example,

Select ID, NAME, DESC, AMNT from Table where ID = @ID, inside the stored procedure.

Then, the schema generated will have the fields as ID, NAME, DESC, AMNT.This is lot more easily not to do mapping & message construction within BizTalk orchestration.

Also, we can generate schema with <Any> field instead of the specific field names. This is the difference between strongly typed stored procedures & stored procedures.

·         WCF-SQL adapter also provides backward support for the stored procedure with FOR XML AUTO.

·          The CLR type ADO.NET functions like ExecuteNonQuery, ExecuteReader & ExecuteScalar are also supported by WCF-SQL adapter. These functions become useful for situations like INSERT, UPDATE, and DELETE where you won’t expect any result set back, but an integer return value & if you want to return single value from SQL (value from 1^st row 1^st column).Another advantage of using these functions is, executing multiple SQL statements.

·         Composite operations – means we can execute related set of operations together on different database tables (SELECT is not supported). This means you can perform separate insert & delete operations together with the composite message. All we need to do is to construct a composite schema with all the operation schemas referenced.

WCF-SQL adapter is not just whatever I have listed above. It has much more feature sets & options for developers such as polling based on specific conditions, SQL-WCF adapter using WCF-Service & channel model and so on. The Binding for the WCF-SQL adapter is been made easy (binding file generated along with the schema), which can be imported to configure physical send/receive ports.

I will try to cover up and advanced version of this article, with elaborating more on the WCF-SQL adapter, with some hands on samples. Thanks for reading & happy Biztalking!!!