Enterprise application platform

Abstract

A business platform can provide access to applications and provide for the integration of resources with other applications, including internal and external applications, services and systems. A portal framework included within the platform can render portals including graphical user interfaces for displaying and receiving content that can be used by various applications. A portal framework can provide an interface to various resources such that information received and displayed by the portal framework can be exchanged with internal and external resources using standards-based transport protocols, messaging systems, and document types. An integration framework can be invoked to exchange this information among applications and services. An integration framework can provide access to resources by integrating the resources with an application server. The portal framework and integration framework can be implemented on an application server which can support enterprise applications. This description is not intended to be a complete description of, or limit the scope of, the invention. Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

Description

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document of the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

CROSS-REFERENCED CASES

The following applications are cross-referenced and incorporated herein by reference:

U.S. patent application Ser. No. 10/377,917, entitled “WEB SERVICE-ENABLED PORTLET WIZARD,” filed Feb. 28, 2002; and

U.S. patent application Ser. No. 10/377,865, entitled “PORTAL SETUP WIZARD,” filed Feb. 28, 2002.

FIELD OF THE INVENTION

The invention relates generally to platforms for running and integrating software applications, such as enterprise applications.

BACKGROUND

Electronic commerce has established itself as a lasting and important component in the modern economy. For continued and long-term success, electronic commerce will require cross-enterprise collaborations among disparate resources including enterprise applications. To achieve cross-enterprise integration, a company must first integrate internal applications. To date, an integration solution that is easy to use, affordable, and based on industry wide standards has not been successfully established. No solution achieving an industry standard infrastructure with universal connectivity, massive scalability, and incorporating accessible business process tools has been developed.

Many companies have a need for platform solutions capable of fully integrating internal business processes that include multiple internal applications. These same companies also have a need for platform solutions capable of integrating internal applications with external services and applications including external business-to-consumer and business-to-business applications, such as applications that can utilize the Internet to generate revenue and reduce costs. The requirement for Internet-enabled applications has led to the rise of the application server market. To date, application servers have primarily been used to host external applications targeted at customers and partners. Application servers are themselves packaged applications that, instead of solving a specific problem, are general-purpose platforms that host vertical solutions.

Furthermore, many companies need an efficient solution for providing targeted presentations to consumers, partners, and employees in the form of user friendly interfaces. Integrating these interfaces with existing and future internal and external applications can further complicate attempts at successful, efficient, and reliable fully integrated business solutions.

BRIEF SUMMARY

Systems and methods in accordance with one embodiment of the present invention can provide platform solutions to integrated business environments. A portal framework can be used to render portals including graphical user interfaces for displaying and receiving content. Information received and displayed by the portal framework can be exchanged with internal and external services and applications using standards-based transport protocols, messaging systems, and document types. An integration framework can be invoked to exchange this information among applications and services. A portal framework and integration framework can be implemented on an application server which can support enterprise applications running on single or multiple instances of the server. Communication among a portal framework and integration framework can further be accomplished by utilizing standards-based communication.

Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will described by way of exemplary embodiments, but not limitations, illustrated by the accompanying drawings wherein like references indicate similar elements, and wherein:

FIG. 1 is a high level block diagram of various software components of a computer network capable of supporting a configurable electronic business system in accordance with an embodiment of the present invention;

FIG. 2 is a high level block diagram of various software components of a computer network supporting a configurable electronic business system in accordance with an embodiment of the present invention that can be used to implement an enterprise application;

FIGS. 3 a-3e are flowcharts illustrating the interaction of the various software components of FIG. 2 that can be used to implement the enterprise application;

FIGS. 4 a-4g are screenshots illustrating a portal and various portal pages that can be generated in accordance with the enterprise application implemented by the components of FIG. 2 and method of FIGS. 3a-3e.

FIG. 5 is a high level block diagram of various software components of a computer network supporting a configurable electronic business system in accordance with an embodiment of the present invention that can be used to implement an enterprise application.

FIGS. 6 a-6c are flowcharts illustrating the interaction of the various software components of FIG. 5 that can be used to implement the enterprise application.

FIGS. 7 a-7f are screenshots illustrating a portal and various portal pages that can be generated in accordance with the enterprise application implemented by the components of FIG. 5 and method of FIGS. 6a-6c.

DETAILED DESCRIPTION

FIG. 1 is a high level block diagram of various software components of a computer network supporting a configurable electronic business system in accordance with the present invention.

