XML and related standards for data warehouses   Table of contents   Indexes   How XML Enables Internet Trading Communities and Marketplaces
 Fairfax 
Gauthier, Jay
 USA 
webMethods, Inc.
 		Jay Gauthier
 Senior Software Engineer
webMethods, Inc.
 3877 Fairfax Ridge Road, 4th Floor Fairfax (Virginia)  USA (22030)
Email: mailto:Jgauthier@webmethods.com Web site:http://www.webmethods.com
 Biography
 Jay Gauthier is a veteran software developer with over fifteen years experience in creating commercial software. He is an avid student of programming languages, object-oriented programming and design patterns and how they can best be applied to create killer applications.
 At webMethods, Jay is one of the principle architects of the B2B Flow Language and version 3.0 of the B2B Developer, an integrated development environment for creating and managing services for business to business integration over the Internet.
 

Introduction

 The B2B Flow Language (Flow) defines a set of operations for processing XML documents. Together with built-in and user-defined services, these operations form the building blocks for receiving or producing XML business documents and integrating them into an organization's existing enterprise systems.
 A simplified example might be a Flow service called 'handleCustomerRequest:
 
  •  INVOKE documentToRecord (turn the parsed XML tree into a native Flow record)
  •  MAP (pull out the CustomerID, RequestType, and Items elements from the incoming document)
  •  INVOKE validateCustomerID
  •  BRANCH on 'requestType' (can be 'PriceCheck' or 'Order')
     
    •  On 'PriceCheck' LOOP over 'Items'
       
      •  INVOKE validateItem
      •  INVOKE checkInventory
      •  INVOKE getPriceForCustomer
    •  On 'Order' ...
 

Definitions

 
  •  Service
     A software module that performs a unit of work. Each takes input fields and produces output fields. A Flow service is an example. Like a "function" in Java.
  •  Field
     A container for data. Base types include String, Record (which contains other fields) and Object (arbitrary Java Object). Each field also has dimensionality: scalar, array or table. Like a "variable" in Java.
  •  Pipeline
     A "data bus" used to collect the input and output fields of services in a Flow. A service's input fields are expected to be in the pipeline when the service is invoked and a service is expected to add its output fields to this same pipeline.
  •  Mapping rules
     Three rules that can be applied to a pipeline. One for copying the data from one field into another, one for setting the value of a field in the pipeline, and one for removing a field from the pipeline.
 

Flow Operations

 Flow operations are combined to create a Flow service, one that processes an incoming purchase order, for example. Operations can be nested to form arbitrarily complex services.
 
  •  INVOKE
     Call another service. An input map is used to prepare fields in the pipeline for the invoked service's inputs. An output map is used to manipulate the service's output. Like a function call in Java.
  •  SEQUENCE
     A container for grouping a set of operations that are to be performed sequentially. Like a "{ ... }" block in Java.
  •  BRANCH
     Inspect the value of a field in the pipeline. Passes control to the contained operation whose label matches that value. Like a "switch" statement in Java.
  •  LOOP
     Iterate over all the data elements of one of the fields in the pipeline. Like a "for" statement in Java that iterates over an array.
  •  REPEAT
     Perform a series of operations a certain number of times, or until some condition is met. Like a "while" statement in Java.
  •  EXIT
     Immediately stop the execution of one of the parent flow operations. Like a "break" or "return" statement in Java.
  •  MAP
     Performs a series of mapping rules on the pipeline.
 

Flow Example

 In the example from the introduction, the Flow service 'handleCustomerRequest' would have been defined as having a single input field, say 'CustomerRequest', corresponding to the root element of a parsed XML document. When the service is invoked, the pipeline initially contains at least this one field.
 This 'CustomerRequest' is a Record with embedded fields for, among other things, the CustomerID, RequestType, and the list of items. These fields may be deeply nested within the record, and there can be numerous other fields that are to be ignored within this service.
 The XML might look like this:
 
<CustomerRequest>
 
    <Header>
 
        <CustomerInfo>
 
            <CustomerID>22920</CustomerID>
 
            <Address>...</Address>
 
        </CustomerInfo>
 
        <RequestType>PriceCheck</RequestType>
 
    </Header>
 
    <Item>
 
        <Product>Grapple Grommets</Product>
 
        <Quantity>1000</Quantity>
 
    </Item>
 
    <Item>
 
        <Product>Doohickey</Product>
 
        <Quantity>500</Quantity>
 
    </Item>
 
</CustomerRequest>
 A document like this could be represented by the following nested fields:
 
CustomerRequest (Record)
 
    Header (Record)
 
        CustomerInfo (Record)
 
            CustomerID (String)
 
            Address (Record)
 
        RequestType (String)
 
    Item (RecordList)
 
        Product (String)
 
        Quantity (String)
 The first operation in handleCustomerRequest is to INVOKE a built-in service called "documentToRecord" which translates the incoming XML document into a CustomerRequest record detailed above.
 Next, a MAP operation will pull out the CustomerID, RequestType and Item list fields from the CustomerRequest record and insert them into the pipeline as top-level fields. The data is not copied - only a new reference (or pointer) to it is inserted into the pipeline. This prepares the pipeline for subsequent INVOKE operations.
 INVOKE validateCustomerID is the next operation in the example. In a business application, this might confirm that the CustomerID truly is a client by looking it up in a database. There is no error checking illustrated above, but the validateCustomerID service could be defined to fail with an appropriate message if the CustomerID is unknown.
 Since this one XML document type can be used for two types of requests: price checks and actual orders, a BRANCH operation is used to check the value of the RequestType field. BRANCH is a container whose sub-operations are labeled to match the value of the field being inspected. In the example above, RequestType is 'PriceCheck', so the first sub-operation will be executed next.
 In this very simple example, each item is described by a Product and Quantity. The INVOKE documentToRecord at the beginning will turn a series of "Item" XML elements into a list of "Item" records (a Record array in Java). To handle a PriceCheck request, this example will LOOP over each "Item" and perform a sequence of operations.
 The first step in handling a PriceCheck for an item is to validate the value of the Product field. Again, in a business application this would check a database or other enterprise application.
 If valid, another service "checkInventory" is called to verify the availability of the Product and Quantity specified.
 Lastly, the service getPriceForCustomer returns the price per unit of that product in that quantity for that customer.
XML and related standards for data warehouses   Table of contents   Indexes   How XML Enables Internet Trading Communities and Marketplaces