US20050193061A1 - Subprocesses and user interactions for a business process management integration server - Google Patents
Subprocesses and user interactions for a business process management integration server Download PDFInfo
- Publication number
- US20050193061A1 US20050193061A1 US11/045,548 US4554805A US2005193061A1 US 20050193061 A1 US20050193061 A1 US 20050193061A1 US 4554805 A US4554805 A US 4554805A US 2005193061 A1 US2005193061 A1 US 2005193061A1
- Authority
- US
- United States
- Prior art keywords
- subprocess
- business
- integration
- message
- integration server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/34—Graphical or visual programming
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
- G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/067—Enterprise or organisation modelling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/547—Messaging middleware
Definitions
- Some embodiments of the present invention relate to enterprise systems.
- 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.
- 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.
- 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).
- an invoicing system e.g., so that an invoice can be generated and mailed to a customer.
- networks such as the Internet are providing opportunities for systems to communicate both inside and outside enterprise boundaries.
- Web services e.g., programmable, self-contained, self-describing, modular application functions that can be published, discovered or invoked through an open Internet standard
- 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.
- 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.
- 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.
- 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.
- XML extensible Markup Language
- WSDL Web Service Description Language
- SOAP Simple Object Access Protocol
- 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.
- 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.
- 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.
- 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.
- 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.
- XSLT Extensible Stylesheet Language Transformation
- 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.
- 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.
- 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.
- 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.
- Xpath XML Path Language
- 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.
- 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.”
- 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.
- UDDI Universal Description, Discovery, and Integration
- 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.
- URL Uniform Resource Locator
- 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.
- WBEM Web-Based Enterprise Management
- 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.
- 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.
- 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 .
- a receiving component system 420 , 430 might also utilize an inbound proxy or an adapter.
- 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.
- 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.
- messaging, queuing, and transport services move the message to the intended or required receiver(s).
- 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.
- 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.
- 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.
- processes e.g., patterns and templates
- processes 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.
- 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.
- Patterns are high-level building blocks, and may be combined with each other and/or atomic process engine functions:
- 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.
- 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.
- 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.
- 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.
- 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.
- a push e.g., when a certain condition is reached, such as N messages have arrived or a certain deadline has been reached
- a polyl 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.
- 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
- 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.
- Ox represents an outbound interface (e.g., O 4 is outbound interface 4 ) and Rx represents an inbound receiving interface.
- the integration process receives through R 4 a message from a first business system.
- the integration process transmits a message to a third business system through O 1 .
- a message is transmitted to a second business system through O 5 .
- FIG. 7 illustrates several types of business process flows according to some embodiments.
- multiple receive steps are waiting for messages of the same interface.
- the messages arrive at different points in time (TI and T 2 ) 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.
- a receive step is waiting within a loop for messages through the same interface.
- the messages arrive at different points in time (T 1 and T 2 ) 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 T 2 ) 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.
- a process can be defined to facilitate collaboration between business applications in an enterprise.
- a substantial amount of effort may be required to define a process.
- 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.
- 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.
- any of the methods described herein may be performed by hardware, software (including microcode), firmware, or any combination of these approaches.
- a storage medium may store thereon instructions that when executed by a machine result in performance according to any of the embodiments described herein.
- 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.
- 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.
- 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.
- 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).
- a task e.g., looking up information in a data warehouse.
- response data may be provided to the process 910 (e.g., information from the data warehouse might be provided to the process 910 ).
- 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 .
- 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 ).
- 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.
- an integration process is defined in an integration repository that contains a set of design-time business messaging service processes.
- a subprocess is also defined in the repository.
- the integration process and subprocess may, for example, be defined generically without enterprise-specific routing information.
- 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., IF 1 and IF 2 ).
- a signature associated with the subprocess may also be declared in the repository (e.g., IF 3 and IF 4 ).
- 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.
- the signatures that were declared in the repository may be passed to the integration directory (e.g., IF 1 t through IF 4 ).
- the configured process service may then be activated in a runtime engine associated with the integration server.
- 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.
- an integration process is defined in an integration repository that contains a set of design-time business messaging service processes.
- a subprocess is also defined in the repository.
- the integration process and subprocess may, for example, be defined generically without enterprise-specific routing information.
- the process includes an “IF” statement with two branches, each containing a Sub-Process Call (SPC).
- a configurable parameter may be declared in the integration process.
- the configurable parameter may be used to assign a subprocess to a variable (e.g., subprocess 1 might be assigned to P_SP 1 and subprocess 2 might be assigned to P_SP 2 ).
- subprocess 1 might be assigned to P_SP 1
- subprocess 2 might be assigned to P_SP 2 .
- 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.
- 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.
- the subprocesses may be directly assigned to the subprocess calls of the IF statement.
- 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).
- the process will resume.
- FIG. 12 illustrates message mapping between a process, a subprocess, and business systems according to some embodiments.
- Ox represents an outbound interface
- Rx represents an inbound receiving interface.
- the integration process receives through R 4 a message from a first business system.
- 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 O 4 and receives a message back from the third business system through R 4 .
- the subprocess completes the task and the integration resumes operation by transmitting a message to a second business system through O 5 .
- 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.
- 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).
- an event in other branch e.g., reaching the join node first
- Such an “implicit” cancellation may be automatically cascaded to the first and second subprocesses.
- an exception can be raised to let the process logic signal a business fault.
- 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.
- 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.
- FIG. 14 is a flow diagram of process steps pursuant to some embodiments.
- a process is executed at an integration server adapted to provide a messaging service for at least two business applications in an enterprise system.
- input is received from a user at 1404 .
- 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.
- 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.
- 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.
- 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.
- the process includes an “IF” statement with two branches, each containing a User Decision (UD) step.
- a configurable parameter may be declared in the integration process.
- the configurable parameter may be used to assign a user to a variable (e.g., PARAM 1 and PARAM 2 ).
- 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.
- 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.
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
- 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.
- 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.
-
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. - 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 anenterprise system 10 according to some embodiments. The system may, for example, provide for the integration and message-based interaction of applications. Thesystem 10 includes anexchange infrastructure 100 for collaborative processing amonginternal components 20 of an enterprise, and betweenexternal components 30 that communicate with one or moreinternal components 20 through afirewall 40. Theinternal components 20 andexternal 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, eachinternal component 20 andexternal 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 thecomponents exchange infrastructure 100 may include, for example, a central integration repository and directory storing shared collaboration knowledge. Theexchange 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 thecomponents 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 ofcomponents 20, using open standards. -
FIG. 2 is a block diagram of anexchange infrastructure 200 and a number ofcomponent applications 270 according to some embodiments. To facilitate message-based collaboration among theapplications 270, theexchange infrastructure 200 may include anintegration repository 210, anintegration directory 220, asystem landscape directory 240, and anintegration server 230. Theintegration repository 210 may capture design-time collaboration descriptions of all software components that can communicate via theexchange infrastructure 100. Theintegration directory 220 may capture configuration-specific collaboration descriptions of the system landscape at runtime, which may include accessing actual component installations from thesystem landscape directory 240 and connectivity descriptions for external components, all of which represents the shared business semantics of the system landscape. Theintegration 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 aruntime engine 234 that provides messaging and business process control at runtime for connecting services and managing the process flow of value chains. A businessprocess management system 232 may reside on theintegration server 230 below theruntime engine 234. The businessprocess management system 232 may, for example, include a business process engine (not illustrated inFIG. 2 ) that runs on top of theruntime engine 234 for runtime execution of business process management. - The
integration server 230 may also includeintegration services 236 that typically require an application-specific implementation. Like theintegration repository 210 andintegration directory 220, theintegration server 230 may be configured for deployment within any existing system infrastructure. In some cases, theintegration server 230 may be a dedicated server that applies the shared collaboration knowledge of theintegration 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 theexchange infrastructure 100. - The
exchange infrastructure 100 may also includevarious adapters 250 that provide connectivity between theintegration server 230 and various applications 270 (e.g., proprietary applications, Web-based services, and/or third party applications). Theexchange 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, anadapter 260 could be implemented external to theexchange infrastructure 200. -
FIG. 3 illustrates anexchange infrastructure 300, including anintegration repository 310, asystem landscape directory 340, anintegration directory 320 and an instantiation of theruntime engine 330 in greater detail. Theintegration 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. Theintegration repository 310 may access descriptions of software components in the system landscape from thesystem landscape directory 340. The business scenarios of theintegration 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 theintegration repository 310 for rapid configuration of theexchange 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 theintegration repository 310 includes design-time information, only component-type information, independent of actual installation, might be stored ascomponents 340. The component descriptions can be added using an API or interactively using a graphical user interface. - The
integration directory 320 details information from theintegration 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 theintegration repository 310 or manually by a user using a graphical user interface. In one implementation, theintegration directory 320 is built on a Java platform and its content is represented via XML using open Internet standards. Note that theintegration repository 310 might be upgraded without affecting theintegration directory 320 or any runtime collaborative processes. The user then decides which changes should be transferred to theintegration 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. Theintegration directory 320 may also include descriptions of active Web services and active business partners. Theintegration directory 320 may use a description of the active system landscape from thesystem landscape directory 340. The business scenarios in theintegration 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). Theintegration 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. Theintegration 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 theexchange 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 theexchange infrastructure 300. - The
integration directory 320 and theruntime 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. Theintegration server 330 executes the collaborative runtime environment or Web application server, either of which can include an instance of theruntime engine 330 in accordance with informational resources provided by theintegration directory 320. - The
runtime engine 330, which exchanges all messages between the various interconnected components includes two layers: anintegration layer 332 and a messaging andtransport layer 336. Theintegration layer 332 includes abusiness process engine 334 executing centrally modeled business processes, a logical routing service and a mapping service. The messaging andtransport layer 336 provides a physical address resolution service, a messaging and queuing service, a transport service via HTTP, and a database (described with respect toFIG. 4 ) to support theruntime engine 330. - The messaging and
transport layer 336 may be included in each instantiation of theruntime engine 330 inWeb 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. Thebusiness 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 anexchange infrastructure 400 while exchanging a message between applications according to some embodiments. A sending application resides in a sendingcomponent system 410, which represents the hardware and software platform of the sending application. One or more receiving applications each reside in areceiving component system - A communication path for a
message 310 can include an outbound proxy at the outbound interface from the sendingcomponent system 410, through a runtime engine and adapter of theexchange infrastructure 400 to areceiving component system component system - 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 theintegration 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 theruntime 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 theintegration repository 310 and the design-time configuration of the system landscape. The business processes may be integrated withother 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 illustratesinteractions 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 aprocess 910 calling asubprocess 920 according to some embodiments. That is, during execution of the process 910 a step is reached in which thesubprocess 920 is called. According to some embodiments, input data may be provided to thesubprocess 920 during this step. Note that the call might be performed by a send step of theprocess 910 that transmits a message to a receive step of thesubprocess 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 thesubprocess 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 thesubprocess 920 to a receive step of theprocess 910. - According to some embodiments, execution of the
process 910 is blocked or halted when thesubprocess 920 is called. In this case, execution of theprocess 910 might resume when thesubprocess 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 anintegration 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 anintegration 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 andsubprocess 2 might be assigned to P_SP2). Thus, if the IF statement will result in eithersubprocess 1 orsubprocess 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 withFIG. 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 inFIG. 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 aprocess 1510 receiving input from a user according to some embodiments. Theintegration 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 inFIG. 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 anintegration 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 (28)
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.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/045,548 US20050193061A1 (en) | 2003-05-16 | 2005-01-28 | Subprocesses and user interactions for a business process management integration server |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US47123703P | 2003-05-16 | 2003-05-16 | |
PCT/EP2004/005211 WO2004102438A2 (en) | 2003-05-16 | 2004-05-14 | Business process management for a message-based exchange infrastructure |
US11/045,548 US20050193061A1 (en) | 2003-05-16 | 2005-01-28 | Subprocesses and user interactions for a business process management integration server |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2004/005211 Continuation-In-Part WO2004102438A2 (en) | 2003-05-16 | 2004-05-14 | Business process management for a message-based exchange infrastructure |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050193061A1 true US20050193061A1 (en) | 2005-09-01 |
Family
ID=33452433
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/846,363 Active 2027-06-12 US7788319B2 (en) | 2003-05-16 | 2004-05-14 | Business process management for a message-based exchange infrastructure |
US11/045,548 Abandoned US20050193061A1 (en) | 2003-05-16 | 2005-01-28 | Subprocesses and user interactions for a business process management integration server |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/846,363 Active 2027-06-12 US7788319B2 (en) | 2003-05-16 | 2004-05-14 | Business process management for a message-based exchange infrastructure |
Country Status (5)
Country | Link |
---|---|
US (2) | US7788319B2 (en) |
EP (1) | EP1625499A2 (en) |
JP (1) | JP5290518B2 (en) |
CN (1) | CN1791861A (en) |
WO (1) | WO2004102438A2 (en) |
Cited By (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070162416A1 (en) * | 2005-12-29 | 2007-07-12 | Morsch Andreas F | System and method for process controls in master data modeling |
US20070245225A1 (en) * | 2006-04-18 | 2007-10-18 | Nally Martin P | System and method for translating between a global view of a system process and a set of interacting processes |
US20090204884A1 (en) * | 2008-02-12 | 2009-08-13 | Oracle International Corporation | Multi-layer xml customization |
US20090204629A1 (en) * | 2008-02-12 | 2009-08-13 | Oracle International Corporation | Caching and memory optimizations for multi-layer xml customization |
US20100070553A1 (en) * | 2008-09-15 | 2010-03-18 | Oracle International Corporation | Dynamic service invocation and service adaptation in bpel soa process |
US20100146291A1 (en) * | 2008-12-08 | 2010-06-10 | Oracle International Corporation | Secure framework for invoking server-side apis using ajax |
US20100205616A1 (en) * | 2009-02-11 | 2010-08-12 | International Business Machines Corporation | Application workflow integration subsystem |
US20120078809A1 (en) * | 2010-09-27 | 2012-03-29 | Sap Ag | Integrating sub-processes in business process modeling notation processes |
US20120256925A1 (en) * | 2011-04-11 | 2012-10-11 | SmartDraw, LLC | Generation of a hierarchically-organized collection of hyperlinked graphics charts |
US20120297077A1 (en) * | 2008-09-17 | 2012-11-22 | Microsoft Corporation | Technologies for detecting erroneous resumptions in a continuation based runtime |
US8667031B2 (en) | 2008-06-13 | 2014-03-04 | Oracle International Corporation | Reuse of shared metadata across applications via URL protocol |
US8782604B2 (en) | 2008-04-11 | 2014-07-15 | Oracle International Corporation | Sandbox support for metadata in running applications |
US8788542B2 (en) | 2008-02-12 | 2014-07-22 | Oracle International Corporation | Customization syntax for multi-layer XML customization |
US8799319B2 (en) | 2008-09-19 | 2014-08-05 | Oracle International Corporation | System and method for meta-data driven, semi-automated generation of web services based on existing applications |
US8856737B2 (en) | 2009-11-18 | 2014-10-07 | Oracle International Corporation | Techniques for displaying customizations for composite applications |
US8875306B2 (en) | 2008-02-12 | 2014-10-28 | Oracle International Corporation | Customization restrictions for multi-layer XML customization |
US8954942B2 (en) | 2011-09-30 | 2015-02-10 | Oracle International Corporation | Optimizations using a BPEL compiler |
US8966465B2 (en) | 2008-02-12 | 2015-02-24 | Oracle International Corporation | Customization creation and update for multi-layer XML customization |
US8996658B2 (en) | 2008-09-03 | 2015-03-31 | Oracle International Corporation | System and method for integration of browser-based thin client applications within desktop rich client architecture |
US20150112740A1 (en) * | 2006-08-13 | 2015-04-23 | Boris Shapira | Systems and method for message-based control and monitoring of a business process |
US9122520B2 (en) | 2008-09-17 | 2015-09-01 | Oracle International Corporation | Generic wait service: pausing a BPEL process |
US10503787B2 (en) | 2015-09-30 | 2019-12-10 | Oracle International Corporation | Sharing common metadata in multi-tenant environment |
Families Citing this family (176)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2004025466A2 (en) * | 2002-09-16 | 2004-03-25 | Clearcube Technology, Inc. | Distributed computing infrastructure |
US7404185B2 (en) * | 2003-12-02 | 2008-07-22 | International Business Machines Corporation | Method and apparatus of adaptive integration activity management for business application integration |
US7389321B2 (en) * | 2003-12-12 | 2008-06-17 | International Business Machines Corporation | Sequential restructuring of a collaborative context |
US9015239B2 (en) * | 2003-12-22 | 2015-04-21 | International Business Machines Corporation | System and method for integrating third party applications into a named collaborative space |
US20050198121A1 (en) * | 2004-01-07 | 2005-09-08 | Daniels Robert W. | Vertical enterprise system |
US7743386B2 (en) | 2004-03-12 | 2010-06-22 | Sap Ag | Context objects for accessing message content |
US7536606B2 (en) * | 2004-04-30 | 2009-05-19 | Microsoft Corporation | Error detection in web services systems |
US8655756B2 (en) | 2004-06-04 | 2014-02-18 | Sap Ag | Consistent set of interfaces derived from a business object model |
US8606723B2 (en) | 2004-06-04 | 2013-12-10 | Sap Ag | Consistent set of interfaces derived from a business object model |
WO2006038924A2 (en) | 2004-06-18 | 2006-04-13 | Sap Ag | Consistent set of interfaces derived from a business object model |
US7739695B2 (en) * | 2004-07-19 | 2010-06-15 | Sap Ag | Computer implemented method and system for running a plurality of business processes |
US7614049B2 (en) * | 2004-08-24 | 2009-11-03 | International Business Machines Corporation | Autonomic installation and configuration of an enterprise business process on-demand |
US7657554B2 (en) * | 2004-11-05 | 2010-02-02 | Microsoft Corporation | Method and system for managing user interface messages |
US7865519B2 (en) | 2004-11-17 | 2011-01-04 | Sap Aktiengesellschaft | Using a controlled vocabulary library to generate business data component names |
US8521570B2 (en) * | 2004-12-28 | 2013-08-27 | Sap Aktiengesellschaft | Integration of distributed business process models |
GB2423382A (en) | 2005-01-27 | 2006-08-23 | Microgen Plc | Generating business process programs using a symbolic representation of operators in a graphical interface |
CA2597758C (en) * | 2005-02-22 | 2016-05-17 | Connectif Solutions Inc. | Distributed asset management system and method |
US8744937B2 (en) | 2005-02-25 | 2014-06-03 | Sap Ag | Consistent set of interfaces derived from a business object model |
US8195789B2 (en) | 2005-04-20 | 2012-06-05 | Oracle International Corporation | System, apparatus and method for characterizing messages to discover dependencies of services in service-oriented architectures |
US9317259B2 (en) * | 2005-05-12 | 2016-04-19 | International Business Machines Corporation | Apparatus, system, and method for automatically generating a reusable software component for interfacing with a web service |
US20070005618A1 (en) * | 2005-06-07 | 2007-01-04 | Konstantin Ivanov | Systems and methods for modeling business processes |
US20060293941A1 (en) * | 2005-06-07 | 2006-12-28 | Konstantin Ivanov | Systems and methods for modeling business processes using graphical symbols |
CN101305350A (en) * | 2005-06-09 | 2008-11-12 | 惠而浦公司 | Software architecture system and method for communication with, and management of, at least one component within a household appliance |
US7788338B2 (en) * | 2005-09-21 | 2010-08-31 | Sap Ag | Web services message processing runtime framework |
US7761533B2 (en) * | 2005-09-21 | 2010-07-20 | Sap Ag | Standard implementation container interface for runtime processing of web services messages |
US8745252B2 (en) * | 2005-09-21 | 2014-06-03 | Sap Ag | Headers protocol for use within a web services message processing runtime framework |
EP1785847B1 (en) * | 2005-10-27 | 2015-11-18 | Accenture Global Services Limited | Display apparatus for automatically visualizing an application landscape |
US8386555B2 (en) * | 2005-11-04 | 2013-02-26 | Sap Ag | Systems and methods for adapting procedure calls to service providers |
US8364840B2 (en) * | 2005-12-02 | 2013-01-29 | Sap Ag | Dynamic message routing |
US8448137B2 (en) | 2005-12-30 | 2013-05-21 | Sap Ag | Software model integration scenarios |
US8370794B2 (en) | 2005-12-30 | 2013-02-05 | Sap Ag | Software model process component |
US8316344B2 (en) | 2005-12-30 | 2012-11-20 | Sap Ag | Software model deployment units |
US8676617B2 (en) | 2005-12-30 | 2014-03-18 | Sap Ag | Architectural design for self-service procurement application software |
US8522194B2 (en) | 2005-12-30 | 2013-08-27 | Sap Ag | Software modeling |
US8402426B2 (en) | 2005-12-30 | 2013-03-19 | Sap Ag | Architectural design for make to stock application software |
US8396731B2 (en) | 2005-12-30 | 2013-03-12 | Sap Ag | Architectural design for service procurement application software |
US8380553B2 (en) | 2005-12-30 | 2013-02-19 | Sap Ag | Architectural design for plan-driven procurement application software |
US8327319B2 (en) | 2005-12-30 | 2012-12-04 | Sap Ag | Software model process interaction |
US8326703B2 (en) | 2005-12-30 | 2012-12-04 | Sap Ag | Architectural design for product catalog management application software |
US8321831B2 (en) | 2005-12-30 | 2012-11-27 | Sap Ag | Architectural design for internal projects application software |
CA2644236A1 (en) * | 2006-03-01 | 2007-09-13 | Telcordia Technologies, Inc. | Integrated service creation and execution platforms for the converged networks |
US20080140857A1 (en) * | 2006-03-21 | 2008-06-12 | Conner Peter A | Service-oriented architecture and methods for direct invocation of services utilizing a service requestor invocation framework |
US8538864B2 (en) * | 2006-03-30 | 2013-09-17 | Sap Ag | Providing payment software application as enterprise services |
US8438119B2 (en) | 2006-03-30 | 2013-05-07 | Sap Ag | Foundation layer for services based enterprise software architecture |
US8396761B2 (en) | 2006-03-30 | 2013-03-12 | Sap Ag | Providing product catalog software application as enterprise services |
US8442850B2 (en) | 2006-03-30 | 2013-05-14 | Sap Ag | Providing accounting software application as enterprise services |
US8326702B2 (en) | 2006-03-30 | 2012-12-04 | Sap Ag | Providing supplier relationship management software application as enterprise services |
US8396749B2 (en) | 2006-03-30 | 2013-03-12 | Sap Ag | Providing customer relationship management application as enterprise services |
US8374931B2 (en) | 2006-03-31 | 2013-02-12 | Sap Ag | Consistent set of interfaces derived from a business object model |
US8321832B2 (en) * | 2006-03-31 | 2012-11-27 | Sap Ag | Composite application modeling |
US8312416B2 (en) | 2006-04-13 | 2012-11-13 | Sap Ag | Software model business process variant types |
US7877757B2 (en) * | 2006-05-05 | 2011-01-25 | Microsoft Corporation | Work item event monitor for procession of queued events |
US20070265895A1 (en) * | 2006-05-09 | 2007-11-15 | Sap Ag | Ad-hoc workflow as a business process template |
US8924269B2 (en) | 2006-05-13 | 2014-12-30 | Sap Ag | Consistent set of interfaces derived from a business object model |
US7917344B2 (en) * | 2006-06-06 | 2011-03-29 | The Boeing Company | Enterprise multi-program process development and integration process |
US8392364B2 (en) | 2006-07-10 | 2013-03-05 | Sap Ag | Consistent set of interfaces derived from a business object model |
US8572633B2 (en) * | 2006-07-31 | 2013-10-29 | Sap Ag | Exception handling for collaborating process models |
US7469406B2 (en) * | 2006-07-31 | 2008-12-23 | Sap Ag | Process suspension through process model design |
US8566193B2 (en) | 2006-08-11 | 2013-10-22 | Sap Ag | Consistent set of interfaces derived from a business object model |
CN101131747B (en) * | 2006-08-22 | 2012-02-01 | 国际商业机器公司 | Method, device and system for catching and/or analyzing Web page events at client terminal |
US8396768B1 (en) | 2006-09-28 | 2013-03-12 | Sap Ag | Managing consistent interfaces for human resources business objects across heterogeneous systems |
JP4336363B2 (en) * | 2006-10-30 | 2009-09-30 | 株式会社日立製作所 | Business process execution method, business process execution system, and program |
US20080114627A1 (en) * | 2006-11-15 | 2008-05-15 | Sap Ag | System and Method for Capturing Process Instance Information in Complex or Distributed Systems |
US8087030B2 (en) * | 2006-12-29 | 2011-12-27 | Sap Ag | Processing a received message |
US8008085B2 (en) * | 2007-01-30 | 2011-08-30 | Arkray, Inc. | Method of measuring HbA1c |
JP2008217443A (en) * | 2007-03-05 | 2008-09-18 | Mitsubishi Electric Corp | Business process simulator, and business process simulation program |
US20080282262A1 (en) * | 2007-05-10 | 2008-11-13 | Microsoft Corporation | Automatic and configurable loading of loosely coupled service oriented software components |
US8510143B2 (en) | 2007-12-31 | 2013-08-13 | Sap Ag | Architectural design for ad-hoc goods movement software |
US8447657B2 (en) | 2007-12-31 | 2013-05-21 | Sap Ag | Architectural design for service procurement application software |
US8417593B2 (en) | 2008-02-28 | 2013-04-09 | Sap Ag | System and computer-readable medium for managing consistent interfaces for business objects across heterogeneous systems |
US8473317B2 (en) | 2008-03-31 | 2013-06-25 | Sap Ag | Managing consistent interfaces for service part business objects across heterogeneous systems |
US8370233B2 (en) | 2008-03-31 | 2013-02-05 | Sap Ag | Managing consistent interfaces for business objects across heterogeneous systems |
US8577991B2 (en) | 2008-03-31 | 2013-11-05 | Sap Ag | Managing consistent interfaces for internal service request business objects across heterogeneous systems |
US8413165B2 (en) | 2008-03-31 | 2013-04-02 | Sap Ag | Managing consistent interfaces for maintenance order business objects across heterogeneous systems |
US8589263B2 (en) | 2008-03-31 | 2013-11-19 | Sap Ag | Managing consistent interfaces for retail business objects across heterogeneous systems |
US8433585B2 (en) | 2008-03-31 | 2013-04-30 | Sap Ag | Managing consistent interfaces for business objects across heterogeneous systems |
US8364715B2 (en) | 2008-03-31 | 2013-01-29 | Sap Ag | Managing consistent interfaces for automatic identification label business objects across heterogeneous systems |
US8930248B2 (en) * | 2008-03-31 | 2015-01-06 | Sap Se | Managing consistent interfaces for supply network business objects across heterogeneous systems |
US8423418B2 (en) | 2008-03-31 | 2013-04-16 | Sap Ag | Managing consistent interfaces for business objects across heterogeneous systems |
JP5154292B2 (en) * | 2008-04-24 | 2013-02-27 | 株式会社日立製作所 | Information management system, form definition management server, and information management method |
US20090326988A1 (en) | 2008-06-26 | 2009-12-31 | Robert Barth | Managing consistent interfaces for business objects across heterogeneous systems |
US8566185B2 (en) | 2008-06-26 | 2013-10-22 | Sap Ag | Managing consistent interfaces for financial instrument business objects across heterogeneous systems |
US8671064B2 (en) | 2008-06-26 | 2014-03-11 | Sap Ag | Managing consistent interfaces for supply chain management business objects across heterogeneous systems |
US8645228B2 (en) | 2008-06-26 | 2014-02-04 | Sap Ag | Managing consistent interfaces for business objects across heterogeneous systems |
US20100030732A1 (en) * | 2008-07-31 | 2010-02-04 | International Business Machines Corporation | System and method to create process reference maps from links described in a business process model |
US20100077025A1 (en) * | 2008-08-12 | 2010-03-25 | Bank Of America Corporation | Workflow automation & request processing |
US8818884B2 (en) | 2008-09-18 | 2014-08-26 | Sap Ag | Architectural design for customer returns handling application software |
US8401928B2 (en) | 2008-09-18 | 2013-03-19 | Sap Ag | Providing supplier relationship management software application as enterprise services |
US8386325B2 (en) | 2008-09-18 | 2013-02-26 | Sap Ag | Architectural design for plan-driven procurement application software |
US8315926B2 (en) | 2008-09-18 | 2012-11-20 | Sap Ag | Architectural design for tax declaration application software |
US8595077B2 (en) | 2008-09-18 | 2013-11-26 | Sap Ag | Architectural design for service request and order management application software |
US8359218B2 (en) | 2008-09-18 | 2013-01-22 | Sap Ag | Computer readable medium for implementing supply chain control using service-oriented methodology |
US8374896B2 (en) | 2008-09-18 | 2013-02-12 | Sap Ag | Architectural design for opportunity management application software |
US8352338B2 (en) | 2008-09-18 | 2013-01-08 | Sap Ag | Architectural design for time recording application software |
US8380549B2 (en) | 2008-09-18 | 2013-02-19 | Sap Ag | Architectural design for embedded support application software |
US8463666B2 (en) | 2008-11-25 | 2013-06-11 | Sap Ag | Managing consistent interfaces for merchandise and assortment planning business objects across heterogeneous systems |
US8577760B2 (en) | 2008-11-25 | 2013-11-05 | Sap Ag | Managing consistent interfaces for tax authority business objects across heterogeneous systems |
US8321306B2 (en) | 2008-12-03 | 2012-11-27 | Sap Ag | Architectural design for selling project-based services application software |
US8311904B2 (en) | 2008-12-03 | 2012-11-13 | Sap Ag | Architectural design for intra-company stock transfer application software |
US8738476B2 (en) | 2008-12-03 | 2014-05-27 | Sap Ag | Architectural design for selling standardized services application software |
US8401908B2 (en) | 2008-12-03 | 2013-03-19 | Sap Ag | Architectural design for make-to-specification application software |
US8676627B2 (en) * | 2008-12-04 | 2014-03-18 | International Business Machines Corporation | Vertical process merging by reconstruction of equivalent models and hierarchical process merging |
US8671035B2 (en) | 2008-12-11 | 2014-03-11 | Sap Ag | Providing payroll software application as enterprise services |
US20100153297A1 (en) | 2008-12-12 | 2010-06-17 | Sap Ag | Managing Consistent Interfaces for Credit Portfolio Business Objects Across Heterogeneous Systems |
US8396751B2 (en) | 2009-09-30 | 2013-03-12 | Sap Ag | Managing consistent interfaces for merchandising business objects across heterogeneous systems |
US9361165B2 (en) * | 2009-12-03 | 2016-06-07 | International Business Machines Corporation | Automated merger of logically associated messages in a message queue |
US8549353B2 (en) | 2009-12-29 | 2013-10-01 | Microgen Aptitutde Limited | Batch processing error handling modes |
CN101826987B (en) * | 2010-04-27 | 2012-05-02 | 北京邮电大学 | System and method for supporting mixed service based on integrated open network |
US20110282949A1 (en) * | 2010-05-11 | 2011-11-17 | Leon Rivkin | Unified message management method and system |
US8412603B2 (en) * | 2010-06-15 | 2013-04-02 | Sap Ag | Managing consistent interfaces for currency conversion and date and time business objects across heterogeneous systems |
US8417588B2 (en) | 2010-06-15 | 2013-04-09 | Sap Ag | Managing consistent interfaces for goods tag, production bill of material hierarchy, and release order template business objects across heterogeneous systems |
US8515794B2 (en) | 2010-06-15 | 2013-08-20 | Sap Ag | Managing consistent interfaces for employee time event and human capital management view of payroll process business objects across heterogeneous systems |
US8732083B2 (en) | 2010-06-15 | 2014-05-20 | Sap Ag | Managing consistent interfaces for number range, number range profile, payment card payment authorisation, and product template template business objects across heterogeneous systems |
US9135585B2 (en) | 2010-06-15 | 2015-09-15 | Sap Se | Managing consistent interfaces for property library, property list template, quantity conversion virtual object, and supplier property specification business objects across heterogeneous systems |
US8364608B2 (en) | 2010-06-15 | 2013-01-29 | Sap Ag | Managing consistent interfaces for export declaration and export declaration request business objects across heterogeneous systems |
US8370272B2 (en) | 2010-06-15 | 2013-02-05 | Sap Ag | Managing consistent interfaces for business document message monitoring view, customs arrangement, and freight list business objects across heterogeneous systems |
EP2492805A1 (en) * | 2011-02-22 | 2012-08-29 | Sap Ag | Computer network, computer system, computer-implemented method, and computer program product for controlling application landscapes |
WO2012121714A1 (en) * | 2011-03-09 | 2012-09-13 | Hewlett-Packard Development Company, L.P. | Performing a change process based on a policy |
CN102750597B (en) * | 2011-04-22 | 2016-05-04 | 国际商业机器公司 | A kind of computer implemented method and apparatus for integrated heterogeneous journey |
US8521838B2 (en) | 2011-07-28 | 2013-08-27 | Sap Ag | Managing consistent interfaces for communication system and object identifier mapping business objects across heterogeneous systems |
US8666845B2 (en) | 2011-07-28 | 2014-03-04 | Sap Ag | Managing consistent interfaces for a customer requirement business object across heterogeneous systems |
US8775280B2 (en) | 2011-07-28 | 2014-07-08 | Sap Ag | Managing consistent interfaces for financial business objects across heterogeneous systems |
US8601490B2 (en) | 2011-07-28 | 2013-12-03 | Sap Ag | Managing consistent interfaces for business rule business object across heterogeneous systems |
US8725654B2 (en) | 2011-07-28 | 2014-05-13 | Sap Ag | Managing consistent interfaces for employee data replication business objects across heterogeneous systems |
US8560392B2 (en) | 2011-07-28 | 2013-10-15 | Sap Ag | Managing consistent interfaces for a point of sale transaction business object across heterogeneous systems |
US9766906B2 (en) * | 2011-12-29 | 2017-09-19 | International Business Machines Corporation | Efficient sharing of artifacts between collaboration applications |
US8984050B2 (en) | 2012-02-16 | 2015-03-17 | Sap Se | Consistent interface for sales territory message type set 2 |
US8762454B2 (en) | 2012-02-16 | 2014-06-24 | Sap Ag | Consistent interface for flag and tag |
US9232368B2 (en) | 2012-02-16 | 2016-01-05 | Sap Se | Consistent interface for user feed administrator, user feed event link and user feed settings |
US9237425B2 (en) | 2012-02-16 | 2016-01-12 | Sap Se | Consistent interface for feed event, feed event document and feed event type |
US8762453B2 (en) | 2012-02-16 | 2014-06-24 | Sap Ag | Consistent interface for feed collaboration group and feed event subscription |
US8756274B2 (en) | 2012-02-16 | 2014-06-17 | Sap Ag | Consistent interface for sales territory message type set 1 |
US8954602B2 (en) | 2012-05-31 | 2015-02-10 | Sap Se | Facilitating communication between enterprise software applications |
US20130347004A1 (en) * | 2012-06-25 | 2013-12-26 | Sap Ag | Correlating messages |
US9246869B2 (en) | 2012-06-28 | 2016-01-26 | Sap Se | Consistent interface for opportunity |
US8615451B1 (en) | 2012-06-28 | 2013-12-24 | Sap Ag | Consistent interface for goods and activity confirmation |
US8756135B2 (en) | 2012-06-28 | 2014-06-17 | Sap Ag | Consistent interface for product valuation data and product valuation level |
US9367826B2 (en) * | 2012-06-28 | 2016-06-14 | Sap Se | Consistent interface for entitlement product |
US9400998B2 (en) | 2012-06-28 | 2016-07-26 | Sap Se | Consistent interface for message-based communication arrangement, organisational centre replication request, and payment schedule |
US8949855B2 (en) | 2012-06-28 | 2015-02-03 | Sap Se | Consistent interface for address snapshot and approval process definition |
WO2014000200A1 (en) | 2012-06-28 | 2014-01-03 | Sap Ag | Consistent interface for document output request |
US8521621B1 (en) | 2012-06-28 | 2013-08-27 | Sap Ag | Consistent interface for inbound delivery request |
US9547833B2 (en) | 2012-08-22 | 2017-01-17 | Sap Se | Consistent interface for financial instrument impairment calculation |
US9076112B2 (en) | 2012-08-22 | 2015-07-07 | Sap Se | Consistent interface for financial instrument impairment expected cash flow analytical result |
US9043236B2 (en) | 2012-08-22 | 2015-05-26 | Sap Se | Consistent interface for financial instrument impairment attribute values analytical result |
US20140114864A1 (en) * | 2012-10-22 | 2014-04-24 | International Business Machines Corporation | Case management integration with external content repositories |
US9165049B2 (en) * | 2013-03-01 | 2015-10-20 | Sap Se | Translating business scenario definitions into corresponding database artifacts |
US9858093B2 (en) * | 2013-03-08 | 2018-01-02 | Oracle International Corporation | Model for configuration independent process templates and business catalog |
US9191343B2 (en) | 2013-03-15 | 2015-11-17 | Sap Se | Consistent interface for appointment activity business object |
US9191357B2 (en) | 2013-03-15 | 2015-11-17 | Sap Se | Consistent interface for email activity business object |
US9411845B2 (en) | 2013-06-13 | 2016-08-09 | Sap Se | Integration flow database runtime |
US10133996B2 (en) * | 2014-04-22 | 2018-11-20 | International Business Machines Corporation | Object lifecycle analysis tool |
US9406040B2 (en) | 2014-08-13 | 2016-08-02 | Sap Se | Classification and modelling of exception types for integration middleware systems |
US10628132B2 (en) * | 2016-09-15 | 2020-04-21 | Oracle International Corporation | Inversion of control framework for multiple behaviors of a process |
US11294644B2 (en) | 2016-09-16 | 2022-04-05 | Oracle International Corporation | Inversion of control framework for multiple behaviors on top of a process |
US10592509B2 (en) | 2017-03-01 | 2020-03-17 | Sap Se | Declarative rules for optimized access to data |
US10657276B2 (en) | 2017-10-26 | 2020-05-19 | Sap Se | System sharing types in multi-tenancy database systems |
US10482080B2 (en) | 2017-10-26 | 2019-11-19 | Sap Se | Exchanging shared containers and adapting tenants in multi-tenancy database systems |
US10740318B2 (en) | 2017-10-26 | 2020-08-11 | Sap Se | Key pattern management in multi-tenancy database systems |
US10733168B2 (en) | 2017-10-26 | 2020-08-04 | Sap Se | Deploying changes to key patterns in multi-tenancy database systems |
US10713277B2 (en) | 2017-10-26 | 2020-07-14 | Sap Se | Patching content across shared and tenant containers in multi-tenancy database systems |
US10621167B2 (en) | 2017-10-26 | 2020-04-14 | Sap Se | Data separation and write redirection in multi-tenancy database systems |
US10452646B2 (en) | 2017-10-26 | 2019-10-22 | Sap Se | Deploying changes in a multi-tenancy database system |
US10740315B2 (en) | 2017-10-26 | 2020-08-11 | Sap Se | Transitioning between system sharing types in multi-tenancy database systems |
US10942892B2 (en) | 2018-05-18 | 2021-03-09 | Sap Se | Transport handling of foreign key checks |
US10915551B2 (en) | 2018-06-04 | 2021-02-09 | Sap Se | Change management for shared objects in multi-tenancy systems |
US10936624B2 (en) | 2018-06-12 | 2021-03-02 | Sap Se | Development and productive use of system with parallel use of production data and zero downtime of software changes |
US10614406B2 (en) | 2018-06-18 | 2020-04-07 | Bank Of America Corporation | Core process framework for integrating disparate applications |
CN110633947A (en) * | 2018-06-22 | 2019-12-31 | 上海昶铭软件科技有限公司 | Project management system and working method thereof |
US11238386B2 (en) | 2018-12-20 | 2022-02-01 | Sap Se | Task derivation for workflows |
US11416485B2 (en) | 2019-03-28 | 2022-08-16 | Sap Se | Dynamic query expressions |
US11360977B2 (en) | 2019-04-01 | 2022-06-14 | Sap Se | Selectively allowing query optimization in query processing |
CN110188132B (en) * | 2019-04-29 | 2023-05-05 | 安徽晶奇网络科技股份有限公司 | Data exchange method and system |
CN111208992A (en) * | 2020-01-10 | 2020-05-29 | 深圳壹账通智能科技有限公司 | System scheduling workflow generation method and system |
CN111708545B (en) * | 2020-06-17 | 2023-09-22 | 北京同邦卓益科技有限公司 | Service flow deployment method and device, electronic equipment and storage medium |
US11716259B2 (en) * | 2021-11-29 | 2023-08-01 | Sap Se | On-demand instance |
Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020065953A1 (en) * | 2000-05-08 | 2002-05-30 | Alford G. Christian | Priority in a portable thread environment |
US6519642B1 (en) * | 1997-01-24 | 2003-02-11 | Peregrine Force, Inc. | System and method for creating, executing and maintaining cross-enterprise processes |
US20030182452A1 (en) * | 2001-10-18 | 2003-09-25 | Mitch Upton | System and method for implementing a schema object model in application integration |
US6629096B1 (en) * | 1999-08-09 | 2003-09-30 | Mindflow Technologies, Inc. | System and method for performing a mindflow process |
US6766517B1 (en) * | 1999-10-14 | 2004-07-20 | Sun Microsystems, Inc. | System and method for facilitating thread-safe message passing communications among threads in respective processes |
US7174363B1 (en) * | 2001-02-22 | 2007-02-06 | Charles Schwab & Co., Inc. | Distributed computing system architecture |
US20070038780A1 (en) * | 2001-04-02 | 2007-02-15 | Irving Rappaport | Method and system for facilitating the integration of a plurality of dissimilar systems |
US20070271554A1 (en) * | 2001-09-19 | 2007-11-22 | Fletcher James C | Dynamic, Real-Time Integration of Software Resources through Services of a Content Framework |
US7506302B2 (en) * | 2002-10-22 | 2009-03-17 | The Boeing Company | System and methods for business process modeling |
US7650325B2 (en) * | 2001-11-13 | 2010-01-19 | International Business Machines Corporation | Dynamic interface adapter for integration of source and target applications |
US7689711B2 (en) * | 2001-03-26 | 2010-03-30 | Salesforce.Com, Inc. | System and method for routing messages between applications |
US7725590B2 (en) * | 2002-04-19 | 2010-05-25 | Computer Associates Think, Inc. | Web services broker |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3179513B2 (en) * | 1990-05-10 | 2001-06-25 | ヒューレット・パッカード・カンパニー | Application program integration system in heterogeneous network environment |
US7020880B2 (en) * | 1997-01-08 | 2006-03-28 | International Business Machines Corporation | Modular application collaborator for providing inter-operability between applications and monitoring errors to trigger execution of required compensating actions to undo interrupted transaction |
US7047532B1 (en) * | 1998-11-13 | 2006-05-16 | The Chase Manhattan Bank | Application independent messaging system |
JP2001216143A (en) * | 2000-02-02 | 2001-08-10 | Hitachi Ltd | Cooperation method for integrating application |
JP2002132503A (en) * | 2000-10-27 | 2002-05-10 | Hitachi Ltd | Definition method of data linkage in workflow control system and process data control system |
JP2002175274A (en) * | 2000-12-06 | 2002-06-21 | Sony Corp | Information processing device and information processing method, network system, storage medium, and computer program |
MXPA03011976A (en) * | 2001-06-22 | 2005-07-01 | Nervana Inc | System and method for knowledge retrieval, management, delivery and presentation. |
JP3683839B2 (en) * | 2001-08-27 | 2005-08-17 | 株式会社東京三菱銀行 | Information relay apparatus, information processing system, and recording medium |
CA2481099C (en) * | 2002-03-28 | 2011-12-06 | Sap Aktiengesellschaft | Exchange infrastructure system and method |
US7428597B2 (en) * | 2002-03-28 | 2008-09-23 | Sap Ag | Content-based routing system and method |
US7412658B2 (en) * | 2002-11-14 | 2008-08-12 | Sap Ag | Modeling system for graphic user interface |
US20040187140A1 (en) * | 2003-03-21 | 2004-09-23 | Werner Aigner | Application framework |
TWI360083B (en) * | 2003-05-09 | 2012-03-11 | Jda Software Group Inc | System, method and software for managing a central |
-
2004
- 2004-05-14 EP EP20040732984 patent/EP1625499A2/en not_active Ceased
- 2004-05-14 US US10/846,363 patent/US7788319B2/en active Active
- 2004-05-14 CN CNA2004800134299A patent/CN1791861A/en active Pending
- 2004-05-14 WO PCT/EP2004/005211 patent/WO2004102438A2/en active Application Filing
- 2004-05-14 JP JP2006529828A patent/JP5290518B2/en active Active
-
2005
- 2005-01-28 US US11/045,548 patent/US20050193061A1/en not_active Abandoned
Patent Citations (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6519642B1 (en) * | 1997-01-24 | 2003-02-11 | Peregrine Force, Inc. | System and method for creating, executing and maintaining cross-enterprise processes |
US6629096B1 (en) * | 1999-08-09 | 2003-09-30 | Mindflow Technologies, Inc. | System and method for performing a mindflow process |
US6766517B1 (en) * | 1999-10-14 | 2004-07-20 | Sun Microsystems, Inc. | System and method for facilitating thread-safe message passing communications among threads in respective processes |
US20020065953A1 (en) * | 2000-05-08 | 2002-05-30 | Alford G. Christian | Priority in a portable thread environment |
US7174363B1 (en) * | 2001-02-22 | 2007-02-06 | Charles Schwab & Co., Inc. | Distributed computing system architecture |
US7689711B2 (en) * | 2001-03-26 | 2010-03-30 | Salesforce.Com, Inc. | System and method for routing messages between applications |
US20070038780A1 (en) * | 2001-04-02 | 2007-02-15 | Irving Rappaport | Method and system for facilitating the integration of a plurality of dissimilar systems |
US20070271554A1 (en) * | 2001-09-19 | 2007-11-22 | Fletcher James C | Dynamic, Real-Time Integration of Software Resources through Services of a Content Framework |
US20030182452A1 (en) * | 2001-10-18 | 2003-09-25 | Mitch Upton | System and method for implementing a schema object model in application integration |
US7650325B2 (en) * | 2001-11-13 | 2010-01-19 | International Business Machines Corporation | Dynamic interface adapter for integration of source and target applications |
US7725590B2 (en) * | 2002-04-19 | 2010-05-25 | Computer Associates Think, Inc. | Web services broker |
US7506302B2 (en) * | 2002-10-22 | 2009-03-17 | The Boeing Company | System and methods for business process modeling |
Cited By (37)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070162416A1 (en) * | 2005-12-29 | 2007-07-12 | Morsch Andreas F | System and method for process controls in master data modeling |
US8407222B2 (en) * | 2005-12-29 | 2013-03-26 | Sap Ag | System and method for process controls in master data modeling |
US20070245225A1 (en) * | 2006-04-18 | 2007-10-18 | Nally Martin P | System and method for translating between a global view of a system process and a set of interacting processes |
US11704606B2 (en) | 2006-08-13 | 2023-07-18 | Controls Force Ltd. | Systems and method for message-based control and monitoring of a business process |
US11651304B2 (en) | 2006-08-13 | 2023-05-16 | Controls Force Ltd. | Systems and method for message-based control and monitoring of a business process |
US11113639B2 (en) * | 2006-08-13 | 2021-09-07 | Controls Force Ltd | Systems and method for message-based control and monitoring of a business process |
US20150112740A1 (en) * | 2006-08-13 | 2015-04-23 | Boris Shapira | Systems and method for message-based control and monitoring of a business process |
US8875306B2 (en) | 2008-02-12 | 2014-10-28 | Oracle International Corporation | Customization restrictions for multi-layer XML customization |
US8966465B2 (en) | 2008-02-12 | 2015-02-24 | Oracle International Corporation | Customization creation and update for multi-layer XML customization |
US8788542B2 (en) | 2008-02-12 | 2014-07-22 | Oracle International Corporation | Customization syntax for multi-layer XML customization |
US20090204629A1 (en) * | 2008-02-12 | 2009-08-13 | Oracle International Corporation | Caching and memory optimizations for multi-layer xml customization |
US20090204884A1 (en) * | 2008-02-12 | 2009-08-13 | Oracle International Corporation | Multi-layer xml customization |
US8538998B2 (en) | 2008-02-12 | 2013-09-17 | Oracle International Corporation | Caching and memory optimizations for multi-layer XML customization |
US8560938B2 (en) | 2008-02-12 | 2013-10-15 | Oracle International Corporation | Multi-layer XML customization |
US8782604B2 (en) | 2008-04-11 | 2014-07-15 | Oracle International Corporation | Sandbox support for metadata in running applications |
US8667031B2 (en) | 2008-06-13 | 2014-03-04 | Oracle International Corporation | Reuse of shared metadata across applications via URL protocol |
US8996658B2 (en) | 2008-09-03 | 2015-03-31 | Oracle International Corporation | System and method for integration of browser-based thin client applications within desktop rich client architecture |
US9606778B2 (en) | 2008-09-03 | 2017-03-28 | Oracle International Corporation | System and method for meta-data driven, semi-automated generation of web services based on existing applications |
US20100070553A1 (en) * | 2008-09-15 | 2010-03-18 | Oracle International Corporation | Dynamic service invocation and service adaptation in bpel soa process |
US8271609B2 (en) * | 2008-09-15 | 2012-09-18 | Oracle International Corporation | Dynamic service invocation and service adaptation in BPEL SOA process |
US9122520B2 (en) | 2008-09-17 | 2015-09-01 | Oracle International Corporation | Generic wait service: pausing a BPEL process |
US8620991B2 (en) * | 2008-09-17 | 2013-12-31 | Microsoft Corporation | Technologies for detecting erroneous resumptions in a continuation based runtime |
US20120297077A1 (en) * | 2008-09-17 | 2012-11-22 | Microsoft Corporation | Technologies for detecting erroneous resumptions in a continuation based runtime |
US10296373B2 (en) | 2008-09-17 | 2019-05-21 | Oracle International Corporation | Generic wait service: pausing and resuming a plurality of BPEL processes arranged in correlation sets by a central generic wait server |
US8799319B2 (en) | 2008-09-19 | 2014-08-05 | Oracle International Corporation | System and method for meta-data driven, semi-automated generation of web services based on existing applications |
US20100146291A1 (en) * | 2008-12-08 | 2010-06-10 | Oracle International Corporation | Secure framework for invoking server-side apis using ajax |
US8332654B2 (en) | 2008-12-08 | 2012-12-11 | Oracle International Corporation | Secure framework for invoking server-side APIs using AJAX |
US9244730B2 (en) | 2009-02-11 | 2016-01-26 | International Business Machines Corporation | Application workflow integration subsystem |
US20100205616A1 (en) * | 2009-02-11 | 2010-08-12 | International Business Machines Corporation | Application workflow integration subsystem |
US8869108B2 (en) | 2009-11-18 | 2014-10-21 | Oracle International Corporation | Techniques related to customizations for composite applications |
US8856737B2 (en) | 2009-11-18 | 2014-10-07 | Oracle International Corporation | Techniques for displaying customizations for composite applications |
US20120078809A1 (en) * | 2010-09-27 | 2012-03-29 | Sap Ag | Integrating sub-processes in business process modeling notation processes |
US20120256925A1 (en) * | 2011-04-11 | 2012-10-11 | SmartDraw, LLC | Generation of a hierarchically-organized collection of hyperlinked graphics charts |
US8954942B2 (en) | 2011-09-30 | 2015-02-10 | Oracle International Corporation | Optimizations using a BPEL compiler |
US10909186B2 (en) | 2015-09-30 | 2021-02-02 | Oracle International Corporation | Multi-tenant customizable composites |
US10503787B2 (en) | 2015-09-30 | 2019-12-10 | Oracle International Corporation | Sharing common metadata in multi-tenant environment |
US11429677B2 (en) | 2015-09-30 | 2022-08-30 | Oracle International Corporation | Sharing common metadata in multi-tenant environment |
Also Published As
Publication number | Publication date |
---|---|
WO2004102438A2 (en) | 2004-11-25 |
EP1625499A2 (en) | 2006-02-15 |
CN1791861A (en) | 2006-06-21 |
US20040254945A1 (en) | 2004-12-16 |
US7788319B2 (en) | 2010-08-31 |
JP5290518B2 (en) | 2013-09-18 |
JP2006529037A (en) | 2006-12-28 |
WO2004102438A3 (en) | 2005-11-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20050193061A1 (en) | Subprocesses and user interactions for a business process management integration server | |
US7565443B2 (en) | Common persistence layer | |
US20060224702A1 (en) | Local workflows in a business process management system | |
US8065657B2 (en) | Exchange infrastructure system and method | |
US20120215581A1 (en) | Ad-Hoc and Priority-Based Business Process Execution | |
US7428597B2 (en) | Content-based routing system and method | |
US7404189B2 (en) | Scheduler supporting web service invocation | |
US6985939B2 (en) | Building distributed software services as aggregations of other services | |
US8478616B2 (en) | Business application development and execution environment | |
US8589594B2 (en) | Programmatic management of software resources in a content framework environment | |
US8032635B2 (en) | Grid processing in a trading network | |
US7937500B2 (en) | Dynamic, real-time integration of software resources through services of a content framework | |
US7373424B2 (en) | Exactly once protocol for message-based collaboration | |
CA2481099C (en) | Exchange infrastructure system and method | |
Kim et al. | RFID business aware framework for business process in the EPC network | |
EP1569106B1 (en) | A scheduler supporting web service invocation | |
Seilonen et al. | Experiences from the Development of an XML/XSLT based Integration Server for a Virtual Enterprise Type Co-Operation | |
Xu et al. | A Dynamic Workflow Management Model Based on Web Services |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SAP AKTIENGESELLSCHAFT, GERMANY Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SCHMIDT, PATRICK;PAUL, BIKRAM;REEL/FRAME:015978/0777 Effective date: 20050506 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION |