WO2003034182A2

WO2003034182A2 - System and method for invoking business functionality for a workflow

Info

Publication number: WO2003034182A2
Application number: PCT/US2002/033183
Authority: WO
Inventors: Mitch Upton
Original assignee: Bea Systems, Inc.
Priority date: 2001-10-18
Filing date: 2002-10-17
Publication date: 2003-04-24
Also published as: AU2002347919A1; JP2005506618A; WO2003044661A1; WO2003034183A3; CN1585948A; WO2003034183A2; WO2003034182A3; AU2002347926A1; EP1444609A4; WO2003034228A1; AU2002347927A1; EP1444609A1; WO2003034285A1

Abstract

An application view component can represent a business-level interface to business functionality in an application or enterprise system. An application view component can be configured for, and can contain services related to, a single business purpose. Business-relevant data can be specified in the request document for these services, and can return business-relevant data in a response document. An application view component can combine this business-relevant data with stored metadata necessary for a resource adapter for the enterprise system. The adapter can take the combined data and execute a system-level business function. A business process management component can allow the application view component to be invoked as a business service. 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 obteined from a review of the specification, the figures, and the claims.

Description

SYSTEM AND METHOD FOR INVOKING BUSINESS FUNCTIONALITY FOR A WORKFLOW

CLAIM OF PRIORITY

This application claims priority to the following applications each of which is hereby incorporated herein by reference:

U.S. Provisional Patent Application No. 60/347,919, filed October 18, 2001 , entitled "APPLICATION VIEW".

U.S. Provisional Application No. 60/347,901 , filed October 18, 2001 , entitled "EVENT ADAPTER".

U.S. Patent Application No. entitled "APPLICATION VIEW

COMPONENT FOR SYSTEM INTEGRATION," by Mitch Upton, filed October 15, 2002.

U.S. Patent Application No. entitled "SYSTEM AND

METHOD FOR INVOKING BUSINESS FUNCTIONALITY FOR A WORKFLOW," by Mitch Upton, filed October 15, 2002.

U.S. Patent Application No. entitled "SYSTEM AND METHOD FOR IMPLEMENTING AN EVENT ADAPTER," by Mitch Upton, filed October 15, 2002.

U.S. Patent Application No. entitled "SYSTEM AND

METHOD USING A CONNECTOR ARCHITECTURE FOR APPLICATION INTEGRATION," by Mitch Upton, filed October 15, 2002. U.S. Patent Application No. entitled "SYSTEM AND

METHOD FOR IMPLEMENTING A SCHEMA OBJECT MODEL IN APPLICATION INTEGRATION," by Mitch Upton, filed October 15, 2002.

U.S. Patent Application No. entitled "SYSTEM AND

METHOD UTILIZING AN INTERFACE COMPONENT TO QUERY A DOCUMENT," by Mitch Upton, filed October 15, 2002.

U.S. Patent Application No. entitled "SYSTEM AND METHOD USING ASYNCHRONOUS MESSAGING FOR APPLICATION

INTEGRATION," by Mitch Upton, filed October 15, 2002.

U.S. Patent Application No. entitled "SYSTEM AND

METHOD FOR IMPLEMENTING A SERVICE ADAPTER," by Mitch Upton, filed October 15, 2002.

COPYRIGHT NOTICE A portion ofthe 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 No. entitled "APPLICATION VIEW

COMPONENT FOR SYSTEM INTEGRATION," by Mitch Upton, filed October 15, 2002.

U.S. Patent Application No. entitled "SYSTEM AND

METHOD FOR PROVIDING A JAVA INTERFACE TO AN APPLICATION VIEW COMPONENT," by Mitch Upton, filed October 15, 2002.

U.S. Patent Application No. entitled "SYSTEM AND

METHOD FOR USING WEB SERVICES WITH AN ENTERPRISE SYSTEM," by Mitch Upton, filed October 15, 2002.

U.S. Patent Application No. entitled "SYSTEM AND

METHOD FOR IMPLEMENTING AN EVENT ADAPTER," by Mitch Upton, filed October 15, 2002.

U.S. Patent Application No. entitled "SYSTEM AND

METHOD USING A CONNECTOR ARCHITECTURE FOR APPLICATION INTEGRATION," by Mitch Upton, filed October 15, 2002.

U.S. Patent Application No. entitled "SYSTEM AND

U.S. Patent Application No. entitled "SYSTEM AND METHOD UTILIZING AN INTERFACE COMPONENT TO QUERY A

DOCUMENT," by Mitch Upton, filed October 15, 2002.

U.S. Patent Application No. entitled "SYSTEM AND

METHOD USING ASYNCHRONOUS MESSAGING FOR APPLICATION INTEGRATION," by Mitch Upton, filed October 15, 2002. U.S. Patent Application No. entitled "SYSTEMS AND

