Subprocesses and user interactions for a business process management integration server

Abstract

A process may be executed at an integration server adapted to provide a messaging service for at least two business applications in an enterprise system. According to some embodiments, a subprocess may be called during execution of the process (and other processes may also call the subprocess). According to other embodiments, input may be received from a user (and further execution of the process may be based at least in part on the received input).

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of International Application PCT/EP2004/005211, with an International filing date of May 14, 2004, now pending; and claims the benefit of priority of U.S. Provisional Patent Application No. 60/471,237 filed May 16, 2003.

FIELD

Some embodiments of the present invention relate to enterprise systems. In particular, some embodiments are associated with a messaging service for business applications in an enterprise system.

BACKGROUND

An enterprise may implement systems, architectures, and techniques for collaborative business processes. In many cases, a company will directly connect components in a one-to-one relationship with other components, and the integration capabilities are hardwired into the application components and mapping programs. For example, a purchase order system might notify a warehouse shipping system when an order is approved. Based on the notification, the shipping system might cause a product to be delivered and notify an invoicing system (e.g., so that an invoice can be generated and mailed to a customer). With such an approach, managing the collaborative sharing of information can be difficult. For example, it might be difficult to update the various components to accurately represent changing business processes.

In addition, networks such as the Internet are providing opportunities for systems to communicate both inside and outside enterprise boundaries. For example, Web services (e.g., programmable, self-contained, self-describing, modular application functions that can be published, discovered or invoked through an open Internet standard) may provide collaboration opportunities for systems to communicate with each other. However, comprehensive system upgrades of existing enterprise software and/or large-scale replacement strategies in heterogeneous system landscapes might be too costly or otherwise unfeasible in terms of the time required to perform the upgrades.

While technical connectivity may be provided using open protocols and standard like the Hyper-Text Transfer Protocol (HTTP) and extensible Markup Language (XML), the challenge of mapping different business semantics remains. To capture future rounds of efficiency gains, an enterprise may need to deploy new collaborative business processes that cross enterprises or functions within an enterprise. In addition, enterprises may need to process and manage real-time scenarios instead of performing batch processing.

Whichever approach is taken with respect to enterprise system integration, certain costs will be associated with the development of new systems and/or upgrades to existing systems. Approaches that may reduce such costs may be desirable. Moreover, it may advantageous to provide a system flexible enough to respond to circumstances that are not anticipated or known when the system is designed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an enterprise system according to some embodiments.

FIG. 2 is a block diagram of an exchange infrastructure and a number of components according to some embodiments.

FIG. 3 is a block diagram of an exchange infrastructure according to some embodiments.

FIG. 4 is a message flow diagram according to some embodiments.

FIG. 5 illustrates interactions between a process engine domain and workflow domains according to some embodiments.

FIG. 6 illustrates message mapping between an integration process and business systems according to some embodiments.

FIG. 7 illustrates several types of business process flows according to some embodiments.

FIG. 8 is a flow diagram of process steps pursuant to some embodiments.

FIG. 9 illustrates a process calling a subprocess according to some embodiments.

FIG. 10 is a high-level logical block diagram of an integration server according to some embodiments.

FIG. 11 is a more detailed logical block diagram of an integration server according to some embodiments.

FIG. 12 illustrates message mapping between a process, a subprocess, and business systems according to some embodiments.

FIG. 13 illustrates a cancellation of a subprocess and a nested subprocess according to some embodiments.

FIG. 14 is a flow diagram of process steps pursuant to some embodiments.

FIG. 15 illustrates a process receiving input from a user according to some embodiments.

FIG. 16 is a high-level logical block diagram of an integration server according to some embodiments.

FIG. 17 is a more detailed logical block diagram of an integration server according to some embodiments.

DETAILED DESCRIPTION

To alleviate problems inherent in the prior art, some embodiments of the present invention introduce systems, methods, computer program code and means for management of business processes and a message communication protocol between applications in a heterogeneous system landscape. The business process management system and method might be implemented, for example, in an exchange infrastructure configured to integrate and drive collaboration between various applications in the landscape using open standards and transport protocols such as HTTP and XML.

FIG. 1 is a block diagram of an enterprise system 10 according to some embodiments. The system may, for example, provide for the integration and message-based interaction of applications. The system 10 includes an exchange infrastructure 100 for collaborative processing among internal components 20 of an enterprise, and between external components 30 that communicate with one or more internal components 20 through a firewall 40. The internal components 20 and external components 30 may represent any of a number of processes or services and their software and hardware, such as Web portals, buying or selling programs, electronic mail, business management programs, and project planning programs. According to some embodiments, each internal component 20 and external component 30 communicates via messaging with one or more other components according to at least one of a number of communication protocols or standards.