Application server 110 is an application server, such as BEA WEBLOGIC SERVER™ available from BEA Systems, Inc. of San Jose, Calif. Application server 110 can provide an easy to use application infrastructure for building, integrating, securing, and managing distributed applications including Java based applications. In one embodiment, application server 110 implements Java 2 Platform, Enterprise Edition (J2EE), available from Sun Microsystems, Inc. of Santa Clara, Calif.

Integration framework 115 can be implemented on application server 110 and can include various integrated components and/or software elements such as business-to-business (B2B) integration 120, a management component such as business process management (BPM) 125, and application integration 130. An event processor such as event processor 135 can be included within business process management 125. In various embodiments, B2B integration 120 can communicate with external components such as a computer network of a supplier 140. Other components, such as business process management 125 and application integration 130, can communicate with external components such as inventory or order management system 145. It will be appreciated that integration framework can communicate with a variety of resources such as internal and external applications, legacy systems, and databases, etc.

Application integration can utilize resource adapters and application views to establish an enterprise-wide, united framework for integrating any current or future application. Adapters can simplify integration efforts by allowing each application to be integrated with an application server, instead of requiring that each application be integrated with every other application.

The development and widespread acceptance of standards such as the J2EE standard, as well as the eXtensible Markup Language (XML), has laid the groundwork for a standardized approach to the development of these adapters. Perhaps the most significant of these standards for application integration is the J2EE Connector architecture. The J2EE Connector architecture (JCA) provides a standardized approach for the development of adapters for all types of applications, from legacy mainframe applications, such as CICS from IBM, to packaged applications such as PeopleSoft, Siebel, and SAP. The adoption of such standards enables businesses to develop adapters that work on any J2EE-compliant application server, for example.

An application integration component directed at enterprise application integration can have several primary aspects. If the functionality of an Enterprise Information System such as a PeopleSoft system or an SAP system is to be invoked, an implementation of the J2EE Connector Architecture can be used. If something occurs inside an EIS system, such as a trigger going off, an event can be generated. This event may, in some embodiments, need to be communicated to an external application. An event architecture in an application integration component can handle this communication.

An application view is an example of a component that can be used to simplify the way in which adapters are accessed. Application views can provide a layer of abstraction, for example, between an adapter and the EIS functions exposed by that adapter. Instead of accessing an EIS by direct programming a user can simply edit an adapter's application views, create new application views, or delete any obsolete application view(s). A more detailed discussion of an integration framework can be found in U.S. patent application Ser. No. 10/271,194, entitled “APPLICATION VIEW COMPONENT FOR SYSTEM INTEGRATION,” by Mitch Upton, filed Oct. 15, 2002, which application claims priority to U.S. Provisional Patent Application No. 60/347,919, filed Oct. 18, 2001, entitled “APPLICATION VIEW,” as well as Application No. 60/347,901, entitled “EVENT ADAPTER,” filed Oct. 18, 2001, all of which are hereby incorporated herein by reference.

Portal framework 150 can be implemented on application server 110 and can include various components such as portal manager 155, webflow 180, and pipeline component(s) 160. Portal manager 155 can manage the content generated within portal framework 150, including content generated by portal processors and portlet servlets (not shown) within framework 150 used in rendering various graphical user interfaces such as portal 165.

Portal framework 150 can render portals that can provide access to information networks and/or sets of services through the World Wide Web and/or other computer networks. Portals can provide a single point of access to data and applications, making portals valuable to developers, businesses, and consumers alike. A portal can present a unified and personalized view of enterprise information to employees, customers, and business partners. In many implementations, a portal application can include a Web application designed as a portal.

Portals are capable of presenting multiple web applications within a single web interface. In addition to regular web content that can appear in a portal, portals provide the ability to display portlets (self-contained applications or content) in a single web interface. Portals can also support multiple pages with tag-based navigation for accessing individualized content and portlets for each page.

Portlets can be implemented as Java server pages (JSPs) with XML-based metadata that can fit into a portal. Portlets can utilize various types of display code to display highly focused information directed to a specific user or user group, having a portal as the portlet's container. Portlets can include portlet components having portlet attributes (i.e. whether the portlet is editable, floatable, minimizable, maximizable, helpable, and mandatory, has defaults minimized, or whether login is required) and portlet layout elements or components (i.e. banner, header, content, and footer sections). In one embodiment, a portlet is defined by a file that contains XML-based metadata for a portlet. Portlets can also be associated with portlet resource files including stub JSPs (one for each portlet layout element) and image files created and saved to a local file system. In various embodiments, portlet servlets within portal framework can generate and render content including JSPs to form the portlets within portal 165.