METHODS FOR INTEGRATION ADAPTER SECURITY," by Mitch Upton, filed October 15, 2002.

U.S. Patent Application No. entitled "SYSTEM AND

TECHNICAL FIELD The invention relates generally to the management of business processes in integrating applications.

BACKGROUND E-commerce has become a major driving factor in the new economy. To be successful in the long-term, e-commerce will require many companies to engage in cross-enterprise collaborations. To achieve cross-enterprise integration, a company must first integrate its internal applications. Using existing technology and tools, application integration can be an expensive proposition. No integration solution exists that is easy to use, affordable, and based on industry standards. Neither does a solution exist that is based on an industry standard infrastructure, has universal connectivity, is capable of massive scalability, and has accessible business process tools.

Application integration to this point has been very inward-focused.

Many existing integration systems have not focused on integrating applications between enterprises. Even when integration solutions were used for cross-enterprise integration, the solutions were still narrowly focused and aimed at vertical markets. This inward focus did little to help companies field 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 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.

The first attempts at application integration were primarily focused on low-level implementation details such as the format ofthe data, the byte ordering between machines, and character encoding. The focus on low- level data formats was necessary because, for the first generation of application integration solutions, there were no widely adopted standards for data encoding that could be deployed across multiple vertical applications.

The traditional approach involved connecting individual systems to, in effect, hardwire the systems together. This approach can be complex, as connecting different systems can require an intimate, low-level knowledge of the proprietary technologies of multiple systems.

Present integration systems, which have moved away from "hardwiring" systems together, still suffer from a lack of standards. Each integration vendor typically provides a proprietary solution for application integration, message transformation, message formats, message transport, and routing. Not one of these systems to date has achieved significant market share to enable its technologies to become the de-facto standard. This lack of standards has given packaged application vendors little incentive to integrate these systems with their. Further, each of these integration systems or servers has its own proprietary API, such that packaged application vendors cannot leverage development beyond a single integration server. This fragmentation ofthe integration market has provided little financial incentive for third parties.

BRIEF SUMMARY

Systems and methods in accordance with embodiments of the present invention can allow functionality in an enterprise system or application to be exposed, such as to a business workflow. An application view component can be used to provide a business-focused interface to an enterprise system, such as for a client application. An application view component can be configured for, and can contain services related to, a single business purpose. Business-relevant data can be specified in the request document for these services, and can return business-relevant data in a response document. An application view component can combine this business-relevant data with stored metadata necessary for a resource adapter for the enterprise system. The adapter can take the combined data and execute a system-level business function. The resource adapter can be used to invoke functionality in the enterprise system and expose that functionality to the application view component. A business process management component can allow the application view component to be invoked as a business sen/ice.

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 Figure 1 is a diagram of an integration system that can be used in accordance with one embodiment of the present invention. Figure 2 is a diagram of a system including a business process management component that can be used in accordance with another embodiment of the invention.

Figure 3 shows a method that can be used with the system of Figure

Figure 4 shows another method that can be used with the systems of Figures 1 and 2.

DETAILED DESCRIPTION

Application integration components can be used to integrate a variety of applications and systems, such as Enterprise Information Systems (EISs). Information technology (IT) organizations typically utilize several highly-specialized applications. Without a common integration platform to facilitate application-level integration, these applications cannot be integrated without extensive, highly-specialized development efforts.

Application integration can utilize adapters 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 being integrated with every other application.

The development and widespread acceptance of standards such as the Java 2 Platform, Enterprise Edition (J2EE)from Sun Microsystems, Inc. of Santa Clara, CA, 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 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.

Application integration can build on this standardized approach in an application integration framework by providing a standards-based architecture for hosting J2EE Connector architecture-based adapters.

Developers can build J2EE Connector architecture-compliant adapters and deploy these adapters, in the integration framework, to connect enterprise applications to an application server.

These adapters can be used to define business-focused interfaces to an EIS, the interfaces referred to herein as "application views" of the respective adapters. An application view can provide a simple, self- describing, consistent interface to services and events in an application. Application views can make use of an adapter for an EIS, making it possible to expose existing information systems as business sen/ices.

Unlike adapters, however, an application view does not require users to have intimate knowledge ofthe EIS orthe client interface for that EIS, such that non-programmers or technical analysts can use application views. An application view can provide a business-oriented way for business analysts to access enterprise data without worrying about the programmatic details defined in an adapter. These same users may be otherwise unable to use an adapter directly, due to a lack of familiarity with the EIS.

An application integration component directed at enterprise application integration can have several primary aspects. If the functionality of an EIS such as a PeopleSoft system or an SAP system is to be invoked, an implementation ofthe 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.

Application Views

An application view can provide significant value to an application integration component. An application view can abstract away much ofthe complexity in dealing with an application, such as a backend EIS system. Application views can also 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 layer of abstraction formed by application views can help non-programmers maintain the services and events exposed by an adapter. Each application view can be specific to a single adapter, and can define a set of business functions on that adapter's