The exchange infrastructure 100 may be a self-contained, modularized exchange platform for driving collaboration among the components 20, 30. The exchange infrastructure 100 may include, for example, a central integration repository and directory storing shared collaboration knowledge. The exchange infrastructure 100 may also support open standards such as various standard markup languages like the extensible Markup Language (XML), Web Service Description Language (WSDL), and Simple Object Access Protocol (SOAP) to provide an abstraction of technical interfaces for the components 20, 30, and for message-based communications across heterogeneous component interfaces. The self contained, modularized functions of the exchange infrastructure 100 might be provided as one or more Web services based on standard Internet technology, and thus be published, discovered, and accessed within a network of components 20, using open standards.

FIG. 2 is a block diagram of an exchange infrastructure 200 and a number of component applications 270 according to some embodiments. To facilitate message-based collaboration among the applications 270, the exchange infrastructure 200 may include an integration repository 210, an integration directory 220, a system landscape directory 240, and an integration server 230. The integration repository 210 may capture design-time collaboration descriptions of all software components that can communicate via the exchange infrastructure 100. The integration directory 220 may capture configuration-specific collaboration descriptions of the system landscape at runtime, which may include accessing actual component installations from the system landscape directory 240 and connectivity descriptions for external components, all of which represents the shared business semantics of the system landscape. The integration server 230 may use shared business semantics at runtime to execute message-based collaboration among the active software components (e.g., associated with the applications 270).

The integration server 230 may include a runtime engine 234 that provides messaging and business process control at runtime for connecting services and managing the process flow of value chains. A business process management system 232 may reside on the integration server 230 below the runtime engine 234. The business process management system 232 may, for example, include a business process engine (not illustrated in FIG. 2) that runs on top of the runtime engine 234 for runtime execution of business process management.

The integration server 230 may also include integration services 236 that typically require an application-specific implementation. Like the integration repository 210 and integration directory 220, the integration server 230 may be configured for deployment within any existing system infrastructure. In some cases, the integration server 230 may be a dedicated server that applies the shared collaboration knowledge of the integration directory 220 of the supported system landscape in a runtime collaboration environment. A runtime workbench may allow organizations or users to manage the reliable operation of the exchange infrastructure 100.

The exchange infrastructure 100 may also include various adapters 250 that provide connectivity between the integration server 230 and various applications 270 (e.g., proprietary applications, Web-based services, and/or third party applications). The exchange infrastructure 100 might also include a Web applications server that provides Web-based applications programmed according to standard computing platforms using web-specific programming languages such as Java. In some cases, an adapter 260 could be implemented external to the exchange infrastructure 200.

FIG. 3 illustrates an exchange infrastructure 300, including an integration repository 310, a system landscape directory 340, an integration directory 320 and an instantiation of the runtime engine 330 in greater detail. The integration repository 310 may include design-time business processes, routing objects, mappings, and interfaces, all of which are defined according to one or more business scenarios. The integration repository 310 may access descriptions of software components in the system landscape from the system landscape directory 340. The business scenarios of the integration repository 310 may, for example, describe and configure message-based interaction between application components or enterprises. An enterprise can select one or more business scenarios described in the integration repository 310 for rapid configuration of the exchange infrastructure 300.

The business processes can be implemented as extensible compound Web services executed using a business process engine, and each business process may modeled centrally in the integration repository 310. A company or user might designs each business process according to its business needs, independently of the technical implementation. There may be several categories of business process templates (e.g., generic business processes, industry-specific processes, and company-specific processes). Each process may identify the Web services that need to be interconnected.

In one specific implementation, business processes are defined using a graphical interface. The graphical business process definition language is defined according to the Business Process Execution Language for Web Services (BPEL4WS) 1.1 specification. Business processes may be exported into and imported from a standardized format (e.g., the BPEL4WS 1.1 specification). An extensible import/export framework might also provide export/export facilities for other standards or new versions of BPEL4WS. A business process engine 334 can then interpret these models and execute them to drive collaboration among software components.

The routing objects might comprise predefined criteria to determine potential receivers of messages that must be distributed between components and business partners during collaborative processing. Information about the routing objects may be used for receiver determination to avoid having to process a complete message before distribution. The mappings may define required transformations between message interfaces, message types, or data types in the integration repository 310. These transformations cover structural conversions and value mappings. Structural conversions are used for semantically equivalent types that are syntactically or structurally different, whereas value mapping may be used when an object is identified by different keys in multiple systems. In a specific implementation, a graphical mapping tool is provided to assist in mapping, and transforming data is based on the Extensible Stylesheet Language Transformation (XSLT) technique or Java code.

The integration repository 310 may be the central point of entry for interface development, storage and retrieval, and includes interfaces that describe message interfaces of software components in the system landscape. Note that the interfaces might be implemented on any software component using any technology.

Message interfaces may include message types, which are in turn made up of data types. The data types can be described using XML Schema Definition Language (XSDL). An example of a data type is “address,” which is used in the message type “Create PO” and can be reused for the message type “Create Invoice.” The interfaces might be arranged according to any classification, such as inbound, outbound and abstract, or synchronous and asynchronous.

The components in the system landscape director 340 may represent component descriptions that include information about application components, as well as information relating to their dependencies on each other. In a specific implementation, the component descriptions are based on the standard Common Information Model (CIM) of the Distributed Management Taskforce (DMT). Since the integration repository 310 includes design-time information, only component-type information, independent of actual installation, might be stored as components 340. The component descriptions can be added using an API or interactively using a graphical user interface.

The integration directory 320 details information from the integration repository 310 that is specific to the configuration of each component as installed in the system.

The configuration-specific collaboration descriptions of the integration directory 320 might be generated automatically from content in the integration repository 310 or manually by a user using a graphical user interface. In one implementation, the integration directory 320 is built on a Java platform and its content is represented via XML using open Internet standards. Note that the integration repository 310 might be upgraded without affecting the integration directory 320 or any runtime collaborative processes. The user then decides which changes should be transferred to the integration directory 320, either as predetermined automatic upgrades or manually via graphical tools.

The integration directory 320 can include configuration-specific descriptions of business scenarios, business processes, context objects, and executable mappings. The integration directory 320 may also include descriptions of active Web services and active business partners. The integration directory 320 may use a description of the active system landscape from the system landscape directory 340. The business scenarios in the integration directory 320 might represent the overall view of the interaction among interfaces and mappings in the context of the actual configuration relevant for the specific implementation. The business processes may represent an executable description of all active business processes.

The context objects might determine the receivers of a message on a business level. In one specific implementation, the content of a message is used as a context object. Note that other parameters may also be used.

Relevant input parameters might include the sender, the sender message type, the message to identify the receivers, and the receiver message type. The context object can be described declaratively, for example, using XML Path Language (Xpath) by using a graphical tool or can be coded in Java. The integration engine 330 at runtime accesses information on the context object.

The context objects may use logical terms to describe senders and receivers in order to separate them from the physical address provided by the Web services described in the integration directory. The physical address can therefore be changed without changing business oriented content. The mappings in the integration directory 320 might represent mappings required in the active system landscape, in contrast to the integration repository mappings that contains all supported mappings. Some new entries however, such as a new sequence of mappings, could be made only in the integration directory 320 (e.g., to address additional Web services for mapping). The integration runtime engine 330 accesses the integration directory mappings at runtime.

The context objects may provide a unique name for accessing semantically identical payload information. For instance, a context object can provide a unique access name for “plant” for an invoice and purchase order. The XPath for a plant in an invoice can be defined as “/A/B/C/plant” while the XPath for “plant” in a purchase order may be “X/Y/Z/work.” As a result, the context object “plant” is assigned to the message interface invoice and purchase order where these XPaths are specified. This may help ensure that the XPath for “plant” is not defined at multiple places.

The Web services in the integration directory 320 might describe interfaces implemented within the current active system landscape, as well as active Web services supported by described business partners. As such, information describing Web services can be exchanged with Universal Description, Discovery, and Integration (UDDI) compatible directories. Note that information describing Web services might also be added manually.

Each Web service description in the integration director 320 may also provide physical addressing details, access information, and other special attributes such as Uniform Resource Locator (URL), protocol, and security information. In one implementation, the Web services are described in WSDL, and SOAP and ebXML are used as messaging protocols. The integration runtime engine 330 accesses information about the Web services at runtime.

The system landscape of the system landscape directory 340 may describe the current system landscape that uses the exchange infrastructure 300. The system landscape might, for example, describe the components that are installed and available on certain machines within the system, the instance or client that was chosen, further information on the installed components, and/or other system landscapes. The system landscape description is based on an open architecture and can adhere to any widely accepted standard such as CIM. Thus, many proprietary and third party components can be configured to automatically register themselves in the system landscape upon being installed within the actual system landscape. Access interfaces to the system landscape description can be based on open standards as well, such as the Web-Based Enterprise Management (WBEM) and SOAP standards.

