Process for data driven application integration for B2B

Abstract

Aspects of the present embodiments provide an eCommerce environment adapted to accept and process various message types (e.g. cXML and mXML). In general, requests are provided from a requesting entity to an application hosting entity. Data from incoming requests are mapped to a format understandable to an appropriate application(s). Responses from the application(s) are then mapped into a response format acceptable by the requesting entity. To this end, embodiments disclosed herein provide processes for the development and execution of a data driven process for mapping multiple request/response message pairs to a single application interface or set of application interfaces. In one embodiment, these processes are driven by development time and run time documents that describe a development time view of the message pairs and the application Interfaces as well as runtime instructions for providing the mappings, respectively.

Claims

What is claimed is:

1. An eCommerce system for processing requests, comprising:

an application comprising an interface defining request and response format requirements and an invocation method for invoking the application;

an abstract interface corresponding to the interface of the application and defining an abstraction of the request and response format requirements and the invocation method; and

at least one message format data structure defining an interface definition of a message format of a particular eCommerce request that is incompatible with the request and response format requirements of the application, the message format data structure comprising:

protocol information identifying a protocol of the particular eCommerce request;

request type information identifying a type of request of the particular eCommerce request;

request data format information identifying a request schema describing a request format of request data for the particular eCommerce request, wherein the request schema comprises a plurality of input fields;

an input field definition mapping to selected input fields of the plurality of input fields;

response data format information identifying a response schema describing a response format of response data for the particular eCommerce request, wherein the response schema comprises a plurality of output fields; and

an output field definition mapping to selected output fields of the plurality of output fields; and wherein the input field definition and the output field definition are mapped to the abstract interface; whereby the particular eCommerce request can be serviced by the application.

2. The system of claim 1, wherein the input field definition identifies a physical location, in the particular eCommerce request, of each of the selected fields of the plurality of input fields.

3. The system of claim 1, wherein the output field definition identifies a physical location, in the particular eCommerce request, of each of the selected fields of the plurality of output fields.

4. The system of claim 1, wherein the protocol is selected from the group comprising cXML and mXML.

5. The system of claim 1, wherein the type of request is a purchase order.

6. The system of claim 1, wherein the type of request is selected from a group comprising of a purchase order, a change purchase order, a remote catalog shopping request, an invoice request and a shopping basket content request.

7. The system of claim 1, wherein the message format data structure further comprises sub-transaction type information identifying a sub-transaction type.

8. The system of claim 1, wherein selected fields of the input field definition are less than all of the plurality of input fields.

9. The system of claim 1, wherein the plurality of input fields includes input fields for at least two different request types and wherein the selected input fields of the input field definition represent only a given one of the at least two request types.

10. The system of claim 1, wherein the input field definition comprises a corresponding input field corresponding to each of the selected fields of the plurality of input fields.

11. The system of claim 10, wherein a name of at least one field of the selected fields is different than a name of the corresponding input field corresponding to the at least one field.

12. The system of claim 1, wherein a total number of fields of the selected output fields is less than all of the plurality of output fields.

13. The system of claim 12, wherein the plurality of output fields includes output fields for at least two different request types and wherein the selected output fields represent only a given one of the at least two request types, which request type is the same as represented by the selected input fields.

14. The system of claim 12, wherein the application access method is selected from a program call access method, a java access method and a queue application access method.

15. An eCommerce system for processing requests, comprising:

an application comprising an interface defining request and response format requirements and an invocation method for invoking the application;

an abstract interface corresponding to the interface of the application and defining an abstraction of the request and response format requirements and the invocation method; and

at least one message format data structure defining an interface definition of a message format of a particular eCommerce request that is incompatible with the request and response format requirements of the application, the message format data structure comprising:

protocol information identifying a protocol of the particular eCommerce request; request type information identifying a type of request of the particular eCommerce request;

request data format information identifying a request schema describing a request format of request data for the particular eCommerce request, wherein the request schema comprises a plurality of input fields for at least two different request types including the type of request of the particular eCommerce request;

input field information identifying at least a portion of the plurality of input fields and identifying a physical location, in a request message, of each input field of at least the portion of the plurality of input fields-wherein the input field information represents only a given one of the at least two request types;

an input field definition mapping only to selected input fields of the plurality of input fields representing the identified type of request of the particular eCommerce request;

response data format information identifying a response schema describing a response format of response data for the particular eCommerce request, wherein the response schema comprises a plurality of output fields for the at least two different request types; and

an output field definition mapping only to selected output fields of the plurality of output fields representing the identified type of request of the particular eCommerce request; and wherein the input field definition and the output field definition are mapped to the abstract interface; whereby the particular eCommerce request can be serviced by the application.

16. The system of claim 15, wherein the type of request is a purchase order.

17. The system of claim 15, wherein the input field definition comprises a corresponding input field corresponding to each of the selected input fields of the plurality of input fields, and wherein the output field definition comprises a corresponding output field corresponding to each of the selected output fields of the plurality of output fields.

18. An eCommerce system for processing requests, comprising:

an application comprising an interface defining request and response format requirements and an invocation method for invoking the application;

an abstract interface corresponding to the interface of the application and defining an abstraction of the request and response format requirements and the invocation method; and

a plurality of message format data structures each defining an interface definition of a message format of a eCommerce request that is incompatible with the request and response format requirements of the application, wherein each message format data structure corresponds to a different eCommerce request and each message format data structure comprises:

protocol information identifying a protocol of a particular ecommerce request comprising input fields and output fields;

request type information identifying a type of request of the particular eCommerce request;

an input field definition mapping to the input fields of the particular eCommerce request; and

an output field definition mapping to the output fields of the particular eCommerce request; and wherein the input field definition and the output field definition are mapped to the abstract interface, whereby the eCommerce requests can be serviced by the application.

19. The system of claim 18, wherein each message format data structure further comprises:

request data format information identifying a request schema describing a request format of request data for the particular eCommerce request, wherein the request schema comprises a plurality of input fields including the input fields of the particular eCommerce request; and