EIS. After an adapter is created, a Web-based interface for the adapter can be used to define application views.

If an application view is used as a primary user interface for an adapter, a number of features can be included that are not commonly found in existing enterprise application integration technologies. Application views can, for example, use XML as a common language among applications. Sen/ice and event definitions can be used to expose application capabilities. XML schemas can be used to define the data for services and events. Bidirectional communication can also be supported in adapters.

An application view can be an integral part of an integration framework. An application view can provide a view of the application capabilities exposed by an adapter that a user can customize to meet specific needs. A user can tailor an application view, for example, for a specific business purpose. As a result, the application view can provide an effective alternative to the "one size fits all" approach that many applications provide for the design of a client interface. An application view can be defined for only the business or other capabilities that are applicable for a specific purpose. The capabilities can be customized such as by naming, describing, and defining the data requirements.

In one example of a system using a resource adapter and application view component, shown in Figure 1 , adapters 106, 108, 110 can be developed that allow a client application 100 to communicate with an Enterprise Information System 104 through the use of an application view 102. A developer can begin by coding an adapter that exposes the functionality in the enterprise application that accesses enterprise data.

The functionality the adapter exposes could, for example, update records in a database using SQL statements, or could request information from an SAP system using its BAPI or I DOC interfaces. A business analyst, working with the developer, can then define an application view of the adapter using an application view interface.

An example of a system using a business process management component is shown in Figure 2. In this figure, a client application 200 can communicate with an EIS 210 through an integration server 202. The integration server can be, for example, a web server or application server, and can be included in a cluster or integration system, represented here by the dotted line. The integration server can include an application view component 206 and a resource adapter 208 for the EIS 210. A business process management component 204 can be included that allows the application view 206 to be invoked as a business service.

A method for using such a system is shown in Figure 3. A request can be passed to a business process management component to invoke a business service for an enterprise system 300. The request may not directly invoke the sen/ice, but may instead start a workflow that has a node that will trigger the invoking of the service. An application view component, which acts as a business-focused interface to an application or enterprise system, can then be invoked as a business service, hiding the internal functionality of the enterprise system 302. That business functionality can be invoked in the enterprise system and exposed to the application view component through a resource adapter for that enterprise system 304.

In Figure 4, for example, a workflow is defined for a business process 400. That workflow can be started, such as by a client application

402. An event can be triggered by a node in the workflow, such as an event node or task node 404. A business service, which can be represented by an application view component, can be invoked in response to the event 406. The corresponding business functionality, which may be in an enterprise system, for example, can then be exposed to the business service 408.

An application view is an object, which can be implemented in one embodiment as a stateless session JavaBean. There can be a Java interface to the application view for the client application. A Java application can be custom coded to use that object, such as by passing XML in and receiving XML back. In addition, a business process management component can be included that allows process engineers to define workflows, and can allow application views to be invoked as business services. A workflow can be a graphical representation of a business process, which can be defined and modified using, for example, a business process management (BPM) component such as a BPM plug- in, as well as a business process engine. In a workflow, a callout can be made to an EIS to get information such as a customer's credit record. The fact that the application view is a Java object or enterprise JavaBean can be hidden from the process and/or designer.

In application integration, new application views can be hot- deployed against an existing EIS through a web-based interface. An application view is hot-deployed when it is deployed with the system running, without restarting the destination server. A new customer management tool for SAP, for example, can also be defined through a web browser.

Integration Framework

Application integration can utilize an integration framework, which can provide a systematic, standards-based architecture for hosting application views. Features of such a framework can include application views for exposing application functions and design-time graphical user interfaces (GUIs), such as web-based interfaces that can be used for creating application views. The integration framework can utilize adapters, instead of "hardwiring" enterprise systems together. Once an adapter is deployed for an EIS, other components and applications can use that adapter to access data on the EIS. A framework in accordance with one embodiment of the present invention relies on XML as the standard format for messages. XML includes XSLT, a standard fortransforming XML documents into other XML documents. XSLT is designed for use as part of XSL, which is a stylesheet language for XML. In XSLT, an XML document is used to specify the operations to perform on a class of XML documents in order to transform the documents' structure and content. An XSLT transformation can make use of any of the operations built into the Java programming language, or can make use of custom operations written either in Java or in native code. An integration framework allows a business process to invoke an XSLT engine in order to transform XML messages.

An integration framework can also rely on standards for transporting messages such as Java Message Service (JMS) and HTTPS. JMS is a standard API for interfacing with message transport systems. Using JMS, a framework can utilize any message transport mechanism that provides a JMS interface. The J2EE Connector architecture standard does not specify a message transport mechanism, but an application integration framework can specify such a transport mechanism.