The business partners in the integration director 320 may define information for business partners of an enterprise, such as names, addresses, and URLs. The partners may also contain more detailed and sophisticated information. For example, the business partners may include a description of the message formats that can be directly received and processed, of security protocols used for safe communications, or trading terms that are employed in the partnership. The kind of information stored in business partners can be governed by enterprise-specific decisions of the enterprise using the exchange infrastructure 300.

The integration directory 320 and the runtime engine 330 form a collaborative runtime environment for executing collaborative business processes. The collaborative runtime environment may provide runtime components relevant for exchanging messages among the connected software components and business partners. The integration server 330 executes the collaborative runtime environment or Web application server, either of which can include an instance of the runtime engine 330 in accordance with informational resources provided by the integration directory 320.

The runtime engine 330, which exchanges all messages between the various interconnected components includes two layers: an integration layer 332 and a messaging and transport layer 336. The integration layer 332 includes a business process engine 334 executing centrally modeled business processes, a logical routing service and a mapping service. The messaging and transport layer 336 provides a physical address resolution service, a messaging and queuing service, a transport service via HTTP, and a database (described with respect to FIG. 4) to support the runtime engine 330.

The messaging and transport layer 336 may be included in each instantiation of the runtime engine 330 in Web applications servers 310, as well as in each adapter of the adapter framework connecting to various software components.

At runtime, business processes are instantiated and executed by the business process engine 334, which executes the respective Web services described in Web services independent of their location according to the business process model. The business process engine 334 may be independent of the semantics of the executed business processes, and may be configured as a mediator and facilitator for business processes to interact with technical components of the runtime system landscape.

FIG. 4 is a message flow diagram illustrating several functions of an exchange infrastructure 400 while exchanging a message between applications according to some embodiments. A sending application resides in a sending component system 410, which represents the hardware and software platform of the sending application. One or more receiving applications each reside in a receiving component system 420, 430.

A communication path for a message 310 can include an outbound proxy at the outbound interface from the sending component system 410, through a runtime engine and adapter of the exchange infrastructure 400 to a receiving component system 420, 430. Note that a receiving component system 420, 430 might also utilize an inbound proxy or an adapter.

For a given message, the logical routing service uses information about the sending application and the message interface to determine receivers and required interfaces by evaluating the corresponding routing rules. The routing rules may be part of the configuration-specific descriptions of the runtime system landscape provided by the integration directory 320, and can be implemented as XPath expressions or Java code. The mapping service determines the required transformations that depend on message, sender, and sender interface, as well as the receiver and receiver interface. In the case of asynchronous communication, even the message direction might be determined to appropriately transform input, output, and fault messages.

After retrieving the required mapping from the integration directory 320, the mapping service can either execute XSLT mappings or Java code (or any combination in a given sequence) to the content of the sent message. Below the integration layer, messaging, queuing, and transport services move the message to the intended or required receiver(s). After the message is transformed into the format expected by each receiver, the physical address of the required receiver service and other relevant attributes are retrieved from the integration directory 320 and mapped to the message.

A queuing engine (not shown) in the messaging and queuing service may store ingoing, outgoing, erroneous, and low work-in-progress messages persistently. The messaging layer 336 of the runtime engine 310 may provide queuing functions for the physical decoupling of application components and guarantees messages are delivered exactly once according to a protocol.

The transport service may let the runtime engine 310 act as both a client and server. For example, the transport service may implement a client that enables outbound communication and a server that handles inbound communication by accepting incoming documents. Additional server functions can address situations in which the receiver has no server by supporting polling over the transport protocol used. HTTP is used, but other transport protocols may be used as well.

According to some embodiments, a process definition module utilizes XML objects and correlations to define processes, based on deployment rules imported from objects from the integration directory 320. The objects are based on the routings and mappings defined for the system runtime configuration. The objects may also be used to define business processes in the integration repository 310 and the design-time configuration of the system landscape. The business processes may be integrated with other integration repository 310 objects and tools, which allows links to and from other objects. Moreover, processes (e.g., patterns and templates) may be delivered to customers along with extension concepts. Application specific content can also be delivered. Some applications can create processes and/or extensions that can be delivered to customers. According to some embodiments, a business process management system includes an import/export framework that imports and exports standards-based adapters for universal connectivity. Such a system may also include an interface for receiving user-specified business process details.

Business process modeling scenarios are also known as modeling patterns (or simply, “patterns”). The following patterns are high-level building blocks, and may be combined with each other and/or atomic process engine functions:

