U.S. patent application number 11/045548 was filed with the patent office on 2005-09-01 for subprocesses and user interactions for a business process management integration server.
Invention is credited to Paul, Bikram, Schmidt, Patrick.
Application Number | 20050193061 11/045548 |
Document ID | / |
Family ID | 33452433 |
Filed Date | 2005-09-01 |
United States Patent
Application |
20050193061 |
Kind Code |
A1 |
Schmidt, Patrick ; et
al. |
September 1, 2005 |
Subprocesses and user interactions for a business process
management integration server
Abstract
A process may be executed at an integration server adapted to
provide a messaging service for at least two business applications
in an enterprise system. According to some embodiments, a
subprocess may be called during execution of the process (and other
processes may also call the subprocess). According to other
embodiments, input may be received from a user (and further
execution of the process may be based at least in part on the
received input).
Inventors: |
Schmidt, Patrick;
(Heidelberg, DE) ; Paul, Bikram; (Bangalore,
IN) |
Correspondence
Address: |
BUCKLEY, MASCHOFF, TALWALKAR LLC
5 ELM STREET
NEW CANAAN
CT
06840
US
|
Family ID: |
33452433 |
Appl. No.: |
11/045548 |
Filed: |
January 28, 2005 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11045548 |
Jan 28, 2005 |
|
|
|
PCT/EP04/05211 |
May 14, 2004 |
|
|
|
60471237 |
May 16, 2003 |
|
|
|
Current U.S.
Class: |
709/204 |
Current CPC
Class: |
G06Q 10/06 20130101;
G06F 2209/547 20130101; G06F 8/34 20130101; G06Q 10/067 20130101;
G06F 9/5038 20130101; G06F 9/546 20130101; G06F 9/485 20130101 |
Class at
Publication: |
709/204 |
International
Class: |
G06F 015/16 |
Claims
What is claimed is:
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.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation-in-part of International
Application PCT/EP2004/005211, with an International filing date of
May 14, 2004, now pending; and claims the benefit of priority of
U.S. Provisional Patent Application No. 60/471,237 filed May 16,
2003.
FIELD
[0002] Some embodiments of the present invention relate to
enterprise systems. In particular, some embodiments are associated
with a messaging service for business applications in an enterprise
system.
BACKGROUND
[0003] 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.
[0004] 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.
[0005] 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.
[0006] Whichever approach is taken with respect to enterprise
system integration, certain costs will be associated with the
development of new systems and/or upgrades to existing systems.
Approaches that may reduce such costs may be desirable. Moreover,
it may advantageous to provide a system flexible enough to respond
to circumstances that are not anticipated or known when the system
is designed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0007] FIG. 1 is a block diagram of an enterprise system according
to some embodiments.
[0008] FIG. 2 is a block diagram of an exchange infrastructure and
a number of components according to some embodiments.
[0009] FIG. 3 is a block diagram of an exchange infrastructure
according to some embodiments.
[0010] FIG. 4 is a message flow diagram according to some
embodiments.
[0011] FIG. 5 illustrates interactions between a process engine
domain and workflow domains according to some embodiments.
[0012] FIG. 6 illustrates message mapping between an integration
process and business systems according to some embodiments.
[0013] FIG. 7 illustrates several types of business process flows
according to some embodiments.
[0014] FIG. 8 is a flow diagram of process steps pursuant to some
embodiments.
[0015] FIG. 9 illustrates a process calling a subprocess according
to some embodiments.
[0016] FIG. 10 is a high-level logical block diagram of an
integration server according to some embodiments.
[0017] FIG. 11 is a more detailed logical block diagram of an
integration server according to some embodiments.
[0018] FIG. 12 illustrates message mapping between a process, a
subprocess, and business systems according to some embodiments.
[0019] FIG. 13 illustrates a cancellation of a subprocess and a
nested subprocess according to some embodiments.
[0020] FIG. 14 is a flow diagram of process steps pursuant to some
embodiments.
[0021] FIG. 15 illustrates a process receiving input from a user
according to some embodiments.
[0022] FIG. 16 is a high-level logical block diagram of an
integration server according to some embodiments.
[0023] FIG. 17 is a more detailed logical block diagram of an
integration server according to some embodiments.
DETAILED DESCRIPTION
[0024] 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.
[0025] FIG. 1 is a block diagram of an enterprise system 10
according to some embodiments. The system may, for example, provide
for the integration and message-based interaction of applications.
The system 10 includes an exchange infrastructure 100 for
collaborative processing among internal components 20 of an
enterprise, and between external components 30 that communicate
with one or more internal components 20 through a firewall 40. The
internal components 20 and external components 30 may represent any
of a number of processes or services and their software and
hardware, such as Web portals, buying or selling programs,
electronic mail, business management programs, and project planning
programs. According to some embodiments, each internal component 20
and external component 30 communicates via messaging with one or
more other components according to at least one of a number of
communication protocols or standards.
[0026] The exchange infrastructure 100 may be a self-contained,
modularized exchange platform for driving collaboration among the
components 20, 30. The exchange infrastructure 100 may include, for
example, a central integration repository and directory storing
shared collaboration knowledge. The exchange infrastructure 100 may
also support open standards such as various standard markup
languages like the extensible Markup Language (XML), Web Service
Description Language (WSDL), and Simple Object Access Protocol
(SOAP) to provide an abstraction of technical interfaces for the
components 20, 30, and for message-based communications across
heterogeneous component interfaces. The self contained, modularized
functions of the exchange infrastructure 100 might be provided as
one or more Web services based on standard Internet technology, and
thus be published, discovered, and accessed within a network of
components 20, using open standards.
[0027] FIG. 2 is a block diagram of an exchange infrastructure 200
and a number of component applications 270 according to some
embodiments. To facilitate message-based collaboration among the
applications 270, the exchange infrastructure 200 may include an
integration repository 210, an integration directory 220, a system
landscape directory 240, and an integration server 230. The
integration repository 210 may capture design-time collaboration
descriptions of all software components that can communicate via
the exchange infrastructure 100. The integration directory 220 may
capture configuration-specific collaboration descriptions of the
system landscape at runtime, which may include accessing actual
component installations from the system landscape directory 240 and
connectivity descriptions for external components, all of which
represents the shared business semantics of the system landscape.
The integration server 230 may use shared business semantics at
runtime to execute message-based collaboration among the active
software components (e.g., associated with the applications
270).
[0028] 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.
[0029] 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.
[0030] The exchange infrastructure 100 may also include various
adapters 250 that provide connectivity between the integration
server 230 and various applications 270 (e.g., proprietary
applications, Web-based services, and/or third party applications).
The exchange infrastructure 100 might also include a Web
applications server that provides Web-based applications programmed
according to standard computing platforms using web-specific
programming languages such as Java. In some cases, an adapter 260
could be implemented external to the exchange infrastructure
200.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] The components in the system landscape director 340 may
represent component descriptions that include information about
application components, as well as information relating to their
dependencies on each other. In a specific implementation, the
component descriptions are based on the standard Common Information
Model (CIM) of the Distributed Management Taskforce (DMT). Since
the integration repository 310 includes design-time information,
only component-type information, independent of actual
installation, might be stored as components 340. The component
descriptions can be added using an API or interactively using a
graphical user interface.
[0038] 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.
[0039] The configuration-specific collaboration descriptions of the
integration directory 320 might be generated automatically from
content in the integration repository 310 or manually by a user
using a graphical user interface. In one implementation, the
integration directory 320 is built on a Java platform and its
content is represented via XML using open Internet standards. Note
that the integration repository 310 might be upgraded without
affecting the integration directory 320 or any runtime
collaborative processes. The user then decides which changes should
be transferred to the integration directory 320, either as
predetermined automatic upgrades or manually via graphical
tools.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] Each Web service description in the integration director 320
may also provide physical addressing details, access information,
and other special attributes such as Uniform Resource Locator
(URL), protocol, and security information. In one implementation,
the Web services are described in WSDL, and SOAP and ebXML are used
as messaging protocols. The integration runtime engine 330 accesses
information about the Web services at runtime.
[0047] 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.
[0048] The business partners in the integration director 320 may
define information for business partners of an enterprise, such as
names, addresses, and URLs. The partners may also contain more
detailed and sophisticated information. For example, the business
partners may include a description of the message formats that can
be directly received and processed, of security protocols used for
safe communications, or trading terms that are employed in the
partnership. The kind of information stored in business partners
can be governed by enterprise-specific decisions of the enterprise
using the exchange infrastructure 300.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] At runtime, business processes are instantiated and executed
by the business process engine 334, which executes the respective
Web services described in Web services independent of their
location according to the business process model. The business
process engine 334 may be independent of the semantics of the
executed business processes, and may be configured as a mediator
and facilitator for business processes to interact with technical
components of the runtime system landscape.
[0053] 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.
[0054] A communication path for a message 310 can include an
outbound proxy at the outbound interface from the sending component
system 410, through a runtime engine and adapter of the exchange
infrastructure 400 to a receiving component system 420, 430. Note
that a receiving component system 420, 430 might also utilize an
inbound proxy or an adapter.
[0055] 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.
[0056] After retrieving the required mapping from the integration
directory 320, the mapping service can either execute XSLT mappings
or Java code (or any combination in a given sequence) to the
content of the sent message. Below the integration layer,
messaging, queuing, and transport services move the message to the
intended or required receiver(s). After the message is transformed
into the format expected by each receiver, the physical address of
the required receiver service and other relevant attributes are
retrieved from the integration directory 320 and mapped to the
message.
[0057] 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.
[0058] 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.
[0059] According to some embodiments, a process definition module
utilizes XML objects and correlations to define processes, based on
deployment rules imported from objects from the integration
directory 320. The objects are based on the routings and mappings
defined for the system runtime configuration. The objects may also
be used to define business processes in the integration repository
310 and the design-time configuration of the system landscape. The
business processes may be integrated with other integration
repository 310 objects and tools, which allows links to and from
other objects. Moreover, processes (e.g., patterns and templates)
may be delivered to customers along with extension concepts.
Application specific content can also be delivered. Some
applications can create processes and/or extensions that can be
delivered to customers. According to some embodiments, a business
process management system includes an import/export framework that
imports and exports standards-based adapters for universal
connectivity. Such a system may also include an interface for
receiving user-specified business process details.
[0060] 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:
[0061] 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.
[0062] 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/acknowledgemen- ts ("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.
[0063] 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.
[0064] 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.
[0065] 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.
[0066] FIG. 5 illustrates interactions 500 between a process engine
domain and workflow domains according to some embodiments. In
particular, an integration server is orchestrating interactions
between a first, second, and third application systems. The
integration server may be, for example, a standalone component that
communicates via messages with the client application systems.
Message related functions (e.g., send, create, transformation,
merge, and split) may be realized by service calls to a messaging
layer of the integration server. For example, the integration
server might wait until messages are received from both the first
application system and the second application system before it
transmits a message to the third application system.
[0067] 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.
[0068] 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.
[0069] 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.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] For example, FIG. 9 illustrates a process 910 calling a
subprocess 920 according to some embodiments. That is, during
execution of the process 910 a step is reached in which the
subprocess 920 is called. According to some embodiments, input data
may be provided to the subprocess 920 during this step. Note that
the call might be performed by a send step of the process 910 that
transmits a message to a receive step of the subprocess 920.
Moreover, the send step may instantiate a correlation. According to
some embodiments, a "call subprocess" step may be used to start the
subprocess.
[0076] The subprocess 920 may then perform a task (e.g., looking up
information in a data warehouse). When the subprocess 920 completes
the task, response data may be provided to the process 910 (e.g.,
information from the data warehouse might be provided to the
process 910). Note that response data might be included in a
message transmitted by a send step of the subprocess 920 to a
receive step of the process 910.
[0077] According to some embodiments, execution of the process 910
is blocked or halted when the subprocess 920 is called. In this
case, execution of the process 910 might resume when the subprocess
920 completes the task (e.g., and provides the response data to the
process 910).
[0078] 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.
[0079] FIG. 10 is a high-level logical block diagram of an
integration server 1000 according to some embodiments. In
particular, an integration process is defined in an integration
repository that contains a set of design-time business messaging
service processes. According to some embodiments, a subprocess is
also defined in the repository. The integration process and
subprocess may, for example, be defined generically without
enterprise-specific routing information.
[0080] 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).
[0081] 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).
[0082] 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.
[0083] FIG. 11 is a more detailed logical block diagram of an
integration server 1100 according to some embodiments. As before,
an integration process is defined in an integration repository that
contains a set of design-time business messaging service processes.
According to some embodiments, a subprocess is also defined in the
repository. The integration process and subprocess may, for
example, be defined generically without enterprise-specific routing
information.
[0084] In the example illustrated in FIG. 11, the process includes
an "IF" statement with two branches, each containing a Sub-Process
Call (SPC). According to some embodiments, a configurable parameter
may be declared in the integration process. Moreover, the
configurable parameter may be used to assign a subprocess to a
variable (e.g., subprocess 1 might be assigned to P_SP1 and
subprocess 2 might be assigned to P_SP2). Thus, if the IF statement
will result in either subprocess 1 or subprocess 2 being
called.
[0085] 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).
[0086] 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.
[0087] FIG. 12 illustrates message mapping between a process, a
subprocess, and business systems according to some embodiments. As
with FIG. 6, Ox represents an outbound interface and Rx represents
an inbound receiving interface. Initially, the integration process
receives through R4 a message from a first business system. As a
result of that message, the integration process calls a subprocess
to perform a task (illustrated by a dotted line in FIG. 12). The
subprocess sends a message to a third business system through O4
and receives a message back from the third business system through
R4. The subprocess completes the task and the integration resumes
operation by transmitting a message to a second business system
through O5.
[0088] 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.
[0089] 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.
[0090] 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.
[0091] 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.
[0092] 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.
[0093] 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.
[0094] 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).
[0095] FIG. 15 illustrates a process 1510 receiving input from a
user according to some embodiments. The integration process 1510
executes until a step is reached that requires an input from a
user. At this point, it is arranged for a set of potential
selections to be displayed to the user (e.g., via a generic
business workplace user interface). For example, the user might be
asked to select one of five displayed options. The user may then
provide input (e.g., via a universal work list). For example, the
user might select the first potential selection, and the selection
may be passed to the integration process via a container element.
The integration process will then continue to execute based at
least in part on the user input (e.g., the left branch illustrated
in FIG. 15 might be taken when the user selects the first potential
selection while the right branch would be taken when he or she does
not). In this way, a system may be provided that is flexible enough
to respond to circumstances that are not anticipated or known when
the system is designed (e.g., because the user may make a decision
at run time).
[0096] FIG. 16 is a block diagram of an integration server 1600
according to some embodiments. In particular, an integration
process is defined in an integration repository that contains a set
of design-time business messaging service processes. The
integration process may, for example, be defined generically
without enterprise-specific routing information.
[0097] 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).
[0098] 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.
[0099] 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.
* * * * *