Introduction to BizTalk Server

Introduction

BizTalk Server 2006 sets a standard in efficient business-process development and deployment by providing an internal architecture with deep integration between messaging and orchestration, as well as a scalable publish-and-subscribe messaging infrastructure. BizTalk Server 2006 unifies many services and development tools in a framework that provides a smooth design experience and a powerful environment for creating and executing business processes.

BizTalk tools and services

The following tools and services are included in BizTalk Server 2006:

· Messaging and orchestration. These services are used to transform, route, and send messages between business processes.

· Application development tools. You use various graphical tools to perform such tasks as creating, testing, and deploying schemas, maps, pipelines, and orchestrations.

· Business rules framework. You can use the business rules framework to seamlessly couple changing business policies and logic with complex business processes.

· Message activity tracking. The Health and Activity Tracking (HAT) tool is used to monitor and debug message activity and orchestrations.

· Web services integration. These services enable you to integrate Web services into a business process or to create a business process that can be published as a Web service.

· Business activity monitoring. You use these services to monitor real-time or archived business statistical data through end-to-end business processes.

· Business Activity Services. The Business Activity Services (BAS) enable you to manage trading partner data and relationships.

Services and Adapters

A service is a set of instructions in Gentran Integration Suite that the Integration Broker uses to perform an activity in a business process. Adapters are services that connect the Integration Broker and other system components to unlike systems and applications outside of the Gentran Integration Suite environment. Business processes can send, pause, retrieve, and fully interact with adapters. Services and adapters are reusable—you can include them in multiple business process models.

Integration Activities Performed by the Integration Broker

The Integration Broker performs integration activities, which are known as services.

Nearly any kind of activity can be a service in Gentran Integration Suite. All services
achieve some predefined type of integration activity. Examples of service activities
performed by the Integration Broker include:

✦ Communicating with external applications or middleware (using special services
called adapters)

✦ Performing data manipulations, such as translation, transformation, splitting, and
joining

✦ Routing data based on content or other criteria

✦ Publishing data to interested subscribers, which may trigger a new business process or
allow a running process to continue

✦ Execution of one or more B2B protocols

✦ Starting a business process

✦ Performing operations on SQL (Structured Query Language) database tables

✦ Enabling human interactions within an otherwise automated process


About Business Processes:-

The services that the Gentran Integration Suite Integration Broker runs are configured within defined business process models that you create and modify within the Gentran Integration Suite system.

A business process is a series of linked software (and possibly human) activities that accomplishes a business goal. The activities are called services, the modules of work that comprise business processes. The services must complete for the business process to run
successfully.

A business process model can be a simple linear configuration or contain one or more
decision points requiring human or system determination of the next steps in the process.


The high-level process for creating a business process model for Gentran Integration Suite
involves:

1. Analyzing your business needs

2. Determining which services, adapters, and components you must involve to
accomplish your goal

3. Configuring the services and adapters used in the business process
4. Testing the business process

Business Process Modeling Language

The Gentran Integration Suite Integration Broker runs business process models that have been created using Business Process Modeling Language (BPML). BPML is an XML-based language for describing business processes. It was developed by the Business Process Management Initiative (www.bpmi.org).

You can create business process models several different ways:

✦ Graphical Process Modeler (GPM)

✦ A simple text editor

✦ Any graphical editor that can export the XML format to Gentran Integration Suite

Unless you are proficient in the use of XML and BPML syntax, use the GPM to create your
business process models.
Business Process Flow

The Integration Broker automatically selects the appropriate business process model to run when data enters the system through an input adapter. When an input adapter receives data from an external system, the Integration Broker locates the appropriate business process or
processes to call, and starts the process or delivers the incoming data to the appropriate already-running process.

Following is an example of how the Integration Broker executes the steps in a business process as a document progresses through Gentran Integration Suite:

1. Gentran Integration Suite receives the business message or document through an adapter.

2. The Integration Broker determines which service to start next and starts the service, according to the content of the document.

3. The adapter places the message or document and other appropriate process state information on a queue for the appropriate service in the selected business process.

4. The appropriate service retrieves the initial business process state information from the queue and processes the next step in the business process.

5. Each service in the business process updates the business process state information, and records a copy of the related data or pointers to the data for process recoverability.

6. An adapter sends the modified business process state information, with the data, to a specific application.

Fundamental Components of Gentran Integration Suite

✦ Integration Broker

✦ Services and Adapters

✦ Graphical Process Modeler

✦ Mapping and Data Transformation Components

Setting up EDI

Setting up EDI :-


Although electronic mail is faster than standard mail and eliminates paper, it differs greatly from EDI because the data is in an unstructured format. If you were to get a purchase order as an e-mail, you would likely print out the document and enter the data into another program, such as an accounting or inventory package.

• Getting the implementation guide

Whether you use a service based solution or in-house software, you will need to format the data to your trading partner's specifications. The formatting process, called mapping is usually a part of the technical support service offered by your software provider, and the guidelines for mapping are in your trading partner's implementation guide.
Often the implementation guide contains a trading partner questionnaire, which needs to be filled out and returned as soon as possible. This is the first step in establishing a trading partner relationship.
Please note that even though all of your trading partners may be using X12 standards, EDI guidelines are not universal. The map created for Company A's invoice cannot be copied and used for Company B, as Company B likely has its own criteria. As a result, you will need an implementation guide for every trading partner.