A webflow, such as webflow 180, can be used to control the flow of a user's session through the pages displayed in a browser, such as the pages associated with portal 165, as well as the execution of specific pieces of business logic. Webflow 180 can guide the progress of the interaction of the user with an actual e-commerce application system. Different types of application code can be used to track and to modify the user interface. These codes may in one embodiment include Java Servlet Pages (JSP) to present information to the user that includes a series of buttons, links and HTML elements; input processing code which is used to modify the user input; and pipeline processing code, which may be a stateless session Enterprise Java Bean (EJB) or manipulating entity EJB. An entry for each code type can be included in a property file used to configure the webflow. The property file describes the various states of the JSP, HTML, and input and pipeline processing features, and also describes the transitions between those features. The transitions may include links, buttons and processing results which determine how the output of one feature affects another feature.

Various events can be generated as a user navigates within or through portal 165. For example, selecting a particular content location using a mouse with an associated cursor located over the desired location can generate an event to be processed by webflow 180 and its associated components. Events can result in the invocation of input processors and pipelines including flexible mechanisms for handling form submission. Input processors can perform validation of data entered into pages and portlets and store the user data in various pipeline sessions for subsequent use by a pipeline component. A pipeline can include a storage location for information regarding the current session, such as data for the current shopping cart or transient data such as error messages relating to user input.

Pipeline component(s) 160 includes discrete units of server-side business logic for performing various tasks such as calculating tax, submitting orders for business transactions, or otherwise communicating with other components including service provider interfaces (SPI) implemented as EJB's. Input processors and pipelines (including pipeline components) can succeed and generate exceptions, from which webflow 180 can decide which pages to display and which pieces of business logic to execute. In one embodiment, pipeline component(s) 160 is included within webflow 180. A more detailed discussion of a portal framework including various components such as webflow can be found in U.S. patent application Ser. No. 09/908,023, entitled “SYSTEM FOR MANAGING LOGICAL PROCESS FLOW IN AN ONLINE ENVIRONMENT,” by Neil Smithline and Sathyanarayana Giridhar, filed Jul. 18, 2001, which application claims priority to U.S. Provisional Patent Application No. 60/236,898, entitled “SYSTEM FOR MANAGING LOGICAL PROCESS FLOW IN AN ONLINE ENVIRONMENT,” filed Sep. 28, 2000, each of which are hereby incorporated herein by reference.

In accordance with one embodiment of the present invention, portal framework 150 and integration framework 115 are implemented on a single instance of application server 110 and can run on a single Java virtual machine. Thus, portal framework 150 and integration framework 115 can be used together in an enterprise application running on a single instance of application server 110. In other embodiments, an enterprise application can run on multiple instances of application server 110, invoking functionality from various locations. In such embodiments, portal framework 150 and integration framework 115 may be implemented on separate servers or separate instances of the server. Portal framework 150 and integration framework 115 can communicate or otherwise exchange data and information using various standardized messaging systems. In one embodiment, portal framework 150 and integration framework 115 can exchange information using Java enabled messaging systems and standardized languages such as XML. For example, the J2EE connector Architecture and Java Messaging Service (JMS) can be used in some embodiments.

JMS, a Java API, is an enterprise messaging system allowing applications and components to communicate with one another through the exchange of messages that can include requests, reports, and events that contain information needed to coordinate communication between different applications and/or software components. Messages can provide a layer of abstraction allowing the details of a destination system and application code to be separated. JMS messaging systems can be used in enterprise applications to communicate with legacy systems or to provide communication lanes between business components running in different environments or on different hosts. The Java connector architecture can provide for connectivity between application servers and enterprise information systems such as ERP systems, mainframe transaction processing systems, and legacy database systems. The connector architecture can rely on technologies standardized and defined by the J2EE to avoid adding custom code when providing connectivity to an information system.

Portal framework 150 and integration framework 115, provided on application server 110, can simplify and ease the creation and implementation of enterprise applications for application developers.

Business-to-Consumer

FIG. 2 is a high level block diagram of various software components of a computer network supporting a configurable electronic business system in accordance with one embodiment of the present invention that can be used to implement the following enterprise application. FIG. 3 is a flowchart illustrating the interaction of the various software components of FIG. 2 that can be used to implement the enterprise application.

Portal framework 150 can present portal 205 to a user at a step 305. Portal 205 can present a personalized view to the user after the user logs in or is automatically logged in. In one embodiment, the personalized view is a default view. Portal manager 155, along with various webflow 215 and pipeline components (210, 220, 230), can render portal 205 substantially as shown in FIG. 4a, including multiple portlets such as browse catalog portlet 406, shopping cart portlet 407 (if user has placed items into the shopping cart), search portlet 408, and tour guide documentation portlet 409.