An integration framework can be based on an existing standard infrastructure, such as an application serverthat supports J2EE, JMS, and the J2EE Connector architecture. Using such a standard infrastructure also provides for high availability and scalability, such as by clustering and resource pooling. The framework can provide for universal connectivity by enabling the construction of XML-based application adapters that can connect to any legacy and packaged application. An adapter development kit can be used to allow users such as customers, system integrators, and packaged application vendors to quickly develop J2EE connector architecture-compliant and integration framework-based adapters. The framework can utilize XML, which means that the same data format can be used for both within- and between-enterprise integration, since many e- commerce systems use XML as the standard message format.

An integration framework can also utilize a business-process engine to allow non-programmers to graphically construct and maintain business processes. An integration framework can implement a common model on top of the J2EE Connector architecture that is focused on business-level concepts. This model, which can consist of XML-encoded events and services, allows the management of a consistent integration environment, regardless of the interface required between adapters and their target applications. The business processes can react to events generated by applications, and they can invoke an application's functionality via services that are exposed by an application adapter.

Business Process Management

One way to use an application view with business processes for an enterprise is to design a workflow using a business process management (BPM) component. A BPM component can provide a GUI-based environment for designing business process workflows. These workflows can include application view services and events defined using application integration.

There can be at least four ways to use an application view in a workflow using BPM. For instance, a task node can be set up to call an application view service. Alternatively, an event node can be set up to wait for a response from an asynchronous application view service. A workflow can also be created that is started by an application view event. An event node can be set up to wait for an application view event. If BPM is not used, an alternate way to use an application view in an enterprise is to write custom Java code to implement a business process.

For each business process implemented, an implementation method can be selected. While any business process can be implemented as a workflow by using BPM, it may be undesirable to custom code a business process unless it is simple and/or specialized.

It can be advantageous to use a BPM component to implement a business process in certain situations. One situation in which it can be advantageous to use BPM to implement a business process occurs when implementation would require complicated error management, persistent processes, and sophisticated conditional branching. For example, if a business process receives events, selects only a subset of the events, performs complex branched actions, then generates many complex messages and sends the messages to a variety of application server clients, it can be advantageous to use BPM to implement the business process.

BPM can also be used when only occasional changes need to be made to a business process. BPM can reduce the number of compile/test/debug cycles. BPM can also be used when, as in many organizations, developers are valuable and scarce.

Certain prerequisites can be met before a user invokes an application view service or receives an application view event in BPM. First, a user may need to have created an application view and defined services and events for the application view. Also, the application view and its adapter may need to be functional and saved somewhere on the system. If the user is planning to call application view services and events from a running workflow, the application view should be deployed as well. In some embodiments both BPM and application integration should be running, and the application integration plug-in should be loaded. The user may wish to obtain information about any required business logic for the workflows being defined. This information can come from a business analyst, for example. Also, a workflow template definition can be opened.

After creating the necessary application view services and events for an enterprise, a user can use those application views to execute business processes. BPM can be used to design business process workflows that use the application view services and events. BPM can provide a GUI-based environment for designing business process workflows. These workflows can include application view services and events defined using application integration.

There are at least four primary ways to use application view services and events in BPM. One way is to set up a task node to call an application view service. Another way is to set up an event node to wait for a response from an asynchronous application view service. Another way involves creating a workflow started by an application view event. Finally, an event mode can be set up to wait for an application view event. These scenarios can be used in combination with each other to create personalized workflows.

Business Example

In an example of an application view useful for exposing a business interface to an application, an application view object can be created with a name that reflects its business purpose, and within a namespace that describes its place within the organizational structure ofthe business. The resulting application view can satisfy the business data requirements and can perform the proper interaction with applications. Users of the application view can include business analysts, technical analysts, and subject matter experts. A business analyst can decide that which will be the business purpose of the application view. A technical analyst can decide which application is best suited to the purpose for the application view. The technical analyst can enlist the help of the subject matter, or application, expert to assist in defining the application view by offering application expertise, and by possibly modifying the application or its metadata to meet the needs of the application view. The adapter for the application selected by the technical analyst can already be installed, as well as the appropriate JSP-based design-time GUI. The server hosting the adapter and the design-time interface should also be up and running before creating a new application view.

The basic flow and alternate flows for the application view can assume that the business analyst, technical analyst, and subject matter expert are all interacting during the creation/definition of the application view. This may not always be the case. If each user is instead taking a turn reviewing the current state of the application view, the flow of events could take the form of multiple passes through the flow of events, with each pass representing only the single user interactions.