• Setting up communications

One of the most important aspects of EDI is selecting how the data is going to get from one place to the other, such as through a VAN or using a direct communication. In the majority of the cases the trading partner will designate the method.

VAN (Value Added Network)

Often referred to as the "electronic post office", a VAN is a third party service that transmits and stores data in the "electronic mailbox" until it is picked up by the appropriate party. Since the EDI message contains addressing information, the van routes the message to the mailbox of the recipient. Until recently, it was considered the most secure method of transferring data.

Direct Connection

Unlike the VAN, a direct connection allows you to pass the data straight to the receiving party.
Types of direct connection include VPN (Virtual Private Network), FTP (File Transfer Protocol), and EDIINT (EDI over the Internet). Usually EDIINT is done in conjunction with AS2 software, which encrypts the data before sending it over the Internet.

• Installing the software

There are two parts to EDI: the translator and the mapper. Installing each part is simple and takes seconds. However, each piece of software must be customized to fit your specific needs.
Translator

The translator is the engine behind the EDI process and governs the day-to-day activity. It has several components, including the engine itself, the EDI maps, the standards, and communications ability.

Mapping tool

Data is formatted using the mapper, a software tool that enables one to properly organize the data so that it follows both the EDI and the trading partner's standards. Maps contain the rules of the transaction; these rules will be enacted by the translator itself. Mapping also includes integration with an existing application. The EDI translator can be programmed to go into an application, extract information, and send it out as an EDI file. It can also import incoming data, thus eliminating the need for data entry. As said earlier, the mapping design is often done as part of the EDI supplier's technical support service.

• Final steps in the set-up process

The trading partner will send sample data, which is then mapped following the guidelines. The completed map is tested by sending sample data (which is now formatted) back to the trading partner. If it fails, the mapping error must be found and corrected. Upon successful testing the EDI partnership is ready to go live.

What is HL7

HL7 is a standard for health’s clinical and administrative data. One of objective of this standard is to develop a coherent, extendible standard that permit structured, encoded health care information of the type required to support patient care, to be exchanged between computer applications while preserving meaning.

How a HL7 Message looks like

MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930||ORU^R01|CNTRL-3456|P|2.4
PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F|||153 FERNWOOD DR.^^STATESVILLE^OH^35292||(206)3345232|(206)752-121||||AC555444444||67-A4335^OH^20030520
OBR|1|845439^GHH OE|1045813^GHH LAB|15545^GLUCOSE|||200202150730|||||||||555-55-5555^PRIMARY^PATRICIA P^^^^MD^^|||||||||F||||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MD
OBX|1|SN|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||F
Yes… Looks strange at first sight… but believe me, it is perfectly logic.

Dissecting the message
An HL7 message consists of the following data elements.

Message type

An HL7 message type is a unique identifier for the business purpose of a message. Every message must contain a message type id as way to announce the purpose of the message. For example, ADT is a unique message ID to Patient Administration.
However, it is rather not a unique classification on the structure of a message. One message type can have more than one message structure.
The message type is advertised in the message header segment

Message event

The message event, sometimes called a trigger, is a unique identifier to the context in which message is generated. The message event consists of an upper case letter and two digits. For example, A01 is for admission/visit notification and A61 is for changing consulting doctor. Both A01 and A61 are used with ADT messages
Event type is advertised in the message header segment.

Message structure

The message structure is a data structure used to express an association of a message type with an event for a class of messages. Each message structure also contains a unique ID.
It structurally consists of a well-defined list of HL7 segments. Segments can be optional, and can repeat. There is no limit on how many times a segment can repeat.
Segments can be aggregated together to form a segment group, which can repeat as well. In the standard specification, segment group is indicated by {} or [], where {} signifies repetition and [] signifies optionality.
Relative position of segments in a message structure and segment groups is well defined. At the message structure level, segment is the atomic data type.

Relationship between X12 and EDIFACT

The current requirement for business to operate in an international marketplace has resulted in efforts to merge the X12 standard with the EDIFACT standard. As the book and serials industry, particularly publishers of scientific and technical materials, do business internationally, they are active in the initiative to develop international EDI standards. While the formats supported by these standards are similar in structure, there are significant differences that will need to be resolved.

As the ANSI X12 standards were already in use when work began to develop the EDIFACT standards, the format and structure of X12 messages were a useful model. As a result, X12 and EDIFACT messages share common structural characteristics:

• character-based encoding, with multiple levels of support for various encoding standards, e.g. telex, 7-bit ASCII
• tagged and delimited data structures
• a global set of data segments and a segment directory to define them.
• a global set of data elements and a data element directory to define them.
• a message of a predefined type consisting of a specific sequence of segments.
• implicit identification of data elements in a segment by location.
• an "interchange" consisting of either "functional groups" each of which contains one or more messages or one or more messages by themselves.

However, given that the existing European standards (UN/TDI) were also considered when developing the EDIFACT formats and structures, there are some differences between the two standards (Woods, 1989):

• EDIFACT uses composite data elements
• looping and nesting procedures are different
• 6 data elements types are defined in ANSI X12 while only three are defined in EDIFACT
• there is no provision in EDIFACT for optional fields
• EDIFACT allows for two levels of syntax.

The differences between the two standards are considered to be minor by the X12/North American EDIFACT secretariat. There is very little difference between the two syntaxes in the overall design of the transaction set/message.