response data format information identifying a response schema describing a response format of response data for the particular eCommerce request, wherein the response schema comprises a plurality of output fields including the output fields of the particular eCommerce request.

20. The system of claim 18, wherein the input field definition comprises a corresponding input field for each of the input fields of the particular eCommerce request, and wherein the output field definition comprises a corresponding output field for each of the output fields of the particular eCommerce request.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to distributed systems configured to process requests provided in different formats.

2. Background of the Related Art

Wide area networks such as the Internet provide a convenient forum for engaging in a variety of commercial activities, generally referred to as eCommerce. A typical eCommerce environment 100 comprising buyers and sellers connected by the Internet is illustrated in FIG. 1. In the illustrative buyer/supplier model, a buyer organization 102 has purchased procurement software 103 from a third party vendor. The procurement software 103 allows an individual in the buying organization 102, commonly referred to a requisitioner 104, to use a browser to make purchases. The requisitoner 104 can choose from a list of approved catalogs and shop for the desired items. The catalogs are hosted locally at the buyer organization 102 on a catalog server 106. The catalog information is uploaded to the catalog server 106 by a supplier 110.sub.1, 110.sub.2, . . . 110.sup.N. Each supplier 110.sup.N is responsible providing their catalog information to the buyer organization 102.

Viewing the catalog, the requisitioner 104 selects the items and quantities needed. When finished, this order is submitted and captured by the procurement software.

The procurement software 103 next notifies a designated approver 108 that a new order request has been placed. The approver 108 is part of the buying organization and uses a browser to view the order and make any necessary changes in price and/or quantities. If the request looks satisfactory, the approver 108 approves the order request.

An approved order request results in a purchase order (PO) message being sent by the procurement software 103 to the appropriate supplier 110.sub.N of the goods. The supplier 110.sub.N accepts the PO, processes it as necessary and sends a PO response message to indicate that the order was accepted.

FIG. 2 shows an alternative eCommerce environment 200 in which a requisitioner 204 of a buying organization 202 is provided with the ability to shop from a remote catalog hosted directly at the web site of a supplier 210.sub.N. In this scenario, the requisitioner 204 again uses a browser to choose an approved catalog to shop from. The procurement software 203 then indicates that the catalog is hosted remotely. The procurement software 203 obtains, either from local storage or from the supplier site, the URL to use for shopping the catalog and returns this information to the browser of the requisitioner 204. The requisitoner 204 then shops the remote catalog and places items in a shopping cart. Upon completion, the requisitioner 204 confirms the order and checks out. The supplier 210.sub.N is then responsible for sending the shopping cart contents to an approver 208 of the buyer organization 202. The remaining steps are as those described with reference to FIG. 1. Thus, the approver 208 approves the order and causes a PO to be sent to the supplier 210.sub.N. The supplier 210.sub.N processes the PO by integrating it with back-end applications or by directing it to a commerce application for processing.

One problem with conventional eCommerce systems is that the buying organizations are installing newer versions of procurement software in an attempt to streamline the purchasing process and reduce expenses. These versions utilize protocols not supported by the legacy systems of the suppliers. These protocols include XML-based protocols, such as Commerce XML (cXML), which allow buyers to communicate with multiple seller organizations. Accordingly, buyers are motivated to do business with suppliers that support the new protocols. Suppliers must therefore support these new protocols or be at a competitive disadvantage to those sellers who do support the protocols. To this end, suppliers must either install new applications or find a means to support the new protocols using the existing order processing software (e.g., reprogram the legacy equipment). Installing new applications and reprogramming existing software are both cost prohibitive and therefore not viable solutions.

There are several existing products that attempt to address integration of existing business solutions with defined B2B protocols. In general, exiting solutions allow an XML formatted message to be mapped to one or more business applications for processing. However, the user is required to have knowledge of all fields in the XML message that apply to a given type of B2B request. Furthermore, some products require a unique adapter program to be generated for each B2B request type to be mapped to a given business application. This adapter program must be ported, compiled and installed on the platform hosting the target business applications.

Therefore, there is a need, in an eCommerce environment, to process requests having various formats including formats not originally/directly supported by supplier's applications.

SUMMARY OF THE INVENTION

Systems, methods, and articles of manufacture are provided for processing eCommerce transactions. In one embodiment, a system for handling eCommerce requests is provided. The system comprises at least one application configured to process a request in a transformed format, wherein the request is received from one of a plurality of requesting entities in an original format and mapped to the transformed format. At least one specification document is configured to produce metadata defining a relationship between data of the request in the original format and data of the request in the transformed format. A flow manager is configured to utilize the metadata to map the request in the original format to the request in the transformed format and to call the at least one application.

In still another embodiment, a system for handling eCommerce requests received from one of a plurality of requesting entities is provided. The system comprises at least two applications each configured to process requests in a transformed format; wherein a first application is configured to process a first request type and a second application is configured to process a request of a second type. At least two access methods are each configured to define an interface for the at least two applications. Illustratively, the at least two access methods comprise a first access method configured for the first request type and for the first application and a second access method configured for the second request type and for the second application. A flow manager is configured to utilize metadata to map the requests from an original format to the transformed format and to call one or more of the at least two applications.

In yet another embodiment, a method of processing eCommerce requests is provided. The method comprises receiving a request of a first request type comprising a first plurality of input fields; determining an application to invoke, wherein the application is configured to process a request of a second request type comprising a second plurality of input fields; invoking an access method, wherein the access method is configured to define an interface of the application for the second request type; mapping at least a portion of the first plurality of input fields to the second plurality of input fields; and invoking the application.

In still another embodiment, a signal bearing medium, comprising a program which, when executed by a processor, performs a method processing eCommerce requests is provided. The method comprises receiving a request of a first request type comprising a first plurality of input fields; determining an application to invoke, wherein the application is configured to process a request of a second request type comprising a second plurality of input fields; invoking an access method, wherein the access method is configured to define an interface of the application for the second request type; mapping at least a portion of the first plurality of input fields to the second plurality of input fields; and invoking the application.