In one basic flow, a technical analyst can open a web browser and point to the URL for the adapter design-time interface. The technical analyst and business analyst can decide the business organization under which the application view belongs, and can verify that an appropriate application view namespace exists. This can be done using a namespace browser tree on the home page of an adapter design-time interface. If no appropriate namespace exists, the namespace can be created using a namespace browser. A technical analyst and a business analyst can agree on a name for an application view that reflects the business purpose for the application view. The technical analyst can create a new application view within the identified namespace and give it the agreed-upon name. The business analyst can give a brief description of the application view's business purpose and the technical analyst can type it into the description field ofthe new application view. The set of events and services for the application view can be reviewed and edited, if necessary. The technical analyst can then save the new application view. At this point, the application view can be saved for later use, tested, or deployed into the runtime application view engine.

Business Approach

If a business analyst or technical analyst defines an application view using an adapter, the application view can be customized for a specific business purpose defined by the business analyst. For example, if defining a "customer management" application view on an adapter for a Customer Relationship Management (CRM) system, services and events related to customer management can be added. Application views can be created that are as inclusive as necessary. Because application views can be customized for a specific business purpose, application views can work much better than the "one size fits all" approach used by many other enterprise application integration systems.

A business-level view of an application's capabilities can provide a logical separation between the programmer and the technical analyst. For example, this abstraction can enable a technical analyst to create records in a database without having to know SQL. Workflow

In an organization, there may be situations in which a user wants to call an application view service from within a workflow. To do this, a task node can be added to the workflow, with an appropriate application view service action being added to the task node. Once the workflow is saved and activated, the application view service can be called whenever the task node executes.

In order to set up a task node to call an application view service, certain steps can be followed to create a task node that calls an application view service. First, a template definition can be opened. A task node can be created if it does not already exist. A task node can be selected that can call the application view service, such as by double-clicking on the particular task node. An "actions" area can be displayed from which a user can select a service to be called. The choice can depend on the business processes.

At this point, an application view service can be called. A "call service" dialog box or other data entry panel can be displayed from which a user can select a service to be called. A navigation tree can be used to organize application view services by folder, such as a folder called EastCoast.Sales, and by application view, such as an application view called CustomerManagement. All application view services can be positioned at the lowest level of the navigation tree. From a "request document variable" list, a user can select an existing XML variable that contains the input data for the application view service.

A "service request template" dialog box can display a template to apply to all service requests of this type. This template can be based on the input schema for the service. When this action executes, the template data can be assigned to the specified request document variable and used as the input document for the sen/ice. This template can override any previous setting for the variable. If the user wishes to examine the XML schema of the input document, the user can choose to view a request definition.

A user may also want to create a workflow that starts whenever a designated application view event occurs. To set a workflow to be started by an application view event, a user can edit the workflow's start node to respond to an event of type "Al Start," for example, and can then select the appropriate application view event. If necessary, the user can set conditions upon which to filter the event. After saving and activating the workflow, the start node can execute each time the application view event occurs.

In order to create a workflow started by an application view event, certain steps can be followed to set up a workflow with a start node that is triggered by an application view event. A user can open a template definition and create a start node if one does not already exist. This start node can respond to a specified application view event. The user can specify an application view event. If necessary, the user can filter the event such as by entering a condition. The user can select an XML variable, such as from an event document variable list. When the start node receives data from the application view event, this variable can be used to store the data. If no suitable XML variable exists, the user can create a new variable.

In a workflow, a user may want to create an event node that is triggered by an application view event. To set up an event node to respond to an application view event, the event node can be edited so it responds to an event of type "Al Event", for example, and the appropriate application view event can be selected. If necessary, conditions can be set on which to filter the application view event. After saving and activating the workflow, the workflow can progress to this event node, wait for a specified application view event, and continue processing.

A developer may want to modify an application view by writing custom code. Many application view features can be accessed by using, for example, a Web-based GUI, but there are some application view features that can used only by custom coding. These can include connecting using specific credentials and custom coding a business process.

When exporting a workflow that utilizes application integration, a BPM export tool can automatically identify the application views and other resources the workflow depends on. To fully export an application view, a user can select all entities that are related to the application view.

Synchronous Approach

In order to call an application view synchronously, a user can select a "synchronous" option from the appropriate application view console A node that synchronously calls a service can be configured to wait for a service to return a response document before the workflow can continue. If the node were to asynchronously call a service, the workflow would be able to continue. For synchronous services that require storage of the response, a user can select a predefined XML variable, such as from a

"response document variable" list. When BPM receives the response from the application view service, the response document variable can store the response. If a user does not care about the response data, the user can leave this field empty. If no suitable XML variable exists, a user can select an option to create a new XML variable. If it is necessary to examine the XML schema of the response document, the user can view the response definition.

Asynchronous Approach

For asynchronous services, such as may require storage of the request ID, a predefined string variable can be selected from an application view console. If no suitable string variable exists, a "variable properties" dialog box can be opened where a new string variable can be created. When a task node is set up to call an asynchronous application view service, the result can be returned to BPM. A workflow can identify this response using the selected request ID variable. To set an event node to receive the response, the same request ID variable can be used for the event node.