1) Send and Receive: Sending messages controlled by the process engine is often combined with receive steps that wait for a correlated response message. A receive step may wait for the messages starting with the activation of the associated correlation as a queuing mechanism.

2) Serialization: This pattern might include the following steps: 1. Receive messages and store them locally in the process data context; 2. Keep the data context and lo start sending received messages when a certain condition has been fulfilled; and 3. Send received messages in a given order respecting dependencies of receivers. The third step can further be described as: a. Without caring about responses/acknowledgements (“fire and forget”); or b. Receiving a response or an acknowledgement (to enable serialization). The process engine can be configured to wait for a technical ACK of or business response from a previously-sent message before sending a next message.

3) Transformations/Merge/Split: The process engine transforms messages within the process context. The following transformations can be performed: 1. (N:1) Transform several collected messages to one new message (e.g. transform several invoices to one combined invoice); 2. (1:N) Transform one message into several other messages (e.g. transform a combined invoice to invoices associated with multiple purchase orders); and 3. (1:1) is a special case of the transformations described above. Note that N:M mappings would also be possible if needed.

4) Multicast: The process engine can be configured to calculate the receivers of a message (also using content-based conditions) and to send the message to these receivers, either without regard to responses or acknowledgements (“fire and forget”) or based on receiving a number of responses or acknowledgements. According to some embodiments, messages may be sent out in parallel or sequentially.

5) Collect: This pattern may use receive steps in which an arbitrary number of messages can be received. From a process point of view, the end of the collecting scenario can be defined via a “push,” (e.g., when a certain condition is reached, such as N messages have arrived or a certain deadline has been reached), or a “poll’ in which the process engine waits for a special message that indicates the end of collecting.

FIG. 5 illustrates interactions 500 between a process engine domain and workflow domains according to some embodiments. In particular, an integration server is orchestrating interactions between a first, second, and third application systems. The integration server may be, for example, a standalone component that communicates via messages with the client application systems. Message related functions (e.g., send, create, transformation, merge, and split) may be realized by service calls to a messaging layer of the integration server. For example, the integration server might wait until messages are received from both the first application system and the second application system before it transmits a message to the third application system.

FIG. 6 illustrates message mapping between an integration process and business systems according to some embodiments. In the figure, Ox represents an outbound interface (e.g., O4 is outbound interface 4) and Rx represents an inbound receiving interface. Initially, the integration process receives through R4 a message from a first business system. As a result of that message, the integration process transmits a message to a third business system through O1. After the integration process receives a response from the third business system through O2, a message is transmitted to a second business system through O5.

FIG. 7 illustrates several types of business process flows according to some embodiments. In the sequential scenario, multiple receive steps are waiting for messages of the same interface. The messages arrive at different points in time (TI and T2) and the receive steps begin to wait at correlation activation. The semantics are as follows: each receive gets its own (different) message; the first message completes the first receive step and the second message completes the second receive step; the first message does not complete both (or more) receive steps. This action may avoid race conditions and help to ensure that no message is lost.

In the loop scenario, a receive step is waiting within a loop for messages through the same interface. The messages arrive at different points in time (T1 and T2) and the receive step begins to wait at correlation activation. The semantics are as follows: if no receive step consumes an arriving message, the process will cache the message; if a receive step is reached, the “oldest” message is fetched out of the cache and the receive step completes; if the process reaches a receive step and the cache is empty, the process waits until a new message arrives. Such a “loop” approach may, for example, help realize a collect scenario.

The parallel scenario covers the situation in which two receive steps are waiting for the same message through the same interface in parallel. The messages arrive at different points in times (TI and T2) and both receive steps begin to wait at correlation activation. The semantics are as follows: the first message does not complete both receives steps; each receive step gets its own message, and the order can be arbitrary.

A send step may be used to send a message that is already available within a process. Executing a send step, the process engine submits the (outbound) message to a pipeline for processing. The receivers for a message to be sent can be determined or specified via routing configuration in the directory, or directly by process definition.

By defining receive steps, send steps, and other steps (e.g., to transform information), a process can be defined to facilitate collaboration between business applications in an enterprise. Note that a substantial amount of effort may be required to define a process. For example, a task may need to be analyzed and, based on the analysis, appropriate steps may need to be defined and tested before the process can be used by an enterprise. Also note that some tasks may need to be performed by more than one business process. For example, a task associated with looking up information in a data warehouse might need to be performed during both an accounting process and a human resource process.