In still another embodiment, a data structure is configured as an interface definition of a message format of a particular eCommerce transaction type. The data structure comprises protocol information identifying a protocol and the particular eCommerce transaction type, request data format information identifying a request message format for the particular eCommerce transaction type, wherein the request message format comprises a plurality of input fields and input field information identifying at least a portion of the plurality of input fields.

In still another embodiment, a data structure is configured as an interface definition of a request message format and a response message format of a particular eCommerce transaction type. The data structure comprises protocol information identifying a protocol and a transaction type; request data format information identifying the request message format, wherein the request message format comprises a plurality of input fields; and input field information identifying at least a portion of the plurality of input fields. The plurality of input fields includes input fields for at least two different request types and the input field information represents only a first request type. The data structure further comprises response data format information identifying a response message format, wherein the response message format comprises a plurality of output fields; and output field information identifying at least a portion of the plurality of output fields. The plurality of output fields includes output fields for the at least two different request types and the output field information represents only the first request type.

BRIEF DESCRIPTION OF THE DRAWINGS

So that the manner in which the above recited features and embodiments are attained and can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to the embodiments thereof which are illustrated in the appended drawings.

It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.

FIG. 1 shows a typical eCommerce environment comprising buyers and sellers connected by the Internet.

FIG. 2 shows an alternative ecommerce environment in which a requisitoner of a buying organization is provided with the ability to shop from a remote catalog hosted directly at the web site of a supplier.

FIG. 3 shows a high level diagram of an embodiment of a B2B environment.

FIG. 4 shows a B2B environment which, in one embodiment, may be understood as a more detailed illustration of the B2B environment shown in FIG. 3.

FIG. 5 shows an exemplary Application Connector Document.

FIG. 6 shows a relational diagram of two request message formats and an access method for an application.

FIG. 7 shows an embodiment of a runtime metadata document.

FIG. 8 shows a data flow diagram illustrating development and deployment of specification artifacts.

FIG. 9 shows a data flow diagram illustrating deployment of process flow models.

FIG. 10 shows a data flow diagram illustrating deployment of specification artifacts and processing requests.

FIG. 11 shows a flow chart of a flow manager configured to handle eCommerce requests.

FIG. 12 shows a data flow diagram illustrating a price check.

FIG. 13 shows a graphical user interface of a specification development tool.

FIG. 14 shows a graphical user interface of a specification development tool.

FIG. 15 shows a graphical user interface of a specification deployment tool.

FIG. 16 shows a graphical user interface of a deployment tool.

FIG. 17 shows a graphical user interface of a deployment tool.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Introduction

Aspects of the present invention provide an eCommerce environment adapted to accept and process various message types (e.g. cXML and mXML). In general, requests are provided from a requesting entity to an application hosting entity. Data from incoming requests are mapped to a format understandable to an appropriate application(s). Responses from the application(s) are then mapped into a response format acceptable by the requesting entity.

To this end, embodiments disclosed herein provide processes for the development and execution of a data driven process for mapping multiple request/response message pairs to a single application interface or set of application interfaces. In one embodiment, these processes are driven by development time and run time documents that describe a development time view of the message pairs and the application interfaces as well as runtime instructions for providing the mappings, respectively. As used herein, "development time" documents/view refers to various artifacts that describe flow processing and mapping rules. "Run time" documents/view refers to the collection of software components that operate to implement the flow processing and mapping rules.

As used herein, "mapping" generally refers to the process of relating one input to another input. For example, mapping includes converting a message in one format to a message in another format based on predetermined rules (this may be referred to as message-to-message transformation). In addition, mapping refers to extracting a value from a field in a message, converting it to an appropriate data type, and then placing that data at a location where an application is expecting it. In one aspect, the location may be a message passed into an application that is expecting a message as input. In another aspect, the location is a parameter on an application that is expecting a set of parameters on call invocation. The foregoing aspects illustrate input mapping; however, the present embodiments also provide for output mapping. Output mapping involves taking values output from an application and placing the values in a message in the proper format (i.e., in a format understandable by procurement software).

Accordingly, mapping assumes that the structure of a source and a target are known. For example, messages are typically broken into separate fields. In XML parlance, fields in a message are delimited by tags which name an element. A single element has attributes that further describe that element. A single element may also contain other elements with associated attributes. In non-XML messages, fields may be arbitrarily defined by the message designer as structures, strings or bits, etc. The mapping rules indicate how a particular source field is to be processed and subsequently placed into a target field. An example of mapping according to the embodiments provided herein would be associating a product number from a B2B request to a parameter of a program.

Mapping is needed because two separately developed applications or processes rarely have the same input and output requirements in terms of message format and/or data. Such applications that were not originally designed to communicate with one another require an intermediate process, such as those described herein, that allow the applications to communicate with each other without modification.

Embodiments described herein use a markup language known as extensible mark up language (XML) to advantage. XML is a popular, well-accepted language in the industry. Because many tools are available to process XML documents, viewing such documents for purposes of education and debugging is made easy. In addition, the extensible nature of XML facilitates adding functionality to existing products while continuing to maintain compatibility between releases of the products. These and other advantages make XML an excellent candidate for the methods and systems of the present application. However, embodiments of the invention are not limited to XML or XML-based protocols and the inventors contemplate using other languages, known and unknown. Accordingly, reference to XML and other specific languages and protocols is merely illustrative.

Moreover, while the embodiments have and hereinafter will be described in the context of fully functioning computers and computer systems, those skilled in the art will appreciate that the various embodiments of the invention are capable of being distributed as a program product in a variety of forms, and that embodiments of the invention apply equally regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of signal bearing media include, but are not limited to, recordable type media such as volatile and nonvolatile memory devices, floppy and other removable disks, hard disk drives, optical disks (e.g., CD-ROMs, DVDs, etc.), and transmission type media such as digital and analog communication links. Transmission type media include information conveyed to a computer by a communications medium, such as through a computer or telephone network, and includes wireless communications. The latter embodiment specifically includes information downloaded from the Internet and other networks. Such signal-bearing media, when carrying computer-readable instructions that direct the functions of the present invention, represent embodiments of the present invention.