A user may wish to set up an event mode to wait for a response from an asynchronous application view service. In a workflow, whenever an action calls an application view service asynchronously, the application view service can return a response. Normally, if the user wants to know about the response, the user may want to set up a corresponding asynchronous event node to wait for the response. To configure an asynchronous event node to wait for a response from an asynchronous application view service, an event node can be created with the event node being set to wait for an event, such as an event of type "Async Response."

There are at least two primary methods that can be used to set up the event node to receive the asynchronous service response in this embodiment. In a first method, a user can select a "response document" option. When using this method, a user can receive an asynchronous service response by selecting the request ID variable and a response document variable. The request ID variable is a string and the response document variable is of type XML. A second method uses an "asynchronous variable" option. When using this method, the asynchronous service response can be received by selecting the request ID variable and an asynchronous service response variable. The request

ID variable can be a string and the asynchronous service response variable can be of a type such as "AsyncServiceResponse." A preferred method may be the response document method, as it can provide a universal means of receiving both asynchronous and synchronous responses. When using the response document method, an XML document can be received regardless of whether the response is asynchronous or synchronous, and it will not be necessary to query the value of the asynchronous service response variable.

A response document variable can be used to receive asynchronous service responses whenever possible. Whenever an "event properties" dialog box is set to wait for an event of the asynchronous response type, a user can choose to use an asynchronous variable to receive the response. If an asynchronous response event node is edited that was previously set up to use an asynchronous service response variable to receive the response, then two options can be displayed in an event properties dialog box: an asynchronous variable option and a response document option. In this case, a user can select one of the two methods to receive the service response.

If an existing asynchronous response event node is edited that does not use an asynchronous service response variable or a new asynchronous event node is created, an event properties dialog box can display a dialog box that will allow a user to set a response document to receive the service response. Although this scenario does not handle errors returned in the application view service response, a user may want to handle errors in specific user workflows. To handle asynchronous service response errors in these workflows that may use, for example, an AsyncServiceResponse variable, a user can use features included in an application integration plug-in. An application integration plug-in can include a variable type such as AsyncServiceResponse and functions such as AIHasError(), AIGetErrorMsgO, and AIGetResponseDocument().

To set up an asynchronous event node to wait for a response from an asynchronous application view service, an event node can be created and set to wait for an event of a type such as "Al Async Response." Steps for setting an event node to use an XML variable to receive an asynchronous sen/ice response can include, first, opening a workflow template definition. A user can create an event node if one does not already exist, which will wait for an asynchronous response from a designated application view service. The user can select an already- defined string variable, and BPM will listen for an asynchronous response with an ID matching this variable.

The event node can wait for a response to an action, such as a call to an application view service, that was called asynchronously earlier in the workflow. The "call application view service" action can set the request ID variable. To make the action and this event node work together, they can both use the same request ID variable.

For asynchronous services that require storage of the response, a user can select a predefined XML variable, such as from a response document variable list. When BPM receives the response from the application view service, the response document variable can be used to store the response. If no suitable XML variable exists, the user can create a new variable. A preferred method for receiving an asynchronous service response may be to use a response document variable of type XML. However, if an existing workflow contains an asynchronous event node that was previously set to use an AsyncServiceResponse variable to wait for a response from an asynchronous application view service, a user can modify the event node.

If an event mode uses an AsyncServiceResponse variable to receive an asynchronous service response, one approach to modifying the event mode uses the following steps. A workflow template definition is opened and an asynchronous variable type selected. A user selects an already-defined string variable, and BPM listens for an asynchronous response with an ID matching this variable.

Callback Listener

A client can choose to invoke a service asynchronously if it is a long- running service. For instance, some SAP requests can take about two or three minutes to process. The processing of the request usually happens transparent to the client. If the user is sitting at a web page, it can be undesirable for the page to simply "hang" for two minutes without doing anything. It may be preferable to issue some sort of response, then update the web page once the proper response is received, such as a new message from SAP. This is one reason for using a callback listener for asynchronous responses. In this way, a client does not want to have to wait around for a response, but will instead be notified when the response is received by the callback listener.

A listen and receive event is another valuable part of certain embodiments in accordance with the present invention, as a listen and receive event is not addressed in the J2EE Connector architecture. A trigger can occur in an EIS, and external applications may need to know about the firing of the trigger. In other words, an event occurs that needs to be propagated out to certain applications. Any registered listeners may need to be notified as well.

As before, a client can create an application view and can add an event listener. A handler is created that knows what to do once it receives an event from the application view. The application view in one embodiment subscribes to a JMS topic and registers the listener on that topic. A JMS topic is a JMS feature to which JMS messages can be posted, similar to an inbox.