FIG. 8 is a flow diagram of process steps pursuant to some embodiments. The flow charts described herein do not necessarily imply a fixed order to the actions, and embodiments may be performed in any order that is practicable. Note that any of the methods described herein may be performed by hardware, software (including microcode), firmware, or any combination of these approaches. For example, a storage medium may store thereon instructions that when executed by a machine result in performance according to any of the embodiments described herein.

At 802, a first process is executed at an integration server adapted to provide a messaging service for at least two business applications in an enterprise system. The messaging service might be, for example, associated with any of the embodiments described herein. For example, the messaging service might provide: (i) a logical routing of a message, (ii) a mapping of a message from a first business application to a second business application, and/or (iii) a physical address resolution of a business application. During execution of the first process, a subprocess is called to perform a task at 804. Note that the subprocess may also be called by a second process at the integration server.

For example, FIG. 9 illustrates a process 910 calling a subprocess 920 according to some embodiments. That is, during execution of the process 910 a step is reached in which the subprocess 920 is called. According to some embodiments, input data may be provided to the subprocess 920 during this step. Note that the call might be performed by a send step of the process 910 that transmits a message to a receive step of the subprocess 920. Moreover, the send step may instantiate a correlation. According to some embodiments, a “call subprocess” step may be used to start the subprocess.

The subprocess 920 may then perform a task (e.g., looking up information in a data warehouse). When the subprocess 920 completes the task, response data may be provided to the process 910 (e.g., information from the data warehouse might be provided to the process 910). Note that response data might be included in a message transmitted by a send step of the subprocess 920 to a receive step of the process 910.

According to some embodiments, execution of the process 910 is blocked or halted when the subprocess 920 is called. In this case, execution of the process 910 might resume when the subprocess 920 completes the task (e.g., and provides the response data to the process 910).

Note that the subprocess 920 may also be called by any number of different processes. In this way, the time, effort, and costs associated with re-defining and re-testing the steps needed to perform the same task can be avoided.

FIG. 10 is a high-level logical block diagram of an integration server 1000 according to some embodiments. In particular, an integration process is defined in an integration repository that contains a set of design-time business messaging service processes. According to some embodiments, a subprocess is also defined in the repository. The integration process and subprocess may, for example, be defined generically without enterprise-specific routing information.

According to some embodiments, a signature associated with the process is declared in the repository. The signature may, for example, represent the inbound and outbound messages used by the process (e.g., IF1 and IF2). A signature associated with the subprocess may also be declared in the repository (e.g., IF3 and IF4).

A configured process service may then be created in an integration directory along with a configured subprocess service. The configured process and subprocess services may, for example, include enterprise-specific message routing information. According to some embodiments, the signatures that were declared in the repository may be passed to the integration directory (e.g., IF1 t through IF4).

The configured process service may then be activated in a runtime engine associated with the integration server. During execution of the process, according to some embodiments, the subprocess may be called (e.g., semantically synchronously) and activated. Note that execution of the process might be blocked while the subprocess performs a task (e.g., asynchronously). When the subprocess completes the task, the process may resume execution.

FIG. 11 is a more detailed logical block diagram of an integration server 1100 according to some embodiments. As before, an integration process is defined in an integration repository that contains a set of design-time business messaging service processes. According to some embodiments, a subprocess is also defined in the repository. The integration process and subprocess may, for example, be defined generically without enterprise-specific routing information.

In the example illustrated in FIG. 11, the process includes an “IF” statement with two branches, each containing a Sub-Process Call (SPC). According to some embodiments, a configurable parameter may be declared in the integration process. Moreover, the configurable parameter may be used to assign a subprocess to a variable (e.g., subprocess 1 might be assigned to P_SP1 and subprocess 2 might be assigned to P_SP2). Thus, if the IF statement will result in either subprocess 1 or subprocess 2 being called.

A configured process service may then be created in an integration directory along with a configured subprocess service. The configured process and subprocess services may, for example, include enterprise-specific URLs and other message routing information. According to some embodiments, the configurable parameters that were declared in the repository may be passed to the integration directory (with the subprocesses being placed on the variables).

The configured process service may then be activated in a runtime engine associated with the integration server. At this time, the subprocesses may be directly assigned to the subprocess calls of the IF statement. During execution of the process, one the subprocess will be called and activated. Note that execution of the process might be blocked while the subprocess performs a task (e.g., to save cache memory). When the subprocess completes the task, the process will resume.

FIG. 12 illustrates message mapping between a process, a subprocess, and business systems according to some embodiments. As with FIG. 6, Ox represents an outbound interface and Rx represents an inbound receiving interface. Initially, the integration process receives through R4 a message from a first business system. As a result of that message, the integration process calls a subprocess to perform a task (illustrated by a dotted line in FIG. 12). The subprocess sends a message to a third business system through O4 and receives a message back from the third business system through R4. The subprocess completes the task and the integration resumes operation by transmitting a message to a second business system through O5.