System Architecture, Data Structures, Data Processors and Interfaces

FIG. 3 shows a high level diagram of an embodiment of a B2B environment 300. The environment generally includes a plurality of trading partners 302 connected to a supplier system 304 via a network 306 (e.g., the Internet). The trading partners 302 execute procurement software to generate a B2B request and transmit the request to the supplier system 304. Illustrative requests include purchase orders (PO), order status checks, and catalog maintenance. The supplier system 304 includes a front-end gateway 308 adapted to handle the interfacing with the trading partners 302 over a variety of connectivity mechanisms and protocols. In one embodiment, the front-end gateway 308 includes a collection of front-end protocols 310 to support the requests received from the trading partners 302. The front-end protocols 310 may be plug-ins and may be installed locally from a signal-bearing medium (e.g., a CD-ROM) or downloaded from the network 306.

A back-end flow manager 312 and the front-end gateway 308 communicate via a transport mechanism 316. In one embodiment, the transport mechanism 316 is a queuing mechanism. The back-end flow manager 312 is responsible for processing the requests by tying them to an appropriate application 314 (e.g., Enterprise Resource Planning (ERP), supply chain application, etc.). Back-end access methods 318 are provided to facilitate a connection with the appropriate application 314. As with the front-end protocols 310, the access methods 318 may be installed locally or downloaded from a remote site on the network 306. Each access method 318 is configured to handle a particular type of interfacing mechanism, as will be described in more detail below.

For simplicity, the front-end gateway 308 and the back-end flow manager 312 are shown as an integral part of a single system. However, in another embodiment, the front-end gateway 308 and the back-end flow manager 312 reside on different systems remotely located from one another. Such a distributed embodiment is facilitated by the use of transport mechanisms (e.g., transport mechanism 316) to communicate.

FIG. 4 shows a B2B environment 400 which, in one embodiment, may be understood as a more detailed figure of the B2B environment 300 shown in FIG. 3. Accordingly, in some cases, like numbers have been used to correlate FIGS. 3 and 4. In general, the B2B environment 400 includes trading partners 302 connected to the supplier system 304 via network 306. The trading partners 302 receive responses from the supplier system 304 in response to requests. The requests may be any variety of protocols, such as cXML from Ariba and mXML from Metiom. Other protocols include xCBL, OCI, and ebXML. Accordingly, the supplier system 304 is configured to support the protocols used by the trading partners 302.

The supplier system 304 includes a front-end gateway 404 connected to an HTTP server 402. The HTTP server 402 is configured to receive and send messages from/to the network 306 in the popular transfer protocol known as hyper-text-transfer-protocol (HTTP). Incoming requests are sent from the HTTP server 402 to the front-end gateway 404 which, in a particular embodiment, is implemented as a Java servlet. As such, the supplier system 400 includes an application servlet engine 406 to allow communication between the HTTP server 402 and the front-end gateway 404. Two available engines that may be used to advantage are (1) the WebSphere Application Server used in combination with the IBM HTTP server and (2) the Domino server. The Domino server has a built-in servlet engine and an HTTP server that can also be used to host Java servlets.

The front-end gateway 404 is responsible for examining and validating incoming requests. Any authentication and authorization information associated with a particular request is validated. In some cases, requests need to be transformed by the front-end gateway 404 to a normalized format consumable by a back-end flow manager 408. In other cases requests are passed exactly as received. For example, in one embodiment, the back-end flow manager 408 is configured for XML. If the requests are received in a format other than XML, the front-end gateway 404 is configured to convert the request into an XML representation.

The front-end gateway 404 communicates with the back-end flow manager 408 via a queuing mechanism 410, such as MQ Series from IBM. Thus, upon validating, authenticating and, in some cases, transforming an incoming message, the message is placed on the queuing mechanism 410. The front-end gateway 404 then waits for an associated response from the back-end flow manager 408 on a response queue.

The back-end flow manager 408 is configured to map incoming requests into a format understandable by a plurality of applications 412 and then return an appropriate response. Illustratively, the rules for mapping these messages are provided as a series of XML documents which embody the mapping rules used to associate data provided with a B2B request and the interface defined for an existing application. These documents are referred to herein as a runtime metadata document 422 (also referred to herein as the "runtime metadata 422").

In one embodiment, the runtime metadata document 422 is created and/or utilized by tools 413 (also referred to herein as "tools suite 413"). In one embodiment, the tools 413 comprise a Process Deployment Tool 413A and a Business Process Editor Tool 413B. The Business Process Editor Tool 413B in turn comprises an ACD creation tool 424 and a Process Flow creation tool 426. These XML documents and the tools 413 will be described in more detail below.

Illustratively, the applications 412 include Java classes, ERP applications, legacy business applications and data, MQ applications, and custom applications. For each application type, an access method 414 (which may also be referred to herein as a "connector") is provided. The access methods 414 are adapted to support an appropriate interfacing mechanism for each application 412. For the applications 412 shown in FIG. 4, three popular interfacing mechanisms are program calls, queues and Java methods. Accordingly, the supplier system 304 of FIG. 4 includes three access methods 414: a Java access method 414a, a program call access method 414b, and a queue application access method 414c.

It is understood that the applications 412 and the access methods 414 shown in FIG. 4 are merely illustrative and the supplier system 304 may support any number of applications 412 and access methods 414. For example, the supplier system 304 may also include an SQL access method for databases. For brevity, discussion of specific access methods 414 is limited to the Java access method 414a, the program call access method 414b, and the queue application access method 414c.

