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.
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.
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.
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.
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
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.
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
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.
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.
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.
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,
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.
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.
In the example illustrated in
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.
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.
In the example illustrated in
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.
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.
Number | Date | Country | |
---|---|---|---|
60471237 | May 2003 | US |
Number | Date | Country | |
---|---|---|---|
Parent | PCT/EP04/05211 | May 2004 | US |
Child | 11045548 | Jan 2005 | US |