FIG. 13 illustrates nested subprocesses according to some embodiments. That is, the integration process calls a first subprocess which in turn calls a second subprocess. Note that execution of the first subprocess might be blocked while the second subprocess is performing a task.

FIG. 13 also illustrates cancellation of a subprocess before the subprocess completes a task. In particular, the integration process is executing two branches in parallel, and one of the branches has called the first subprocess (which in turn has called the second subprocess). In this case, an event in other branch (e.g., reaching the join node first) might result in the cancellation of the branch that called the subprocess. Such an “implicit” cancellation may be automatically cascaded to the first and second subprocesses.

According to some embodiments, an exception can be raised to let the process logic signal a business fault. For example, an application exception might be explicitly thrown by the process logic or a system exception might be thrown by the process engine.

Exception handlers can be defined for the existing exceptions within their scope. Throwing an exception can be handled as follows. First, an exception handler is found for the exception name. The inner block that surrounds the throw command is first searched; if the exception handler cannot be found in the surrounding block, go to next higher block, and so on as long as the exception handler cannot be found (exception propagating). Second, all active steps within the block that carries the exception handler are stopped. If the handler is found in a parent block, this block with all active steps will be stopped. Third, the exception handler is started and the steps within the exception handier are executed. Fourth, at the end of the exception handler, the block (in which the exception handler is defined) is completed as normal. If an exception cannot be handled in one of the blocks, the process will go to an error state.

In the case of an exception generated by a subprocess, the exception may be provided to the calling process which will map the exception to one of an exception within its own block and handle it as appropriate. That is, a subprocess can have a set of exceptions that can be propagated to the calling process. According to some embodiments, a subprocess may handle some exceptions locally and/or terminate if an exception cannot be handled.

Although many aspects of collaboration between business applications may be automated, in some cases a decision by a user may be required to properly handle a situation. For example, it might be helpful to have a business user or a system administrator review a particular error to determine if a process should be halted or allowed to continue.

FIG. 14 is a flow diagram of process steps pursuant to some embodiments. At 1402, a process is executed at an integration server adapted to provide a messaging service for at least two business applications in an enterprise system. During execution of the process, input is received from a user at 1404. For example, the integration server might display at a user workstation the following message “An unknown type of purchase order has been received. Click OK to continue this business process” along with two icons labeled “OK” and “Cancel Business Process.” The user may then activate one of the icons to provide input to the integration server. Note that further execution of the process may be based at least in part on the input received by the integration server (e.g., the business process might continue or be halted).

FIG. 15 illustrates a process 1510 receiving input from a user according to some embodiments. The integration process 1510 executes until a step is reached that requires an input from a user. At this point, it is arranged for a set of potential selections to be displayed to the user (e.g., via a generic business workplace user interface). For example, the user might be asked to select one of five displayed options. The user may then provide input (e.g., via a universal work list). For example, the user might select the first potential selection, and the selection may be passed to the integration process via a container element. The integration process will then continue to execute based at least in part on the user input (e.g., the left branch illustrated in FIG. 15 might be taken when the user selects the first potential selection while the right branch would be taken when he or she does not). In this way, a system may be provided that is flexible enough to respond to circumstances that are not anticipated or known when the system is designed (e.g., because the user may make a decision at run time).

FIG. 16 is a block diagram of an integration server 1600 according to some embodiments. In particular, an integration process is defined in an integration repository that contains a set of design-time business messaging service processes. The integration process may, for example, be defined generically without enterprise-specific routing information.

In the example illustrated in FIG. 16, the process includes an “IF” statement with two branches, each containing a User Decision (UD) step. According to some embodiments, a configurable parameter may be declared in the integration process. Moreover, the configurable parameter may be used to assign a user to a variable (e.g., PARAM1 and PARAM2).

A configured process service may then be created in an integration directory. The configured process service may, for example, include enterprise-specific URLs and other message routing information. According to some embodiments, the configurable parameters that were declared in the repository may be passed to the integration directory (with particular users or organizational units being placed on the variables). The configured process service may then be activated in a runtime engine associated with the integration server.

The embodiments described herein are solely for the purpose of illustration. Those skilled in the art will recognize other embodiments may be practiced with modifications and alterations limited only by the claims.

Claims

1. A method, comprising:

executing a first process at an integration server adapted to provide a messaging service for at least two business applications in an enterprise system; and