There can be a defined object, or application integration component, called an "event generator." The job ofthe event generator is to watch and communicate with the EIS to determine when an event occurs. For a DBMS adapter, this can involve a query on a staging table. A user can make a request, such as "select * from event." Any record in that event table will be a record of a new event in the DBMS. The event generator can periodically look to the EIS for new events.

For example, when an order processing system is running low on an item in inventory, an event can result the system triggering a notification that it needs to restock a certain product. This event can happen, for example, in an EIS. Triggers can be used for DBMS. Once an insert occurs on a certain table, a trigger can fire and place information about the new data into the event table, such as by using an "insert into event..." statement. Then, once a new event occurs, the event generator can pull that event. Plug-ins

Plug-ins can be useful to extend or add functionality to application integration. When using an application integration plug-in, functions such as, for example, AI HasErrorQ, AI G etErrorMsgO, and AIGetResponseDocumentO can be used to interrogate application integration response variables, where applicable. If an application integration plug-in is installed in BPM, a user can be given access to any of these functions. Using these functions, decision nodes can be configured to handle success and failure conditions. In some embodiments, these functions support only an asynchronous variable method for receiving asynchronous service responses.

Another plug-in function such as AIHasError() can be used to determine the status of an asynchronous service response. A function such as AIGetErrorMsgO can be used to retrieve the error message string returned by an asynchronous application view service. A function such as AIGetResponseDocumentO can be used to retrieve the actual XML response document returned by an asynchronous application view service.

Custom Coding

In certain situations, it may be advantageous for a user to custom code portions ofthe application integration solution. In a simple example, business logic can be implemented where an enterprise has a customer relationship management (CRM) system and an order processing (OP) system. A business process can be desired that coordinates the synchronization of customer information between these two systems. The creation of a customer on the CRM system can trigger the creation of a corresponding customer record on the OP system. A Java class such as "SyncCustomerlnformation" can be custom coded by the userto implement this business logic.

This example demonstrates some basic steps that can be taken when implementing an organization's business processes, using an example class called SyncCustomerlnformation. In general, two steps can be used to create custom code that uses an application view in a business process. First, a user can make sure that a Java class exists to represent the application implementing the business process. Then, within this Java class, the user can supply the code to implement the business logic.

For one embodiment, the following prerequisites should be met before creating custom code to implement a business process. First, an application view should be created, with one or more events or services being defined within the application view. A user can obtain information about the required business logic for the business process workflow being defined. This information can come, for example, from a business analyst.

In addition, this particular scenario assumes certain prerequisites are already complete. One assumption is that application views for the source CRM system and the target OP system are defined and working. Also assumed is that both application views exist. When writing custom code, a Java class can exist to represent each application required for the business process. The necessary Java classes can be created if they already exist.

A reference can be obtained to a namespace manager and application view manager within an application server. This can be accomplished by using a JNDI (Java Naming and Directory Interface) lookup. Using a namespace manager, a reference can be obtained to the "root" namespace by calling a method such as "getRootNamespace()." Using a root variable, a reference can be obtained to the East Coast namespace by calling "root.getNamespaceObject." A temporary reference can be obtained to the customer management application view and the reference can be stored into a variable called "custMgmtHandle."

This custMgmtHandle temporary reference can be used to obtain an actual reference to an application view instance for customer management.

This can be accomplished by calling the application view manager as

"avm.getApplicationViewlnstance (custMgmtHandle.getQualifiedName())."

The returned reference can be stored into a variable called custMgmt.

The user can begin listening for "new customer" events by calling

"custMgmt.addEventListenerfNew Customer", listener)," where "listener" is an object that can respond to "new customer" events. An "onEvent" method of the listener class can also be implemented. When a "new customer" event is received, the onEvent method of the listener can be called. The onEvent method should then call a method to respond to the event. In this example, the onEvent method provides the event object that contains the data associated with the event. This method, called "handleNewCustomer," can be implemented to respond to the New Customer event.

Application View as a Business-Level Interface

A key component of one embodiment of an application integration component is an application view. An application view can represent a business-level interface to the specific functionality in an application. An adapter, on the other hand, can represent a system-level interface to all the functionality in the application. An application view can be configured for a single business purpose and can contain services related to that business purpose. These services can require only business-relevant data to be specified in the request document and return only business-relevant data in the response document. An application view can combine this business-relevant data with stored metadata necessary for the adapter. The adapter can take both the business-relevant data and the stored metadata, and can execute a system-level function on the application.

The application view can represent both events and services that support a business purpose. This can allow a business userto interact with the application view for all communication with an application. This bi- directional communication can be supported by an event adapter and a service adapter. An application view can abstract this fact from the user and present the user with a unified business interface to the application.