From shopping cart portlet 407 within portal 205 or the shopping cart page 416 (FIG. 4d) of portal 205, the user can select the checkout feature at step 310. If the checkout feature is not chosen, the user can search and/or browse the product catalog represented in the pages of portal 205 at step 315. For example, having selected the consumer digital cameras link 410, the user is presented with a category summary page for the consumer digital cameras. An event generated by the user selecting link 410 can generate an exception from which webflow 215 determines to display the category summary page, as illustrated in FIG. 4b. Portal manager 150 can gather the necessary resources, including any XML definition files and JSP pages to render the appropriate page. The category summary page, as shown in FIG. 4B, includes a search portlet 408, category portlet 411, shopping cart portlet 407, tour guide documentation portlet 409, and product evaluator portlet 412.

Product evaluator portlet 412 can be, for example, a web service enabled portlet adapted to expose an external rating web service for the items listed on the category summary page. Portlet 412, as described, can include JSP portlet code providing an HTML form for entering product numbers. If the user accesses the product evaluation portlet at step 320, information entered into the HTML form can be passed to an operation of the external web service which returns a rating for the product that can displayed in the portlet at step 325. In one embodiment, a pipeline component is invoked to pass the rating request and receive the response using, for example, the Simple Object Access Protocol (SOAP), which uses a combination of XML-based data structuring and the Hyper Text Transfer Protocol (HTTP) to define a standardized method for invoking methods in objects that are distributed in diverse operating environments across the Internet. FIGS. 4b and 4c illustrate product evaluator portlet 412 before and after a rating has been requested.

From various pages within portal 205, the user can add items to the shopping cart or to a saved list of items at step 330. As items are added to the shopping cart or saved list, the pipeline session for the current session can be updated with information regarding the chosen products at step 335. Additionally, from many of the pages within portal 205, the user can select a buy now feature for an item. In response, the item can be added to the shopping cart and portal framework 150 can present a shopping cart page as illustrated in FIG. 4d.

If the user selects the checkout feature from shopping cart portlet 407 or from shopping cart page 416 of portal 205 at step 310, a real-time inventory validation of the product item(s) being ordered can be performed as illustrated in FIG. 3a. In other embodiments in accordance with the present invention, a real-time inventory validation is performed when the user selects a buy now feature, tries to add a product item to the shopping cart, or tries to update the quantity of an item already in the shopping cart.

In one approach to performing real-time inventory validation, portal framework 150 can make a call through integration framework 115 to a back-end inventory system such as inventory management system 145. Inventory management system 145 can include an inventory table or database with information about product and part inventory information and can be accessed through application integration 130.

Pipeline component 220 (e.g., CheckInventoryPC) can be used to call service provider interface 225 (SPI) (e.g., InventoryProvider). SPI 225 can be implemented as a stateless session enterprise Java bean (EJB) and can contain various remote methods for performing inventory operations such as: public int checkInventory( ); public List get ProductInventory( ); and public List getProductPartInventory( ). List can contain Inventory objects, where an Inventory object can be an interface implemented as shown below.

package examples.e2e.b2b;
public interface Inventory {
/**
* Returns the identifier for the inventory oibject.
*/
public String id( );
/**
* Returns a description for the inventory object.
*/
public String description( );
/**
* Returns the minimum quantity of this inventory object that
* should be maintained in stock.
*/
public long min( );
/**
* Returns the maximum quantity of this inventory object that
* should be maintained in stock.
*/
public long max( );
/**
* Returns the current quantity of this inventory object.
*/
public long max( );
}.

In one embodiment, SPI 225 can be implemented utilizing related environment variables from an ejb-jar.xml file described using the <env-entry-name> tag. Pipeline component 220 can call SPI 225, utilizing the functionality provided by an inventory method such as a CheckInventory( ) implementation method of SPI 225 at step 340. CheckInventory( ) can utilize application integration 130 to call a pre-configured application integration service. The service can query inventory table 145 to determine product availability at step 345. In one embodiment, an inventory check and response is sent as an XML document using standards-based transport protocols or standards-compliant protocols such as SOAP. In other embodiments, a JCA can be used. After receiving a response from application integration 130, CheckInventory( ) can call an XML helper to parse the response at step 350. It will be appreciated that numerous implementations of SPI 225 can be made depending on an application's requirements, including the requirements of any back-end management system.

An integer representation of the response can be returned through pipeline component 220 at step 355. Portal framework 150 can display the inventory response through a portlet within portal 205. In one embodiment, a message is displayed within portal 205 indicating unavailability if the inventory is insufficient to fulfill the order. In other embodiments, portal framework 150 can additionally utilize a pricing service to calculate and display any applicable discount for the product(s) selected by the user. If the inventory for a selected product(s) is unavailable, the user can update the quantity of the selected product or remove the product from the shopping cart (steps 360-362).

After validating the availability of all selected products, a checkout page can be displayed as shown in FIG. 4e at step 364. At the checkout page, the user can enter various information such as a billing/shipping addresses, shipping method, credit card information, and contact information at step 366. After selecting continue order from the checkout page, portal framework 150 can display an order submission page to the user as shown in FIG. 4f at step 368.

From the order submission page, the user can review and validate their order. After selecting submit order at step 370, portal framework 150 can access payment processing web service 170 for credit card authorization, capture, and settlement at step 372. Web service 170 can support various calls, such as authorize, capture, and settle, wherein a “true” response can be returned by web service 170 in response to one of the calls. An authorize call can accept a credit card number as an argument, for example, while a capture call can accept an amount to be captured. A web proxy can be used to call web service 170 from pipeline component 210, wherein pipeline component 210 can make the calls to web service 170 in succession. Web service 170 can then authorize, capture, and settle the credit card authorization at step 374. After receiving an authorization from web service 170, portal manager 155 can display an order confirmation page to the user at step 376 as illustrated in FIG. 4g.

After authorization and display of the order confirmation page, portal framework 150 can begin management of the order. When the order is persisted, an XML representation of the order can be created and placed on event queue 175. In one embodiment, event queue 175 is a JMS event queue. The XML representation of the order can be submitted by a pipeline component to event queue 175, thus enabling asynchronous communication between the queue and integration framework 115.

Portal manager 155, which can render portal 205, can be in communication with pipeline component 230 (e.g., ConvertOrderRepPC) which can call SPI 235 (e.g., PurchaseManager). SPI 235 can be implemented as a stateless session EJB and can contain various remote methods for performing operations regarding orders, queries for price and availability, and purchase orders, such as: queueOrder; queueQPA; and queuePORequest.

In one embodiment, SPI 235 can be implemented utilizing related environment variables from an ejb-jar.xml file described using the <env-entry-name> tag. Pipeline component 230 can covert the order generated within portal framework 150 to an XML message at step 378. An exemplary XML representation of an order is illustrated below.

<?xml version=“1.0” encoding=“UTF-8” ?>
<wlcs_order customer_id=“democustomer” id=“14004”
status=“SUBMITTED”>
<price>
<amount>4309.11</amount>
<currency>USD</currency>
</price>
<special instruction>please use a lot of bubble
wrap..</special_instruction>
<shipping>
<splitting_preference>Ship all at once</splitting_preference>
<subtotal>4099.2</subtotal>
<lines>
<line id=“14005”>
<quantity>3.0</quantity>
<product_id>9-33305</product_id>
<tax>
<shipping>
<amount>2.475</amount>
<currency>USD</currency>
</shipping>
<unit_price>
<amount>973.95</amount>
<currency>USD</currency>
</unit_price>
<msrp>
<amount>1149.95</amount>
<currency>USD</currency>
</msrp>
<description>tool set-933305</description>
<total_amount>2921.85</total_amount>
</line>
<line id=“14006”>
<line id=“14007”>
</lines>
</wics_order>

Pipeline component 230 can call SPI 235, invoking an order processing method such as a queueOrder( ) implementation method of SPI 235. The XML message can be sent to event queue 175 to which a workflow 240 within business process management 125 is subscribed at step 380. Event processor 135 can retrieve the XML representation of the order for processing at step 382. A workflow can be a representation of a business process, enabling the orchestration of the execution of business logic and the exchange of business documents among back-end systems, users, and trading partners (systems and users) in a loosely coupled fashion. In one embodiment, the XML representation of the order is sent as a JMS XML message and event queue 175 is a JMS queue.

The JMS XML message can start workflow 240 or trigger a workflow event listened to by a running instance of the workflow 240. After retrieval of the message from JMS queue 175, workflow 240 can parse the XML message and forward all the input data to back end inventory system 145 at step 384. Portal framework 150 can update an order history portlet to reflect the order status at step 386.

Business-to-Business

Portal framework 150 and integration framework 115 can additionally simplify and ease the creation of enterprise applications for application developers developing business-to-business applications. Consider the following example of a business-to-business enterprise application utilizing portal framework 150 and integration framework 115 running on application server 110. This example will illustrate various functionality capable of monitoring a database, soliciting information from external sources, and using the information to formulate and transmit requirement information from one of the external sources. Such functionality can be beneficial in applications where a level of inventory is to be maintained and requirements for the inventory can be procured from various sources. The following example illustrates an application involving a purchasing agent for an entity accessing an electronic database representing an inventory, selecting a product to purchase, sending a query for price and availability to multiple suppliers, receiving quotes for pricing and availability, and formulating a purchase order for the item to be sent to one of the suppliers.

FIG. 5 is a high level block diagram of various software components of a computer network supporting a configurable electronic business system in accordance with the present invention that can be used to implement the following enterprise application. FIGS. 6a-6c are flowcharts illustrating the interaction of the various software components of FIG. 2 used to implement the enterprise application.

A user, such as a purchasing agent, can be automatically logged into portal framework 150. Other methods can also be used to indicate to portal framework 150 the identity of the user such that webflow 515 and portal manager 155 can render a personalized page such as a homepage within portal 505. Portal 505 can include tabs representing various pages within the portal. By selecting a tab, portal framework 150 can generate and/or gather the necessary resources (JSP's, XML definition files, etc.) such that the appropriate portal page represented by the tab is rendered. At step 602, the user can select an inventory tab 702 to view an inventory page as illustrated in FIG. 7a.

In order to determine and display the inventory information to the user, portal framework 150 can make a call through integration framework 115 to a back-end inventory system such as inventory management system 145, using similar functionality as discussed above with regards to the consumer example. Portal framework 150 can include a pipeline component 520 (e.g., GetInventoryPC) that can call service provider interface 225 (e.g., InventoryProvider). As previously discussed, SPI 225 can be implemented as a stateless EJB and can include various remote methods for performing inventory operations such as getProductInventory( ) and getProductPartInventory( ).

To determine product inventory, pipeline component 520 can call SPI 225, utilizing the functionality provided by a product inventory method such as the getProductInventory( ) implementation method of an implementation of SPI 225 at step 604. GetProductInventory( ) can utilize application integration 130 to make a call using a pre-configured application integration service at step 606. This service can query inventory management system 145 to determine product inventory at step 606. After receiving a response from application integration 130, GetProductInventory( ) can call an XML helper to parse the response in order to create a List of Inventory objects at step 608. The List of Inventory objects can be returned to portal framework 150 which can render product inventory portlet 704, including the available inventory of the selected products at step 610.

From the inventory page, a check parts inventory button can be selected for a product in order to view the inventory for the individual parts that comprise the product. To determine the parts inventory for a product, pipeline component 530 can call SPI 225, utilizing the functionality provided by a product part method such as the getProductPartInventory( ) implementation method. GetProductPartInventory( ) can utilize application integration 130 to make a call using a pre-configured application integration service. This service can query inventory management system 145 to determine the parts inventory for a product using a similar query as previously discussed. After receiving a response from application integration 130, GetProductPartInventory( ) can call an XML helper to parse the response in order to create a List of Inventory objects. The List of Inventory objects can be returned to portal framework 150 which can render product part inventory portlet 706, including the available inventory of the products' parts, as illustrated in FIG. 7b.

From product part inventory portlet 706, the user can select the Request Quote button for a particular part. After the Request Quote button for a part is selected, portal framework 150 can render a purchasing page as illustrated in FIG. 7c at step 612. The purchasing page can include query for price and availability portlet 708. Within portlet 708, the user can enter information into the fields for quantity, unit price, and required receipt date. After entering the information, a query for price and availability (QPA) can be initiated when the user selects the send QPA request button within portlet 708 at step 616. A QPA object can be implemented as follows in one embodiment.

package examples.e2e.b2b;
import com.bea.commerce.ebusiness.price.quote.Money;
/**
* Represents a query for price and availability that is to be
comnmunicated to supplier(s).
* @author Copyright (c) 2002 by BEA Systems, Inc. All Rights Reserved.
*/
public interface QPA {
/**
* Returns the identifier for this QPA.
*/
public String requestId( );
/**
* Returns the date this QPA was created.
*/
public Calendar creationDate( );
/**
* Returns the identifier for the product to be quoted.
*/
public String productId( );
/**
* Returns a description for the product to be quoted.
*/
public String description( );
/**
* Returns the quantity of the product desired by the purchaser.
*/
public long desiredQty( );
/**
* Returns the unit price desired by the purchaser.
*/
public Money desiredUnitPrice( );
/**
* Returns the date the purchaser desires to receive the product.
*/
public Calendar desiredDate( );
}.

The information entered in portlet 706 can be delivered through portal manager 155 to QPA pipeline component 530. Pipeline component 530 can communicate with SPI 235 (e.g., Purchase Manager) to deliver QPA requests to integration framework 115. PC 530 can call SPI 235, invoking a query method such as the queueQPA( ) implementation method of SPI 235.

QueueQPA( ) can convert the QPA request to an XML document representing the order at step 618. In one embodiment, queueQPA( ) calls an XML helper to generate the XML representation. The XML representation can be sent to event queue 175 at step 620. In one embodiment, the XML representation of the order is sent as a JMS XML message and event queue 175 is a JMS queue.

Workflow 545 in BPM 125 can be subscribed to event queue 175 such that event processor 135 can retrieve the XML representation of the QPA request for processing. Upon retrieval of the XML message, workflow 545 can be initiated or a workflow event listened to by a running instance of workflow 545 can be triggered at step 622. After retrieval of the message from event queue 175, workflow 545 can invoke workflow 550 within business-to-business integration 120 (B2Bi), passing it the QPA request XML document and initiating a QPA conversation.

B2Bi 120 can communicate with suppliers 140 using a number of standards-based business protocols depending on a collaboration agreement with the suppliers. For example, in one embodiment, the eXtensible Open Collaboration Protocol (XOCP) is used for communication between integration framework 115 and suppliers 140. In other embodiments, RosettaNet, cXML, and ebXML messages can also be used.

If XOCP is used; workflow 550 can pack the QPA request XML document into an XOCP message for distribution to suppliers 140 at step 624. B2Bi 120 can route the message to the various suppliers 140, based on the registered collaboration agreements with the suppliers at step 626. In one embodiment, a third workflow 555 is invoked to route the message to the suppliers. Suppliers 140 can receive the XOCP message and extract the QPA request XML document. The receipt of the message can initiate private workflows within the suppliers' systems designed to create QPA responses. Each supplier's QPA response can be created as an XML document. The suppliers can pack the QPA response XML document into an XOCP message that can be sent to integration framework 115 and on to B2Bi 120.

Public workflow 550 can receive the XOCP message from the suppliers and extract the QPA response XML document at step 628. In one embodiment, workflow 555 is used to receive the XOCP message from the suppliers and route it to workflow 550. If more than one QPA response is received in the XOCP message workflow 550 can aggregate the response documents into a single XML document and post the document, using a JMS queue for example, to private workflow 545. The QPA conversation can then be terminated and public workflow 550 notified. Workflow 545 can receive the aggregated QPA response XML document and write it to an XML file. The XML file can be passed from integration framework to portal framework 150 where portal manager 155 can update the quotes for price and availability portlet 710 with the response information at step 630 as illustrated in FIG. 7d. In one embodiment, a quote pipeline component can be invoked to create Quote objects from the aggregated XML file that can be displayed in portlet 710. The pipeline component can invoke an XML helper to parse the XML file.

The user can access portlet 710 and review the QPA responses, accept one of the suppliers' QPA response, and choose to create a purchase order at step 632. Portal framework 150 can update purchase order for review portlet 712 to indicate the selected QPA response at step 634 as illustrated in FIG. 7e.

Pipeline component 540 can deliver the purchase order data to integration component 115 using SPI 235. For example, by using a purchase order method such as the queuePO( ) implementation method, a Quote object can be sent from PC 540 to SPI 235. An exemplary Quote object can be implemented as shown below.

package examples.e2e.b2b;
import com.bea.commerce.ebusiness.price.quote.Money;
/**
* Represents a query for price and availability that is to be communicated
* to supplier(s).
* @author Copyright (c) 2002 by BEA Systems, Inc. All Rights Reserved.
*/
public interface Quote {
/**
* Returns the identifier for the QPA that precipitated this quote.
*/
public String requestId( );
/**
* Returns the identifier for this quote.
*/
public String quoteId( );
/**
* Returns the date this QPA was created.
*/
public Calendar qpaCreationDate( );
/**
* Returns the date this quote was generated by the supplier.
*/
public Calendar quoteDate( );
/**
* Returns the name of the supplier who sent this quote.
*/
public String supplierName( );
/**
* Returns the identifier for the product quoted.
*/
public String productId( );
/**
* Returns a description for the product quoted.
*/
public String description( );
/**
* Returns the quantity of the product promised by the supplier.
*/
public long quotedQty( );
/**
* Returns the unit price quoted by the supplier.
*/
public Money quotedUnitPrice( );
/**
* Returns the date promised by the supplier.
*/
public Calendar promiseDate( );
}.

QueuePO( ) can call an XML helper to create an XML representation of the Quote object at step 636. The XML document can be posted to event queue 175 at step 638. In one embodiment, the XML document is transmitted as a JMS message and event queue 175 is a JMS queue. The posting of the XML document can invoke workflow 545 in business process management 125 at step 640. Workflow 545 can invoke purchase order (PO) private workflow 560 which can invoke PO public workflow 565. PO public workflow 565 can wrap the XML document into an XOCP message or other agreed format at step 642. The XOCP message can be sent to the appropriate supplier, initiating a PO conversation at step 644. In one embodiment, the XOCP message invokes a public workflow for the suppliers that extracts the PO XML document and starts the selected supplier's private workflow by passing it the XML document.

Upon receipt of the XML document, the supplier's private workflow can translate the XML PO data into binary data or another suitable data format, generate a PO acknowledgment, translate the acknowledgment to an XML document, and pass the document to the suppliers' public workflow. The suppliers' public workflow can wrap the XML acknowledgment in an XOCP message that can be sent to public workflow 565 where the XML content can be extracted from the XOCP message and an XML event sent to private workflow 560, ending the PO conversation at step 646. Workflow 560 can write the PO acknowledgment information to an XML file as well as update the PO information within enterprise information systems. The XML file can be passed from integration framework 115 to portal framework 150 where portal manager 155 can update purchase order history portlet 714, as illustrated in FIG. 7f (step 648). Portlet 714 can display a pending status until the acknowledgment is received. In one embodiment, a PO status pipeline component can be invoked to create PO objects from the XML file generated by workflow 560 to be used in order history portlet 714. The pipeline component can invoke an XML helper to parse the XML file. An exemplary PO object can be implemented as shown below.

package examples.e2e.b2b;
import com.bea.commerce.ebusiness.price.quote.Money;
/**
* Represents a query for price and availability that is to be
communicated
* to supplier(s).
* @author Copyright (c) 2002 by BEA Systems, Inc. All
Rights Reserved.
*/
public interface PO {
/**
* Returns the identifier for this purchase order.
*/
public Dytinh poNumber( )f;
/**
* Returns the date this PO was created.
*/
public Calendar creationDate( );
/**
* Returns the status of this PO. This value is generally
* one of Pending, Acknowledged, Shipped or Received.
*/
public String status( );
/**
* Returns the name of the supplier associated with this PO.
*/
public String supplierName( );
/**
* Returns the identifier for the product supplied.
*/
public String productId( );
/**
* Returns a description for the product supplied.
*/
public String description( );
/**
* Returns the quantity of the product supplied.
*/
public long qty( );
/**
* Returns the unit price for each item supplied.
*/
public Money unitPrice( );
/**
* Returns the date promised by the supplier.
*/
public Calendar promiseDate( );
/**
* Returns the total cost for the PO.
*/
public Money total( );
}.

The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to one of ordinary skill in the relevant arts. For example, steps performed in the embodiments of the invention disclosed can be performed in alternate orders, certain steps can be omitted, and additional steps can be added. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the claims and their equivalence.

One embodiment may be implemented using a conventional general purpose or a specialized digital computer or microprocessor(s) programmed according to the teachings of the present disclosure, as will be apparent to those skilled in the computer art. Appropriate software coding can readily be prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art. The invention may also be implemented by the preparation of integrated circuits or by interconnecting an appropriate network of conventional component circuits, as will be readily apparent to those skilled in the art.

One embodiment includes a computer program product which is a storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the features presented herein. The storage medium can include, but is not limited to, any type of disk including floppy disks, optical discs, DVD, CD-ROMs, microdrive, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, flash memory devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of media or device suitable for storing instructions and/or data.

Stored on any one of the computer readable medium (media), the present invention includes software for controlling both the hardware of the general purpose/specialized computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the present invention. Such software may include, but is not limited to, device drivers, operating systems, execution environments/containers, and user applications.

Claims

1. A method for performing an electronic business transaction, comprising: receiving a request for the availability of a product through a portal, the portal generated using a portal framework;converting the request to an XML-based document;passing the XML-based document to an integration framework;placing the XML-based document into a request message configured for communication using a predetermined protocol;passing the request message using the predetermined protocol to at least one supplier system;receiving a response message from the at least one supplier system containing an XML-based response document;extracting the XML-based response document from the response message;passing the XML-based response document to the portal framework; andupdating the portal with information from the XML-based response document.

2. A computer-readable storage medium including code to: receive a request for the availability of a product through a portal, the portal generated using a portal framework;convert the request to an XML-based document;pass the XML-based document to an integration framework;place the XML-based document into a request message configured for communication using a predetermined protocol;pass the request message using the predetermined protocol to at least one supplier system;receive a response message from the at least one supplier system containing an XML-based response document;extract the XML-based response document from the response message;pass the XML-based response document to the portal framework; andupdate the portal with information from the XML-based response document.