during execution of the first process, calling a subprocess to perform a task, wherein the subprocess may also be called by a second process at the integration server.

2. The method of claim 1, wherein execution of the first process is blocked while the subprocess performs the task, and further comprising:

continuing execution of the first process after the subprocess performs the task.

3. The method of claim 1, wherein said calling includes submitting parameters to the subprocess, and further comprising:

receiving response data from the subprocess.

4. The method of claim 1, further comprising:

defining the first process in a repository containing a set of design-time business messaging service processes; and

defining the subprocess in the repository.

5. The method of claim 4, wherein said defining includes:

declaring a signature associated with the first process, the signature being associated with inbound and outbound messages.

6. The method of claim 6, wherein said defining includes:

setting a value of a configurable parameter based on the subprocess.

7. The method of claim 6, further comprising:

creating a configured first process service in a directory; and

creating a configured subprocess service in the directory, wherein the configured subprocess service includes enterprise-specific message routing information.

8. The method of claim 7, wherein information associated with the signature and the configurable parameter are passed from the repository to the directory.

9. The method of claim 7, further comprising:

activating the configured first process service in a runtime engine associated with the integration server, wherein said executing and calling are performed by the runtime engine.

10. The method of claim 1, wherein the subprocess calls another subprocess.

11. The method of claim 1, wherein the subprocess is called semantically synchronously and performs the task asynchronously.

12. The method of claim 1, further comprising:

canceling the subprocess before the subprocess completes the task.

13. The method of claim 1, wherein the subprocess is a first subprocess and further comprising:

cascading the cancellation to a second subprocess called by the first subprocess.

14. The method of claim 1, further comprising:

mapping exceptions associated with the subprocess to the first process.

15. The method of claim 1, wherein the messaging service is associated with at least one of: (i) a logical routing of a message, (ii) a mapping of a message from a first business application to a second business application, or (iii) a physical address resolution of a business application.

16. A system, comprising:

an integration repository storing enterprise system design-time descriptions of at least two business applications, the design-time descriptions including (i) a set of design-time business processes and (ii) at least one design-time business subprocess;

an integration directory storing enterprise system configuration-specific descriptions of the business applications, the configuration-specific descriptions including (i) configuration-specific business processes to be executed between the business applications and (ii) at least one configuration-specific business subprocess to be called by multiple configuration-specific business processes; and

an integration server including a business process management runtime engine to execute a configuration-specific business process that calls the configuration-specific business subprocess.

17. A medium storing processor-executable process steps, the process steps comprising:

executing a first process at an integration server adapted to provide a messaging service for at least two business applications in an enterprise system; and

during execution of the first process, calling a subprocess to perform a task, wherein the subprocess may also be called by a second process at the integration server.

18. A method, comprising:

executing a process at an integration server adapted to provide a messaging service for at least two business applications in an enterprise system; and

during execution of the process, receiving input from a user, wherein further execution of the process is based at least in part on the received input.

19. The method of claim 18, further comprising:

displaying to the user a set of potential selections, wherein said receiving comprises receiving from the user an indication associated with at least one of the potential selections.

20. The method of claim 18, further comprising:

defining the process in a repository containing a set of design-time business messaging service processes.

21. The method of claim 20, wherein said defining includes:

declaring a configurable parameter associated with the user.

22. The method of claim 21, further comprising:

creating a configured process service in a directory, wherein the configured process service includes enterprise-specific message routing information.

23. The method of claim 22, wherein the configurable parameter is replaced with at least one of (i) a user identifier, or (ii) an organization identifier.

24. The method of claim 23, wherein information associated with the configurable parameter is passed from the repository to the directory.

25. The method of claim 24, further comprising:

activating the configured process service in a runtime engine associated with the integration server, wherein said executing is performed by the runtime engine.

26. The method of claim 18, wherein said receiving is associated with a container element.

27. A system, comprising:

an integration repository storing enterprise system design-time descriptions of at least two business applications, the design-time descriptions including a set of design-time business processes;

an integration directory storing enterprise system configuration-specific descriptions of the business applications, the configuration-specific descriptions including configuration-specific business processes to be executed between the business applications;

an integration server including a business process management runtime engine to execute a configuration-specific business process; and

a user input device to provide a response to the integration server during execution of the configuration-specific business process.

28. A medium storing processor-executable process steps, the process steps comprising:

executing a process at an integration server adapted to provide a messaging service for at least two business applications in an enterprise system; and

during execution of the process, receiving input from a user, wherein further execution of the process is based at least in part on the received input.