Service as a Business Operation A service can be a business operation within an application that is exposed by the application view. The service can exist as a request/response mechanism. When an application receives a request to invoke a business service, the application view can invoke that functionality within its target application and return, or respond with, an XML document that describes the results. To define a service, a user may need to determine and define the input requirements, output expectations, and the content ofthe interaction specification.

The foregoing description of preferred embodiments of the present invention has been provided forthe 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 art. 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 following claims and their equivalence.

Claims

What is claimed is:

1. A system for managing workflow for application integration, comprising: an application view component adapted to provide an interface to a resource for the client application; a resource adapter adapted to invoke functionality in the resource and expose that functionality to the application view component; and a process management component adapted to allow the application view component to be invoked as a sen/ice.

2. A system according to claim 1 , wherein: the application view component is adapted to provide a business- focused interface.

3. A system according to claim 1 , wherein: the application view component is adapted to provide an interface to an enterprise system for the client application.

4. A system according to claim 1 , wherein: the process management component is a business process management component adapted to allow the application view component to be invoked as a business service.

5. A system according to claim 1 , wherein: the application view component is further adapted to provide a business-oriented way to access data in the resource.

6. A system according to claim 3, wherein: the application view component is further adapted to define a set of business functions on the enterprise system.

7. A system according to claim 1 , wherein: the application view component is a stateless session bean.

8. A system according to claim 1 , further comprising: a Java interface to the application view component, the Java interface allowing a Java application to pass XML to and from the resource.

9. A system according to claim 3, wherein: the business process management component is further adapted to provide a GUI-based environment for designing business process workflows, the workflow capable of including application view events and services.

10. A system according to claim 1 , further comprising: an enterprise system adapted to receive and send XML in response to a request from a client application.

11. A system according to claim 1 , further comprising: a client application adapted to make requests.

12. A system according to claim 1 , further comprising: a workflow adapted to call the process management component to invoke the service.

13. A system according to claim 12, wherein: the workflow includes a task node capable of calling the process management component to invoke the service.

14. A system according to claim 12, wherein: the workflow includes an event node adapted to wait for a response from an asynchronous instance of the service.

15. A system according to claim 12, wherein: the workflow includes an event node adapted to wait for an application view event.

16. A system according to claim 12, wherein: the workflow is adapted to be started by an application view event.

17. A system according to claim 1 , further comprising: a process engine adapted to allow the graphical construction and maintenance of business processes, the business processes adapted to invoke functionality in an application through the functionality exposed by the resource adapter in response to an event generated by the client application.

18. A system according to claim 1 , wherein: the process management component is adapted to manage a business process to perform tasks selected from the group consisting of receiving events, selecting a subset of events, performing complex branched actions, generating complex messages, and sending the complex messages to application server clients.

19. A system according to claim 1 , wherein: the process management component is adapted to compile, test, and debug a business process.

20. A system according to claim 1 , wherein: the process management component is adapted to create a workflow.

21. A method for managing workflow for application integration, comprising: deploying an application view component for an enterprise system, the application view component adapted to provide a business-focused interface to the enterprise system; defining services and events for the application view such that the application view can be invoked as a business service; and designating at least one node in the workflow adapted to invoke the application view as a business service.

22. A method according to claim 21 , further comprising: obtaining any required business logic for the workflow.

23. A method according to claim 21 , further comprising: defining the workflow using a business process management component.

24. A method for invoking enterprise system functionality from a workflow, comprising: creating a task node in a workflow; associating the task node with an application view component for a particular enterprise system, the application view component capable of being invoked as a service to expose functionality in the enterprise system; and invoking the service from the task node.

25. A method according to claim 24, further comprising: defining a set of business functions on the enterprise system.

26. A method for invoking business functionality for a workflow, comprising: passing a request to a business process management component to invoke a business service for an enterprise system; invoking an application view component adapted to provide a business-focused interface to the enterprise system; and exposing business functionality in the enterprise system to the application view component using a resource adapter.

27. A method for invoking business functionality for a workflow, comprising starting a business workflow containing at least one node; invoking a business service in response to an event triggered by the node; and exposing business functionality to the business service.

28. A computer-readable medium, comprising: means for calling a business service from a workflow; and means for invoking functionality in an enterprise system and exposing that functionality through the business service.

29. A computer program product for execution by a server computer for invoking business functionality, comprising: computer code for calling a business service from a workflow; and computer code for invoking functionality in an enterprise system and exposing that functionality through the business service.

30. A system for invoking business functionality, comprising: means for calling a business service from a workflow; and means for invoking functionality in an enterprise system and exposing that functionality through the business service.

31. A computer system comprising: a processor; object code executed by said processor, said object code configured to: call a business service from a workflow; and invoke functionality in an enterprise system and expose that functionality through the business service.

32. A computer data signal embodied in a transmission medium, comprising: a code segment including instructions to call a business sen/ice from a workflow; and a code segment including instructions to invoke functionality in an enterprise system and expose that functionality through the business service.