In general, an access method 414 is the "template" for an access method instance. Thus, an access method 414 is specialized into a specific access method instance, herein referred to as an Application Connector Document (ACD). By analogy to object oriented programming, the access method 414 can be thought of like a class and the access method instance (i.e., the ACD) is like an object. ACDs are described in more detail below.

Each access method 414 defines properties that are needed by the access method 414. Properties are name-value pairs that are presented to an end user at deployment time and allow for configuration information to be passed to the access method 414. For example, a property may be a system name, a user profile, a class name or a path to a document. In one embodiment, properties will always be strings and may have default values or values set at deployment.

Each access method 414 also has a mechanism used to define input and output fields. In one embodiment, such mechanisms include a PCML (Program Call Markup Language) documents and XML documents. PCML documents provide a rich tag specification for describing parameters to a program. The PCML document may be optimized to define a fixed structure buffer which is passed into an application. An XML document is a tagged string that is self-describing and can be used for applications that require XML as input.

Which mechanism/document to use depends on the nature of the application 412 to be accessed. An access method 414 may support one or both of these mechanisms. If an access method 414 uses PCML as the technique for defining input and outputs, then a property field can be defined to contain a path to the PCML document. This allows the creator of the access method 414 to specify the PCML document that describes the input/output to the application. If an access method 414 uses XML as the technique for defining input and output fields, then two property fields may be defined, one to contain a path to the XML document for input and one for the path to the XML document for output.

Illustratively, each access method 414 contains a root element called "Connector" that contains properties, input and output elements. The properties element contains a set of elements with names for the properties that access method 414 has defined. In one embodiment, the properties of an access method 414 are specified by a user using a tool, as will be described in more detail below. Once the properties have been defined to the tool, the tool will present them to an administrator so that values can be provided. In addition, the tool will allow the administrator to map fields from the input/output message to the application interface (input/output fields). When the administrator has finished providing all the information required, the tool will generate a runtime metadata specification that will be used by the back-end flow manager 408 to invoke the access method 414.

PCML Access Method:

The program call access method 414b can be used to call any program resident locally or remotely. In one embodiment, the program call access method 414b is a PCML document that describes the program to be called and the parameters expected by that program.

The properties that are defined for an exemplary program call access method 414b shown in Table I.

          TABLE I
          001   <!ELEMENT connector (properties, input, output)>
          002   <!ATTLIST connector
          003   type NMTOKEN #FIXED "programcall"
          004   name CDATA #REQUIRED
          005   version (1.0) #REQUIRED
          006   >
          007   <!ELEMENT properties (system, userid, password,
                pcmldocument)>
          008   <!ELEMENT system (#PCDATA)>
          009   <!ELEMENT userid (#PCDATA)>
          010   <!ELEMENT password (#PCDATA)>
          011   <!ATTLIST password
          012   encrypt (yes) #REQUIRED
          013   >
          014   <!ELEMENT pcmldocument (#PCDATA)>
          015   <!ELEMENT input (field*)>
          016   <!ATTLIST input
          017   type (pcml) #REQUIRED
          018   >
          019   <!ELEMENT output (field*)>
          020   <!ATTLIST output
          021   type (pcml) #REQUIRED
          022   >
          023   <!ELEMENT field EMPTY>
          024   <!ATTLIST field
          025   ref CDATA #REQUIRED
          026   display (yes .vertline. no) #REQUIRED
          027   name CDATA #IMPLIED
          028   default CDATA #IMPLIED
          029   >

    TABLE II
    001   <!ELEMENT connector (properties, input, output)>
    002   <!ATTLIST connector
    003   type CDATA #FIXED "DataQueue"
    004   name CDATA #REQUIRED
    005   connectversion (1.0) #REQUIRED
    006   >
    007   <!ELEMENT properties
    008   (MessageType, DQSendKeyed, DQSendKey,
          DQSendQueueName, DQSendLibrary, DQReceiveKeyed,
          DQReceiveKey, DQReceiveQueue Name, DQReceiveLibrary,
          DQReceiveWaitTime, pcmldocument, system, userid, password)>
    009   <!ELEMENT input (docref, field*)>
    010   <!ATTLIST input
    011   type (pcml .vertline. xml .vertline. all) #IMPLIED
    012   >
    013   <!ELEMENT output (docref, field*)>
    014   <!ATTLIST output
    015   type (pcml .vertline. xml .vertline. all) #IMPLIED
    016   >
    017   <!ELEMENT MessageType (#PCDATA)>
    018   <!ATTLIST MessageType
    019   proptype CDATA #FIXED "list(pcml; xml; csv)"
    020   default CDATA #IMPLIED
    021   label CDATA #FIXED "Message Type"
    022   >
    023   <!ELEMENT DQSendKeyed (#PCDATA)>
    024   <!ATTLIST DQSendKeyed
    025   proptype CDATA #FIXED "list(yes; no)"
    026   default CDATA #IMPLIED
    027   label CDATA #FIXED "Keyed Send Queue?"
    028   >
    029   <!ELEMENT DQSendKey (#PCDATA)>
    030   <!ATTLIST DQSendKey
    031   proptype CDATA #FIXED "string"
    032   default CDATA #IMPLIED
    033   label CDATA #FIXED "Send Queue Key"
    034   enabledBy CDATA #FIXED "DQSendKeyed(yes)"
    035   >
    036   <!ELEMENT DQSendQueueName (#PCDATA)>
    037   <!ATTLIST DQSendQueueName
    038   proptype CDATA #FIXED "string"
    039   default CDATA #IMPLIED
    040   label CDATA #FIXED "Send Queue Name"
    041   >
    042   <!ELEMENT DQSendLibrary (#PCDATA)>
    043   <!ATTLIST DQSendLibrary
    044   proptype CDATA #FIXED "string"
    045   default CDATA #IMPLIED
    046   label CDATA #FIXED "Send Queue Library"
    047   >
    048   <!ELEMENT system (#PCDATA)>
    049   <!ATTLIST system
    050   proptype CDATA #FIXED "string"
    051   default CDATA #FIXED "localhost"
    052   label CDATA #FIXED "Send-Receive Queue System"
    053   >
    054   <!ELEMENT userid (#PCDATA)>
    055   <!ATTLIST userid
    056   proptype CDATA #FIXED "string"
    057   default CDATA #FIXED""
    058   label CDATA #FIXED "Send-Receive Queue Userid"
    059   encrypt CDATA #FIXED "yes"
    060   >
    061   <!ELEMENT password (#PCDATA)>
    062   <!ATTLIST password
    063   proptype CDATA #FIXED "string"
    064   default CDATA #FIXED""
    065   label CDATA #FIXED "Send-Receive Queue Password"
    066   encrypt CDATA #FIXED "yes"
    067   keyfield CDATA #FIXED "userid"
    068   >
    069   <!ELEMENT DQReceiveKeyed (#PCDATA)>
    070   <!ATTLIST DQReceiveKeyed
    071   proptype CDATA #FIXED "list(yes; no)"
    072   default CDATA #IMPLIED
    073   label CDATA #FIXED "Keyed Receive Queue?"
    074   >
    075   <!ELEMENT DQReceiveKey (#PCDATA)>
    076   <!ATTLIST DQReceiveKey
    077   proptype CDATA #FIXED "string"
    078   default CDATA #IMPLIED
    079   label CDATA #FIXED "Receive Queue Key"
    080   enabledBy CDATA #FIXED "DQReceiveKeyed(yes)"
    081   >
    082   <!ELEMENT DQReceiveQueueName (#PCDATA)>
    083   <!ATTLIST DQReceiveQueueName
    084   proptype CDATA #FIXED "string"
    085   default CDATA #IMPLIED
    086   label CDATA #FIXED "Receive Queue Name"
    087   >
    088   <!ELEMENT DQReceiveLibrary (#PCDATA)>
    089   <!ATTLIST DQReceiveLibrary
    090   proptype CDATA #FIXED "string"
    091   default CDATA #IMPLIED
    092   label CDATA #FIXED "Receive Queue Library"
    093   >
    094   <!ELEMENT DQReceiveWaitTime (#PCDATA)>
    095   <!ATTLIST DQReceiveWaitTime
    096   proptype CDATA #FIXED "string"
    097   default CDATA #IMPLIED
    098   label CDATA #FIXED "Receive Queue Wait Time"
    099   >
    100   <!ELEMENT pcmldocument (#PCDATA)>
    101   <!ATTLIST pcmldocument
    102   proptype CDATA #FIXED "file"
    103   default CDATA #IMPLIED
    104   label CDATA #FIXED "PCML Document"
    105   enabledBy CDATA #FIXED "MessageType(pcml)"
    106   >
    107   <!ELEMENT docref (#PCDATA)>
    108   <!ELEMENT field (field*)>
    109   <!ATTLIST field
    110   ref CDATA #REQUIRED
    111   display (yes .vertline. no) #REQUIRED
    112   label CDATA #IMPLIED
    113   type (char .vertline. int .vertline. packed .vertline. zoned
     .vertline. float .vertline. byte .vertline. struct) "char"
    114   length CDATA #IMPLIED
    115   precision CDATA #IMPLIED
    116   repeating (Yes .vertline. No) "No"
    117   countfield CDATA #IMPLIED
    118   default CDATA #IMPLIED
    119   >

        TABLE III
        001       <!ELEMENT connector (properties, input, output)>
        002       <!ATTLIST connector
        003       type NMTOKEN #FIXED "Java"
        004       name CDATA #REQUIRED
        005       >
        006       <!ELEMENT properties (classname, pcmldocument)>
        007       <!ELEMENT classname (#PCDATA)>
        008       <!ELEMENT pcmldocument (#PCDATA)>
        009       <!ELEMENT input (alias*)>
        010       <!ATTLIST input
        011       type (pcml) #REQUIRED
        012       >
        013       <!ELEMENT output (alias*)>
        014       <!ATTLIST output
        015       type (pcml) #REQUIRED
        016       >
        017       <!ELEMENT alias EMPTY>
        018       <!ATTLIST alias
        019       ref CDATA #REQUIRED
        020       display (yes .vertline. no) #REQUIRED
        021       label CDATA #IMPLIED
        022       >

    TABLE IV
    001   public interface JavaConnectorInterface {
    002    public JavaConnectorResult run (ConnectorParms parameters,
          String 003 PCMLDocName);
    004   }
    005
    006   public class JavaConnectorResult {
    007    public int returncode;
    008    public String returnstring;
    009   }

    TABLE V
    001   public class GeneralConnector
          implements JavaConnectorInterface {
    002    public JavaConnectorResult run (ConnectorParms parms, String
    003    PCMLDocName {
    004     /* get the list of input fields */
    005     fields = parms.getinputfieldlist();
    006     for (/* each field in the fieldlist */) {
    007             /* repeat following section for each field data type */
    008       {
    009         /* get the field value by passing in the name attribute in the
    010           field list entry; data type for field will correspond to
    011           data type specified in the field list entry */
    012             /* an array of values is returned */
    013             For (/*each value in the arrays returned*/) {
    014             /* use the value to set a parameter that will be passed
                    to the
    015               target backend application */
    016       }
    017
    018     }/* end for */
    019     /* invoke the real back-end application */
    020     /* get the list of output fields */
    021     fields = parms.getoutputfieldlist();
    022       for (/* each field in the fieldlist */) {
    023       for (/*loop if multiple values */) {
    024       /* get value generated by target application */
    025       /* use value to update the field identified by the name attribute
              in
    026         the field list entry */
    027       }/* end for */
    028     }/* end for */
    029    }
    030   }

    TABLE VI
    001   <?xml version="1.0" encoding="UTF-8"?>
    002   <!DOCTYPE connector SYSTEM
    003   "file://localhost/C:/B2BDTD/PgmConnector.dtd">
    004   <connector name="OrderEntry" type="programcall">
    005   <properties>
    006   <system>rchas001</system>
    007   <userid>rstevens</userid>
    008   <password encrypt=yes>pwval</password>
    009   <pcmldocument>orderentrypgm</pcmldocument>
    010   </properties>
    011   <input type="pcml">
    012   <docref>orderentrypgm</docref>
    013   <field display="yes" name="Item Number" ref="xyz.inum"/>
    014   <field display="yes" name="Item
          Quantity" ref="xyz.q" default="1"/>
    015   </input>
    016   <output type="pcml">
    017   <docref>orderentrypgm</docref>
    018   <field display="yes" name="Item Price" ref="xyz.p"/>
    019   </output>
    020   </connector>

          TABLE VII
          001         <!ELEMENT protocolmessageformat 002
                      (protocol,requestschema,responseschema)>
          003         <!ATTLIST protocolmessageformat
          004         version (1.0) #REQUIRED
          005         >
          006         <!ELEMENT protocol EMPTY>
          007         <!ATTLIST protocol
          008         name CDATA #REQUIRED
          009         protocolversion CDATA #REQUIRED
          010         transactiontype CDATA #REQUIRED
          011         transactionsubtype CDATA #IMPLIED
          012         >
          013         <!ELEMENT requestschema (field*)>
          014         <!ATTLIST requestschema
          015         type (DTD) #REQUIRED
          016         name CDATA #REQUIRED
          017         >
          018         <!ELEMENT responseschema (field*)>
          019         <!ATTLIST responseschema
          020         type (DTD) #REQUIRED
          021         name CDATA #REQUIRED
          022         >
          023         <!ELEMENT field (field*)>
          024         <!ATTLIST field
          025         ref CDATA #REQUIRED
          026         name CDATA #IMPLIED
          027         default CDATA #IMPLIED
          028         count (multiple .vertline. one) "one"
          029         >


TABLE VIII
    RMF Element     Description
    Protocol        Identifies the protocol/transaction/subtype combination
                    this RMF is associated with.
    Requestschema   Identifies the schema which describes the format of
                    request data for this protocol/transaction. In one
                    embodiment,  schemas defined by XML DTDs are
                    supported.
    Responseschema  Identifies the schema which describes the format of
                    response data to be generated for this
                    protocol/transaction.
    Field           Used to identify the fields in the request and response
                    schema for this protocol/transaction that are available
                    for use in mapping to the various ACDs that are de-
                    fined to handle a given B2B request. Also allows an
                    alternative name to be associated with this field.
                    <field> elements may be nested to reflect the
     hierarch-
                    ical nature of the request and response formats sup-
                    ported by various B2B protocols.

    TABLE IX
    001     <field context="Request" count="one" label="Money" ref
    002     ="/cXML/Request/OrderRequest/OrderRequestHeader/
            Shipping/Money">
    003     <field context="Request" count="one" label="@currency" ref
    004     ="/cXML/Request/OrderRequest/OrderRequestHeader/
            Shipping/Money/@currency"/>
    005     <field context="Request" count="one"
    006     label="@alternateAmount" ref
    007     ="/cXML/Request/OrderRequest/OrderRequestHeader/
            Shipping/Money/@alternateAmount"/>
    008     <field context="Request" count="one"
    009     label="@alternateCurrency" ref
    010     ="/cXML/Request/OrderRequest/OrderRequestHeader/
            Shipping/Money/@alternateCurrency"/>
    011     </field>

                TABLE X
                Ariba cXML message
                format             Metiom mXML message format
    Retrieve    ProfileRequest     N/A
    Server      Response =
    Capabilities ProfileResponse
    New         OrderRequest with  PurchaseOrderMessage
    Purchase    type = new         Response =
    Order       Response = Response PurchaseOrderAcknowledgement-
                                   Message
    Change      OrderRequest with  PurchaseOrderChangeRequest-
    Purchase    type = update or delete Message
    Order       Response = Response Response =
                                   PurchaseOrderChangeRequest-
                                   AcknowledgementMessage
    Remote      PunchOutSetupRe-   N/A
    Catalog     quest with type =
    Shopping    create, edit, inspect
    Request     Response=
                PunchOutSetupRe-
                sponse
    Shopping    PunchOutOr-        OrderRequestMessage
    Basket      derMessage
    Content
    Invoice     N/A                InvoiceMessage

                             TABLE XI
                      Process Flow Model DTD
    001   <!ELEMENT processflowmodel (protocol, connector, inmap*,
          outmap*)>
    002   <!ELEMENT protocol>
    003   <!ATTLIST protocol
    004   name CDATA #REQUIRED
    005   protocolversion CDATA #REQUIRED
    006   transactiontype CDATA #REQUIRED
    007   transactionsubtype CDATA #IMPLIED
    008
    009   >
    010   <!ELEMENT connector EMPTY>
    011   <!ATTLIST connector
    012   acdref CDATA #REQUIRED
    013   >
    014   <!ELEMENT inmap EMPTY>
    015   <!ATTLIST inmap
    016   source CDATA #IMPLIED
    017   target CDATA #REQUIRED
    018   value CDATA #IMPLIED
    019   >
    020   <!ELEMENT outmap EMPTY>
    021   <!ATTLIST outmap
    022   source CDATA #REQUIRED
    023   target CDATA #REQUIRED
    024   >


TABLE XII
    001   <?xml version="1.0" encoding="UTF-8"?>
    002   <!DOCTYPE processflowmodel SYSTEM
    003   "file://localhost/C:/B2BDTD/ProcessFlowModel.dtd">
    004   <processflowmodel>
    005    <protocol name="cXML" protocolversion="1.0"
    006   transactiontype="OrderRequest"/>
    007    <connector acdref="OrderEntry"/>
    008    <inmap source="/ItemOut/ItemID/SupplierPartID"
    009    target="Item Number"/>
    010    <inmap source="/ItemOut/@quantity" target="Item Quantity"/>
    011    <outmap source="Item Price" target="/ItemOut/@price"/>
    012   </processflowmodel>

    TABLE XIII
    GUI
    Control
    Name        Description
    Access      Name associated with this access method instance. Names must be
    Method      unique since they are used to reference a given access method
    Name        instance from a business process flow (PFM).
    Access      Defines the type of access method for this access method
     instance.
    Method      Specific properties and the type of input/output message
     formats
                allowed for the access method instance are defined by the
     access
                method. Selection of access method will affect the information
                presented in the Properties and Documents sections. When
     editing
                an existing access method instance definition, the Access
     Method
                field will be disabled; thereby preventing a user from changing
     the
                access method for an existing access method instance.
    Properties  Name/value pairs defining information needed by a particular
     access
                method to service requests at runtime. The set of name/value
                properties is specific to each access method type.
    Documents   Identifies an XML document or PCML document, for example, which
                defines the input and output fields supported by the individual
                access method instance. Input document defines the set of
     fields
                supported as input to the access method instance. Output
     document
                defines the set of fields that are returned by the access
     method
                instance. When PCML is used, the same document will typically
                appear for both input and output. When document type is XML,
     the
                element and attribute names defined by the XML document
                represent the candidate set of fields supported by the access
                method instance. When the document type is PCML, the data and
                structure elements defined by the PCML document represent the
                candidate field set for the access method instance.
    Field ID    A hierarchical view showing the set of candidate input and
     output fields
                supported by the access method instance as defined by the
     specified
                input and output documents, respectively.
    Name        Used to assign a more intuitive name (e.g., an alias) to a
     particular field
                defined in either the input or output document for this access
     method
                instance. Values specified for Name will be displayed when
     mapping B2B
                request fields to access method fields on the Process Flow tab
     of the
                Business Process Editor.
    Default     Used to assign a default value to a particular field. Default
     value is used if
                field is not explicitly mapped from data contained in the
     incoming B2B
                request.
    Display     Used to control whether a field is displayed when mapping B2B
     request
                data to fields associated with the access method. Deselecting
     display will
                cause the field to be treated as "hidden" so that it won't be
     displayed on
                the Process Flow tab and cannot be the source or target for
     data mapped
                from the B2B request being handled by this access method
     instance.

    TABLE XIV
    Menu Option     Action
    File -> New  Create a new access method instance definition. Only
                    Name and Access Method will be shown until Access
                    Method is selected.
    File -> Open . . . Bring up browse interface to locate pre-existing
     access
                    method instance file for update.
    File -> Save Save changes made to this access method instance.
    File -> Save Bring up browser interface to select file name and lo-
    As . . .        cation to save this access method instance definition
                    under.
    File -> Exit Exit the Business Process Editor.
    Edit -> Cut  Cuts the selected text to the system clipboard.
    Edit -> Copy Copies the selected text to the system clipboard.
    Edit -> Paste Pastes current text from a system clipboard to the
                    current cursor location.
    Publish         Select a host system and B2B instance to send a
                    completed PFM and access method instance
                    definitions to.
                    A publish operation stores the completed PFM and ac-
                    cess method instance definition on a B2B server from
                    which it can be deployed to the runtime environment.
    Help            Brings up online help for the Business Process Editor.

    TABLE XV
    GUI
    Control
    Name        Description
    Protocol    Allows a user to choose the protocol to be serviced by this
     process flow
                definition.
    Action      The Action dropdown is based on the selected protocol. Allows a
     user
                to choose the action to be serviced by this process flow
     definition.
    Access      This dropdown displays the list of available access method
     instances.
    Method      Access method instances are defined using the Application
     Access
    Name        method tab. Allows a user to choose the access method instance
     that
                will be used to handle B2B requests of the specified protocol
     and
                action.
                Once an action and an access method are selected, the Load
     button is
                enabled. When the Load button is clicked:
                I. The Request Fields and Response Fields in the Input Mappings
                and Output Mappings sections are filled with the fields
     associated
                with the chosen protocol/action.
                II. The Access Method Fields in the Input Mappings and Output
                Mappings sections are filled with the fields associated with
     the
                chosen access method instance.
    Input       Shows the set of fields provided with this type of B2B request
     and the
    Mappings    input fields supported by the specified access method instance.
     User
                may select a Request Field and an Access Method Field and click
     Add
                Mapping to indicate that the Request Field is to be mapped to
     the
                selected Access Method Field at runtime. This data mapping
                association is displayed in the Mapping Table at the bottom of
     the
                Business Process Editor screen.
    Output      Shows the set of fields returned by the specified access method
     and
    Mappings    the set of fields that make up the response message for this
     type of
                B2B request. User may select a Response Field and an Access
                Method Field and click Add Mapping to indicate that the Access
                Method Field is to be mapped to the selected Response Field at
                runtime. This data mapping association is displayed in the
     Mapping
                Table at the bottom of the Business Process Editor screen.
    Mapping     This table lists all of the data mappings that have been
     defined
    Table       between Request/Response data fields associated with this type
     of
                B2B request and the input and output fields associated with the
                specified access method instance.
                To remove a mapping from the table, select the row containing
     the
                mapping and click Remove.
                To remove all mappings from the table, click Remove All. A
     warning
                message appears to confirm this operation.

• Inventors
  O'Brien, Terrence Ross; Rapp, William Craig; Stevens, Richard Joseph;
• Assignee
  International Business Machines Corporation (Armonk, NY)
• Published
  Nov-9-2004
• Current US Classes:
  707/100
  707/104.1
  707/4
  709/227
  719/313
  719/328
• Application #
  837413
• International Classes
  G06F 007/00
• Field of Search
  707/2 707/10 707/101 707/104.1 705/26 705/40 705/27 705/1 709/227 719/313 719/328
• Examiner
  Corrielus; Jean M.
• Agent
  Moser, Patterson & Sheridan, LLP
• US Patent References:
  5778223
  6101556
  6125391
  6453306
  6591260