Process for data driven application integration for B2B

Details Process for data driven application integration for B2B Process for data driven application integration for B2B

2001-04-18

2004-11-09

Corrielus, Jean M. (Department: 2135)

Data processing: database and file management or data structures

Database design

Data structure types

C707S793000, C707S793000, C709S227000, C719S313000, C719S328000

Reexamination Certificate

active

06816865

ABSTRACT:

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
1
,
110
2
, . . .
110
N
. Each supplier
110
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
N
of the goods. The supplier
110
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
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
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
N
. The supplier
210
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 field

Affiliated with

Also associated with

Rating

Process for data driven application integration for B2B does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Process for data driven application integration for B2B, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Process for data driven application integration for B2B will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3312871