perfectxml.com
 Basic Search  Advanced Search   
Topics Resources Free Library Software XML News About Us
  You are here: home »» Info Bank »» Articles » BizTalk Server 2000: An Overview Friday, 13 July 2007
 

Back to Articles Page      

        

TechMetrix BizTalk Server 2000: An Overview
 Reproduced with kind permission of TechMetrix Research External link
 Article written by: TechMetrix Research (info@techmetrix.com  E-mail )

  • Introduction
    This article presents Microsoft's BizTalk Server 2000. The range of tools covered by this label enables trading partners who wish to exchange documents (or more precisely, data) to integrate applications within B2B transactions.

    BizTalk Server 2000 is based on tried-and-tested Microsoft products (such as SQL Server) and on a number of exchange standards whose special features will be discussed in this article.

    We will begin by describing the functionalities of BizTalk Server 2000, and the technical building blocks that make up its foundation. We will then look at integration with BizTalk Server and how to best avail of this software platform.

  • BizTalk Server 2000, a Microsoft offering
    BizTalk Server 2000 is a tool used for the integration of partners' information systems. The B2B integration services offered by BizTalk Server 2000 are traditional:
    • Routing of data stream between partners
    • Interpretation and transformation of data formats
    • Tracking and protection of exchanges


    BizTalk Server 2000 uses simple rules to implement a multitude of mechanisms to achieve the above. The particularity of the product is that it is 100% Microsoft. It is based on the following software:
    • Microsoft Windows 2000, in its various versions
    • Microsoft Internet Information Services (IIS) with Microsoft Active Server Pages (ASP)
    • Microsoft SQL Server (7.0 or 2000). (Note that for SQL Server 7.0 the entire system must be updated)
    • Microsoft Visio 2000.


    Each software building block provides the mechanisms required for data exchange:
    • Support for HTTP, HTTPs, SMTP, EDIFACT protocols
    • Support for message services
    • Support for file exchange
    • Management of distributed transactions
    • XML transformation with a parser
    • Storage and archiving of messages
    • Graphical definition of exchanges
    • Administration of business services


    Figure 1 illustrates the software architecture used by BizTalk.

    BizTalk Server 2000 software architecture



  • The technical positioning of BizTalk
    A centralized solution
    Contrary to products such as WebMethods (a true EAI tool), a single instance of BizTalk Server is capable of managing all aspects of partner integration.

    In the case of WebMethods, each partner must have a specific software building block (WebMethods B2B Server or WebMethods B2B for Partners). The two blocks handle the transportation of data streams and communication with the respective underlying information systems.

    BizTalk Server is designed to centralize exchanges. It receives incoming streams from a system and redirects outgoing streams to one or several systems. For an enterprise that wishes to manage exchanges between partners (a virtual marketplace for example) BizTalk may be an advantage in that it can be implemented without imposing a specific software architecture on partners (we will see that a simple FTP service is sufficient).

    Figure 2: BizTalk Server centralizes exchanges



  • Connectivity with partners
    BizTalk Server is meant to be a completely open tool and, as a result, a number of protocols may be used to access its services:

    • FTP: data streams may be posted by FTP in the BizTalk server directories provided for this purpose. Analyzers are set up to monitor the activity of the directories and to react to file sending.
    • HTTP, HTTPs: the HTTP protocol, whether secure or not, is the most frequently used alternative for extranet-type Web integration between trading partners. Specific ASP pages are available on the BizTalk server (managed by IIS). Partners can invoke pages with the help of an MSXML type HTTP component and send any type of data stream to the BizTalk server. The ASP pages then trigger data processing.
    • DCOM: another option is to use DCOM, a protocol for managing Microsoft distributed objects. Each component of the BizTalk integration engine may be managed in the form of COM objects. From any application supporting the DCOM protocol, flows of data and communication channels may be created, receipt functions may be invoked, planned tasks may be launched, and so on.



    Partners can therefore choose their method for interfacing with BizTalk Server for exchanges. However, BizTalk Server has certain limits in terms of connectivity, even if the fact that it supports HTTP guarantees it high interoperability in its role as B2B platform.

    BizTalk Server services may be managed as long as they are based on the Microsoft-specific DCOM protocol. The product is closed and recalls the following rule: a Microsoft product communicates well with Microsoft products but has difficulties opening to the outside.

    Integration of partners' information systems is limited to receiving and posting data flows. Today, BizTalk Server does not provide the same level of connectivity as a WebMethods B2B Server with its adapters. Most B2B product vendors have strongly based their offering on adapters or business connectors which allow for a high level of integration with Information Systems (IS) whatever their nature. For example, BizTalk Server cannot invoke SAP BAPIs (calling functions for SAP business objects) or truly manage SAP.

    BizTalk Server aims to consolidate and stabilize B2B communication standards and Microsoft leaves it up to vendors to develop connectors. While waiting for the market to develop further, BizTalk Server accepts "handmade" connectors and offers basic tools for developing these.

    Integration with BizTalk Server 2000 Integration begins with the implementation of a large number of functional and technical rules. Using BizTalk Server as an integration platform involves setting up a precise process to allow the various stages of partner exchange to be observed. Such a process is called agreement and this agreement is divided into the following stages:

    • Receipt of data from partner (format 1)
    • Interpretation and validation
    • Transformation into BizTalk internal format
    • Archiving
    • Serialization to format 2
    • Routing to partner 2 (format 2)


  • Data Processing Workflow
    The status of data streams submitted to BizTalk Server changes as they are processed. BizTalk Server manages the queues of documents, which enables it to ensure reliable routing, processing of all messages and error management.

    These queues of documents take the form of tables in the database. When installing BizTalk Server, a database is created specifically for managing these queues. A machine may also be dedicated to this function.

    Figure 3, below, shows the different message queues and their relations.

    Figure 3: message queues managed by BizTalk Server



  • Defining an agreement
    An agreement defines all of the rules relating to exchange between trading partners. It also specifies the methods of data procurement. The defined rules will enable BizTalk Server to identify the partners involved, the means of transport chosen and the associated security rules.

    A typical list of rules in an agreement might be as follows:

    • All documents from partner 1 are stored in directory A on the server
    • The original format of these documents is EDIFACT
    • The 4th field represents the name of the partner that will receive the document
    • Documents sent to partner 2 use HTTP once 10 new documents arrive
    • The format of partner 2 is XML following the specific DTD ZZZ.


    The agreement in this example is relatively accurate in that it puts the two partners in contact. However, it is possible to define agreement rules that may be applied and generalized in various situations. These are referred to as integration channels.

  • Incoming data
    BizTalk accepts incoming data in any format. Its flexibility extends from the tabulated data to complex XML structures and standard specific formats such as IDOC (SAP) or EDIFACT (EDI). The first stage therefore involves analyzing the structure of incoming streams and defining a map. This is facilitated by the BizTalk Editor tool. This graphical tool enables document specifications to be created simply by positioning the fields and values. It also has a certain number of native business formats such as EDIFACT, IDOC. It also offers the possibility of improving knowledge by directly integrating XML schemas (DTD).

    Incoming data streams are automatically stored in the Schedule Queue.

  • Interpretation and validation
    Document specifications set up by analysts then enable the incoming data streams to be validated. Depending on the format specified for incoming data, BizTalk Server calls on the appropriate parser for document validation.

    If the document is not valid in relation to the specified format, it is stored in the Suspended Queue.

    If the document is valid it can be stored in the Work Queue. Firstly, BizTalk Server converts it into an internal format. This specific mechanism leads to information being added to the stream. More particularly, the document is accompanied by a header with technical information on transport, security and information concerning partners.

    If the stream is not processed immediately it will be stored in the Retry Queue and can be processed independently later. This avoids keeping links between documents and integration channels.

    The internal XML format adopted by BizTalk Server is BizTalk Framework. This non-standard — although based on SOAP (Simple Object Access Protocol) — format is the subject of a large number of projects and fully benefits from Microsoft's attempts to have it adopted in the world of e-business. What is more, BizTalk messages sent by HTTP use the SOAP message header where the required information is transported to the document routing all along the process chain.

    Resources: http://microsoft.com/technet/biztalk /btsdocs External link

  • Transformation and serialization
    Before data is finally routed to one or more partners it is transformed into the required format. The BizTalk Mapper defines complex transformation rules for transformation to and from all formats.

    These transformation rules are applied by implementing XML stylesheets (entirely transparent for the developer defining the rules). Certain sections of these stylesheets, called functoids, process particular transformations, specific to certain types of data (character string, real, dates…).

    One of the interesting aspects of BizTalk Mapper it that it accepts the addition of specific functoids. We can also imagine the possible integration of functions dealing with transformation of reference products from one format to another.

    The advantage of these functoids is that they can be reused. Several data maps can use the same functoids, which do not have to be redefined each time.

  • Prerequisites for BizTalk Server
    The range of tools provided by BizTalk Server 2000 presents Microsoft's B2B integration solution as a technical solution that is easy to implement and use. The definition of relations between partners is quick and intuitive. BizTalk Server is extremely efficient at setting up simple B2B relations.

    However, looking at the product in more detail, we realize that specific skills are required. In addition to the command of the concepts of the XML language and a sound knowledge of Web mechanisms, teams wishing to implement BizTalk Server 2000 must also understand the specific features of the Microsoft world. They must master the software on which BizTalk is based. They must also be familiar with COM and DCOM models and the use of distributed objects via ASP applications.

    In addition to mastering the technological aspects of the product, developers must be aware of the functional ins and outs of the BizTalk application they are creating. To create an application in BizTalk you must know the process logic and be able to identify the different players.

    Despite its undeniable attractiveness, BizTalk Server 2000 remains a Microsoft application and as a result has, and always will have, a positive psychological impact on some, while conjuring up more of an off-putting "black box" feeling for others.

  • How much?
    BizTalk Server licenses remain affordable compared with products such as WebMethods. What is more, a single license is all that is required to install a productive BizTalk Server. This license includes the BizTalk Server engine and all associated tools. But to fully avail of the product you must also buy Visio and SQL Server.

    It is also possible to choose between the two editions according to your integration requirements:
    • The Standard edition allows for the integration of 5 partners. It is only valid for an architecture based on one BizTalk single processor server. It costs $4999.

    • The Enterprise edition provides the support required for a limited number of partners. The architecture may be distributed over several BizTalk servers. It costs $24,999. Note, however, that this is the cost per processor. If we intend distributing over 4 servers (1 as the system point of entry and 3 for the effective processing of a large volume of data flow), the price increases to $100K which is close to WebMethods pricing.


TechMetrix BizTalk Server 2000: An Overview
 Reproduced with kind permission of TechMetrix Research External link
 Article written by: TechMetrix Research (info@techmetrix.com  E-mail )


  

Back to Articles Page      



  Contact Us | E-mail Us | Site Guide | About PerfectXML | Advertise ©2004 perfectxml.com. All rights reserved. | Privacy