MXPA99006796A - A system and method for creating, executing and maintaining cross-enterprise processes - Google Patents

Abstract

A system and method for creating, executing, and maintaining shared, automated business processes across distributed organizations comprises capabilities that enable interoperation among heterogeneous information systems. The system includes a plurality of independent communicating subsystems called sites that have a server with common means of representing and executing shared public process definitions and private process definitions. Process execution comprises coordinated inter-site message exchanges that are coupled with controlled sequences of actions that are local to each of the sites. The public process definition or module captures interactions among the independent sites. Interactions include communication events in which one site sends a message of a known type to another site. Each definition specifies a set of valid sequences of communication events among the participating sites. Associated with any public process definition is a set of lower level or private process definitions or modules. The private process definition specifies a set of possible local actions that can be executed at the site when that particular public process node is executed. In the preferred embodiment, the private process definition is defined in terms of constructs such as operating parameters and software application interactions.

Description

A SYSTEM AND A METHOD TO CREATE, EXECUTE AND MAINTAIN CROSS BUSINESS PROCESSES BACKGROUND OF THE INVENTION 1. FIELD OF THE INVENTION The present invention relates in a general way to information systems, and in particular to a system and the methods that allow the coordination of the activity between distributed information systems. 2. Description of the Related Art The recent change in the structure of business organizations, from the independent monolithic entity to multiple interdependent companies, reflects a similar evolution in the computing systems of single central units to distributed networks of personal computers and workstations. Since computer networks are extremely efficient in communicating information and developing activities between distributed sites, modern networks should be the obvious beneficiaries of this revolution in technology. For example, routine activities such as ordering and confirming purchases could be performed automatically between existing systems by a shared computer network.

Numerous drawbacks in the state of the art, however, prevent the full exploitation of conventional network technology for inter-business or commercial purposes. The most pressing problems due to the use of shared networks between business or commercial partners are (1) the heterogeneity of the associated computer systems, (2) the heterogeneity of the data used by the associated systems, (3) security and communication reliability. between the systems, and (4) the legal, organizational and cultural limits between the partners. Regarding the heterogeneity of the system, organizations often use combinations of operating systems, intermediate systems and applications of programs and programming systems that are incompatible with each other. The diffusion of the deployment of intermediate systems is just beginning, but the interoperation between the leading fields has already been completely defined. Especially problematic are differences at the application level, which are fundamental and will continue to challenge implementers for some time. With respect to the second problem, the heterogeneity of the data, the different applications and users of these applications, often represent information in different ways or use different types of information to perform the same task. These gaps can be particularly significant when applications and their users are distributed among different companies. Bridging the syntactic and semantic gaps associated with the information may require a mix of transformation capabilities as well as neutral objects. With respect to the third problem, the security and reliability of the communication, any interaction between the systems of a business or commercial network will require the presence of reliable and safe communication channels among the participants. The security concern is especially imminent when the Internet is used as a link in the communication channel, since this means is susceptible to being heard illegally and other forms of security attack. With respect to the fourth problem, any attempt to automate business or commercial processes among multiple partners must overcome the numerous non-technical barriers associated with managing a product distributed among multiple organizations. These challenges include imbalances between project priority and resource allocation, language barriers, time zone differences and both corporate and government regulations. These challenges limit the levels of coordination that are achieved. Any technical solution, therefore, it should focus on minimizing the scope and complexity of the mutual requirements required to implement the solution. CurrentlyThere are at least five known methods for extending interdependent processes beyond a system of computers or other systems connected by the networking resources of conventional computers. The first is the manual method in which users of multiple computer systems communicate information to each other via telephone, fax or other means. The information communicated is then manually reduced in the respective computer systems. The manual method can be used to bridge gaps in automation, but it is obviously limited in its ability to strongly link partner processes reliably and efficiently. The second method, which arises in the era of the applications of the growing domestic core units, is known as Electronic Data Interchange (EDI), the EDI is a broadly defined term, although very often it refers to a particular set of standards or standards, technologies (Value Added Networks, Direct Marking, programs and programming systems for mapping), and practices used for the electronic exchange of data between companies. In the EDI, you can exporting a business or commercial information connection (for example, a purchase order) of an application system, plotted in a neutral format, transmitted to a partner via VAN (Value Added Network), traced by the partner in an appropriate format for its application, and imported into the partner application. Alternatively, direct dialing can be replaced by the VAN. The EDI, however, is usually batch oriented, requires extensive format customization and does not support processes. The third method, used when the business or commercial requirements do not conform to the EDI model, is to use a customized system designed and implemented according to the specifications of the users. This method is expensive, requires a mix of network programming and system integration tasks, and serves a specific purpose only for specific users. In addition, it is inflexible and difficult to modify. Recently, two trends in technology have radically changed the way in which application systems can be intertwined. As a result, a fourth and fifth methods, as well as an adaptation of the EDI, should be added to the three discussed above. The first trend is the rapid expansion of network infrastructure. The most visible component of this infrastructure is the ubiquitous conductivity provided by the Internet. Almost all organizations are, or will soon be, connected to the Internet. Coupled with this connectivity is an expanding set of technologies and intermediate services, such as distributed object structures and message-oriented intermediate units that facilitate more manageable distributed applications and promise greater interoperability of program components and programming systems . The second trend involves advances in business or commercial application systems that are used by companies. Key advances in these systems include the development of interconnects of objects and the development of capabilities to model the work / process flow. Object interconnections provide a more flexible and less scrollable method for moving information to and from applications, than earlier methods such as SQN (Structural Interrogation Language) or file-based interconnections. Several application vendors now provide the ability to design and implement the workflow between different application modules. This capability allows companies to focus more easily on their business processes and makes the need to connect the processes of business or commercial partners more obvious.

The most visible impact of these trends, and the fourth method of extending business or commercial interdependence, is the use of the World Wide Web for business-to-business interactions. In this model, an employee in a company has access to information, such as a catalog or transport information, that belongs to the business applications of another company using a standard Web browser. This method, however, is inadequate for many extended business processes that require dependent interactions between the application systems of different organizations. The fifth method exploits the recent technology of the intermediate units, which makes possible the creation of high performance distributed applications that are logically integrated. Although the same technology can be used to provide interoperation between application sequences of different vendors and between systems in different companies, significant challenges limit feasibility. First, employing the technology of the intermediate units is a coordination task that requires significant programming knowledge and a special understanding of security, synchronization and other aspects of the network. The cost of such an effort can be justified by the vendor of a distributed application, but the companies that want it To engage in a specific extended business process, they probably do not devote the required capital to building distributed systems from the bottom. Finally, the EDI adaptation, known as Internet-EDI, is currently in a number of methods that attempt to move the traditional EDI method discussed above to a means of transporting the Internet. These methods are motivated by the desire to reduce the high transportation costs associated with Value Added Networks (NPV). Indeed, these methods diverge very little from traditional EDI. The same message formats, programs and programming systems are used to draw maps and still enveloping constructs. The use of an open network, however, requires additional security, reliability and intervention capabilities that were initially part of a VAN service. In addition, the use of these additional services in an open network configuration must be supported by the programs and programming systems at the points of an information exchange. The Internet-EDI, therefore, suffers from key constraints, such as a lack of process support, a non-extensive representation formalism, and an integration arrangement that does not intertwine with new practices. The above methods do not meet the growing demand for implementation among automated processes, complex, fired systems that are safe and maintained. Thus, a system and method for planning and controlling extended business interdependence are needed that (1) specifically focus on interactions for existing business application systems, (2) support secure and reliable communication, (3) minimize the development of customized programming and programming systems; (4) have functionality to handle heterogeneous data repression formalisms; and (5) have the ability to support complex processes that extend outward and inward in enterprise applications.

BRIEF DESCRIPTION OF THE INVENTION The present invention is a system and method for creating, executing and maintaining cross-business processes. Cross-company business processes are automated, shared business processes or workflows between distributed information systems that include specific provisions for the automation of those processes across organizational boundaries and between heterogeneous information systems. The system is comprised of a plurality of independent communication subsystems called sites with common capabilities. Each of the sites includes a server with means of representation and execution of shared process definitions, common. These sites act in concert in the course of running processes between shared systems. The execution of the process includes exchanges of inter-site coordinated messages that are coupled to controlled sequences of actions that are local to each of the sites. In addition, each site can include any of a number of application programs and operating systems to run intersystem processes and internal processes on the server. The automated intersystem processes are represented in a system of the present invention in a two-tier process model. The upper level or interactions of public process definition / module captures between independent sites (each typically representing a level of business organization). Interactions include communication events in which a site, designated in the definition of the public process by a node, sends a message of a known type to another site. The definition of the public process, then, is a logical grouping or directed graph of interdependent communication events among a set of sites. Each definition specifies a set of valid sequences of communication events between the participating sites.

Associated with any definition of public process is a lower level set or definitions or private process modules. A definition of private process is attached to each node in a public process. The private process definition specifies a set of possible local actions that can be executed on the site, when that particular public process node is not executed. In the preferred embodiment, the definition of private process is defined from the point of view of constructs such as operation parameters and program application interactions and specific programming systems for the node or site.

BRIEF DESCRIPTION OF THE DRAWINGS Figures 1 is a block diagram of an extended enterprise that includes a plurality of sites having definitions of public process and private process definitions in accordance with the present invention. Figure 2 is a graphic representation of a public process definition that includes nodes, arcs and connections between them according to the present invention. Figure 3 is a flowchart of the process for executing a private process definition in accordance with the present invention.

Figure 4 is a block diagram of a system according to the present invention. Figure 5 is a flow chart of a method for distributing a public process definition in accordance with the present invention. Figure 6 is a flow chart of a method for installing a public process definition in accordance with the present invention. Figure 7 is a flowchart of a method for executing a case of a specific process type according to the present invention. Figure 8 is a graphic representation of a visual representation device showing a graphical user interface for editing the public process definition. Figure 9 is a graphic representation of a visual representation device showing a graphical user interface for editing the private process definition.

DESCRIPTION OF THE PREFERRED MODULE Referring to Figure 1, a preferred embodiment of an extended business system 100 is shown.

The extended business system 100 of the preferred embodiment in the present invention, preferably comprises a plurality of sites 101, 102 and 103 installed in different organizations that are coupled by a communication network 104. Those sites 101-103 form an extended enterprise 100, in which the internal processes of each site 101-103 are coupled with the internal processes of other 101-103 sites via coordinated sequences of information exchanges. For example, sites 101-103 can be commercial companies that comprise three elements of a distribution chain: distributor, manufacturer and customer. Those skilled in the art, however, will recognize that the sites 101-103 could be any types of business units or functions that may exist at any number of sites, and three sites 101-103 are provided by way of example only. Each of these sites 101-103 represents a purchase of control and is comprised of a set of application systems that store information and contain logic circuits to retrieve and modify that information. Exemplary applications include the application successions REP (Transmission of Enterprise Resources), Product Data Management Systems (PDM), logistics applications and Advanced Planning Systems (APS). The operation of the present invention includes coordinated sequences of actions within each site 101- 103, which are linked with coordinate sequences of information exchanges between different sites 101-103. Those actions executed within each 101-103 site primarily include the movement of information in and out of applications associated with sites 101-103. Each exchange of information between sites 101-103 is preceded by a sequence of actions within the sending site and is followed by another sequence of actions within the receiving site. In consecuense, those sequences of site-specific actions serve as the connections that link a set of information exchanges into a single coordinated sequence of interactions. The possible sequences of local actions and site-to-site exchanges are specified through a process definition language. This language allows the complex branching and branching of logic circuits and can capture the constraints that govern the relationships between local action sequences and site-to-site exchanges. More formally, the process definition language of the preferred embodiment includes nodes and arcuate elements that are combined in a specific and logical order to create a directed graphic (as described in Figure 2 and as will be further described). ahead) . A single node of origin 205-225 and a single node of destination 205-225 define each arched element. Each node 205-225 includes a set of input arcs and the associated logic that connects these to the antennas 205-225 and a set of output arcs and the associated logic that connects these to the consequent nodes 205-225. The relation between the input arcs for a given node 205-225 is defined by a logical phrase, which contains conjunctive conjunctions and possibly nested disjunctive, in which each arc is represented by a different propositive symbol. The output arcs for a given node are related by separate logical sentences in an equivalent way. The node 201 has no input arcs and is known as the initial node. The nodes 299 that do not have exit arcs are known as terminal nodes. In the preferred embodiment, a two-tier process model was used to represent the site-to-site information exchange collection and sequences of site-specific actions. A public process definition or module 116a specifies the relationship between all exchanges of site-to-site information. The sequence of possible actions within a single site 101, 102, 103, for a particular node in a public process definition 116a, is specified by a private process module definition 118a, 118b, 118c. Both definitions of public and private process 116a, 118a, 118b, 188c are constructed in the upper part of the process definition language with special interpretations for node 205-225 and arched elements. In a public process definition 116a, each nodal element represents a specific site 101, 102, 103 and each arched element represents a message of specific information contents that are sent from site 101, 102, 103, represented by the initial node of the node. arc to the site represented by the destination node of the arc. The graph for a public process can include only a single initial node. The definition of public process 116a, then, is a specification of "who, how, when" between a set of sites 101-103 for a particular purpose. Each public process definition 116a specifies a set of valid sequences of communication events between the participating sites 101, 102, 103. More specifically, the same public process definition 116a is provided to each site 101, 102, 103 that has an action in the definition of the public process 116a. As shown in Figure 1, each site 101, 102, 103 may have one or more definitions of public process 116a, one for each intersite process. In a private process definition 118a, 118b, 118c, the nodal elements represent specific programmatic actions and the arched elements specify the order in which those actions are executed. The private process definition 118a, 118b, 118c specifies how sites 101-103 process received messages and construct outbound messages. In addition, the private process definitions 118a, 118b, 118c specify what happens within a node of the public process definition 116a. Thus, private process definitions 118a, 118b, 118c include routines and processes that are designed for a particular site 101, 102, 103, to which the private process definitions 118a, 118b, 118c are assigned or on which they operate. . Even more particularly, the private process definitions 118a, 118b, 118c are designed for interaction using the operation systems, applications and resources of the site to which they are assigned. Thus, as described in Figure 1, each of the private process definitions 118a, 118b, 118c is different for each site 101, 102, 103. However, when the sites 101, 102, 103 are configured in a manner similar (for example, they have the same operating systems, applications and resources) the private process definitions 118a, 118b, 118c can be used or shared. Those skilled in the art will recognize that each site 101, 102, 103 may also include a plurality of private process definitions 118a, 118b, 118c, as described in Figure 1. The plurality of private process definitions 118a, 118b, 118c can be for a definition of public process 116a or different public process definitions 116a. The preferred embodiment models the information contained in the message sent between sites 101, 102 and 103 as objects with restricted structure and behavior. These objects are data containers whose possible contents are specified by object definitions 120a, 120b, 120c. In the preferred embodiment, an object definition 120a, 120b, 120c takes the form of a DTV (Definition of Document Type) of XML (Expandable Utility Margin Language). This definition specifies the lexicological and grammatical form of all objects of that type. The object definitions 120a, 120b, 120c are mentioned by both public and private process definitions. Referring now to Figure 2, an exemplary public process definition 200 is shown. The public process definition 200 is graphically represented as a flowchart. Figure 2 shows a definition of public process 20.0 that specifies a set of possible interactions between sites 101-103. The process 200 comprises a set of nodes 205 to 225 and a set of communication events 230 to 250. Each node corresponds to a specific site 101-103, and associated with each node 205 to 225 of the public process definition 200, find a private process definition 118a, 118b, 118c. Figure 3 shows an exemplary private process definition 300 associated with the node 210. Each communication event 230-250 that connects one node to another in a public process definition 200 represents the exchange of a message of a known object type. For example, the known objects can be any of the conventional types of business objects, such as a purchase order object, a confirmation message object, etc. Such objects 120a, 120b, 120c are defined in the object definition 120a, 120b, 120c, so that each site 101, 102, 103 may use the object definitions 120a, 120b, 120c as necessary to process the objects either at the public level or at the private level. In other words, the definition of public process 200 is a logical grouping or a directed graph of interdependent communication events 230-250 between sites 101-103 shown in Figure 1. This grouping specifies a set of valid sequences of communication events. between, the participating sites, 101, 102, 103. Specifically, the public process definition 200 describes in the communication event 230 a purchase order sent from site 101 to site 102. This purchase order is generated by the private process from site 101 associated with node 205. Node 210 is a branch node, and produce two communication events, 235 and 240 in that node. Depending on a specific branching condition, either event occurs or both events occur. The conditions under which those two events trigger are not indicated by the public definition 200, since they are known only for the site 102. Those conditions are contained in the private process definition 118b associated with the node 210, and from this mode site 102. Those skilled in the art will also recognize that the private process definition 118b may be a set of private process definitions corresponding to an instance of a public process definition 116a. The occurrence of events 235 and / or 240 produces the execution of the nodes that follow immediately and the execution proceeds in descending order in the figure. The node 225 represents a branch joining node that can expect one or all of the events in a set to connect to it. After the execution of node 225, the public process ends at terminal 249. Associated, with each node 250 to 225 of public process definition 200, there is a private process definition 118a, 118b, 118c. For example, Figure 3 shows a private process definition 300 associated with the node 210. Unlike a public process definition 200, the content of the process definition Private 300 is determined and known only by the corresponding site as site 102 in this case. The definition of a private process 300 includes a number of actions 305 to 330 that are controlled in accordance with a specified logic. Possible actions include external business application interactions, handwritten actions, user notification and approval, time delay, specification of the output object, and execution of a subprocess. All cases of the private process definition 300 have access to the object of the "Purchase Order" type that is contained in the communication event 230. Any action in the private process definition 300 can refer to this object. The private process definition 300 is restricted to producing an object either of the type "Recognition" or of the type "Purchase Order" which corresponds to the communication events 235 and 240 respectively. Referring now to Figure 3, there is shown an exemplary embodiment for a private process definition 300. The private process definition 300 starts at the initiating action 301 which is executed after the communication event 230 is completed. Those experts in the art they will recognize that the process would be similar for a variety of other private process definitions, so that once the object is transferred to or received by the site 101, 102, 103, the private definition that corresponds to the node after the communication event starts automatically. Private process 300 continues to action 305. Execution of action 305 involves placing a block of information corresponding to the purchase order received in business application 113. After completing action 305, execution continues to action 310 The action 310 involves consulting the business application 114 to determine whether the article associated with the Purchase Order of the communication event 230 exists locally or if the product is imported. The result of this query is placed in a variable called "IMPORTED" in a set of variables associated with the private process 300. The action 315 is executed after the action 310. The action 315 implies a conditional test IF-THEN-ADEM the value of IMPORTED in addition to a handwritten action. The results of this conditional test determine whether trajectory A or trajectory B is followed after completing action 315. The execution of trajectory A proceeds to action 320, which implies the construction of an object type "Recognition" and its designation as an exit from the private process. The execution of the path B proceeds to action 325, which involves the construction of an object of the type "Purchase Order" and its designation as an exit from the private process. Trajectories A and B complete the action 330, which involves the notification of a designated user via the e-mail transmission of certain status information associated with the execution process. This information includes identifying characteristics of the purchase order and results of the business application queries. After the execution of action 330, the private process ends, and the control returns to the level of the public process. The use of such private definitions is particularly advantageous because it provides uniform control and regulation of the intercycle processes, while allowing maximum flexibility through the use of private definitions that allow the controller of a particular site to implement the definition. Private in any number of ways according to parameters, resources and other restrictions for a particular site. Each site of the preferred embodiment includes a combination of components that support the design, implementation and maintenance of the public and private processes and the process time components that support the execution of those processes. Figure 4 shows the preferred configuration of an exemplary site 102. The standard site 102 is comprised of a single server 480 and one or more clients 460, 470 that communicate with the server over a 409 network. 460 and 470 and the server 480 operate on separate central computers. Clients 460 and 470 contain graphical user interfaces (GUI) 465 and 475 respectively. In addition, the server 480 includes or has access to the database 410 and the applications 420 and 430. In the preferred embodiment, the database 410 resides in a central computer that is separate from one, on which the server is located 480. The clients 460 and 470 and the server 480 share common representations of relevant information interacting on the 409 network according to a specific and conventional communication protocol. Such representations of shared information include public and private process definitions, object definitions, process execution histories, as well as information about other sites with which the site interacts. Human users 440 and 450 interact with site 102, via client GUIs 465 and 475 to view, create, edit and manage the shared information representations delimited above. For example, users 440 and 450 are able to view and edit graphic representations of public processes 200 and private processes 300 on GUIs 465 and 475. Figures 8 and 9 show a GUI screen loader corresponding to the definition of public or private process described above, with reference to Figures 2 and 3, respectively. The server 480 of the preferred embodiment is comprised of an intermediate row manager set 482, and an execution engine 484, a transport manager 486 and the adapters 488 and 489. The intermediate row manager set 482 controls the access and flow of information between the network 409, the engine 484 and the database 410. In addition, it implements the application logic, and ensures the consistency of information of those elements. With respect to network 409, set 482 measures access to information of concurrently operating clients and other components of server 480. As discussed in detail below, the installation of public and private processes 200 and 300 requires the prior approval of user 440 or 450. Once this approval has been received, it is introduced by the appropriate user to client 460 and 470 via the respective GUI. A local installation signal is then delayed on the network 409 for the server 480. The administrator set 482, acting on the received signal, initiates the installation of the process definitions of the 484 engine. During the installation, the execution 484 transforms the process definitions it receives into executing state machines, which are stored in database 410.

This transformation extracts from the public process definition all the nodes connected to arcs that imply the target site. The resulting state machine contains all the information necessary for a single site to participate in the execution of the original public process. Once the installation is completed. The administrator set 482 provides the engine 484 with any additional information stored in the database 410 or received from the clients 460 and 470, necessary to effect the execution of the process. The persistence of shared data is maintained by the communication with the database 410. Once the installation of the private and public process definitions 200 and 300 is completed, the 484 engine controls its execution. During execution, the execution engine 484 manages two key activities: inbound and outbound communication with other sites via transport manager 486 and interactions with applications 420 and 430 via adapters 488 and 489. The 484 engine also manages through of administrator set 482, various auxiliary activities including sending and receiving messages to and from users 440 and 450 and storing logical information in database 410. During the execution of a public process definition, such as definition 200, the administrator of transport 486 manages communications to and from the Internet 104. For example, the definition of public process 200 anticipates the receipt of purchase order 230 and recognition 245 by site 102, as well as the acknowledgment 235 and the purchase order. 240. In this capacity, the administrator 486 preferably handles the illogical retry of recognition (based on the properties of the service he is using). Messages are created outside of any specific transport service and the security of communication is based on the message. Receptions are supported without repudiation, both for the origin and for the delivery. During execution, adapters 488 and 489 measure the data flow between execution engine 484 and external applications 420 and 430. For example, referring to step 315 of private process definition 300, engine 484 can transmit an application through adapters 488 or 489 that application 420 or 430 determines whether the article in question is imported. In turn, the application will respond through the respective adapter. The adapter configuration options for the 488 and 489 are set by the authors or private processes for the associated site. Those adapters 488 and 489 communicate their acceptable configuration options to the middle row administrator set 482 at the time of their installation. The interface of configuration for the 488 and 489 adapters allows a private process to insert data into an external application, retrieve data from an external application or listen to a specific event produced by the external application, where the inserted, recovered or heard data is represented by a definition of object. The 488 and 489 adapters also ensure uniform properties of state / consistency management and auditory behavior through the different applications that can be integrated with the system. During the execution of the process, the adapters 488 and 489 plot the insertion, retrieval and listening for the actions specified in a private process, in specific interactions with target applications 420 and 430. The operation of a preferred mode site revolves around the life cycle a definition of the public process and the associated private process and object definitions. Shown in Figure 5, this cycle begins with the creation of a public process definition and, the definitions of referenced objects then continue with the distribution of the public process definition and object definitions, creation of definitions of necessary private process, installation of the process and ends with the execution of the process.

In step 502, the user creates a public process definition. The site on which the definition of public process 200 is created is known as the authorization site. The creation of the public process definition 200 includes the creation of all object definitions that represent site-to-site messages in the public process definition. In the preferred embodiment, the public process and object definitions are created by the controller unit users 440 and 450 interacting with the administrator set 482 through the client GUIs 465 and 475. During the creation of the public process definition 200, for example, user 400 specifies the sequence of interactions between all participating sites 101, 102, and 103 and the logic connecting those interactions. In this example, GUI 465 would present definition 200 as a set of icons interconnected by flow indicators that would appear to a large extent like the diagram in figure 2. Definitions for purchase order, recognition and rejection objects would also be created by user 440 via GUI 465 if n, or they exist previously. After the public process and the necessary objects have been defined, the user proceeds with the distribution of the process. In step 504, the authorization site sends over the Internet 104, the definition of authorized public process and limits the definitions of object to all the sites that participate in the public process. Those skilled in the art will recognize that the Internet 104 may be an Intranet over a local area network (LAN), an Internet or a wide area network (WAN), or the Internet. In this case, site 102 is the authorization site and sites 101 and 103 are the participating sites. In order that the site 102 sends the public process definition 200 and the associated object definitions over the Internet, the definitions are sent from the administrator set 482 to the transport manager 486 and from there to the transport administrators of the sites participants. After the reception of the public process definition 200 and the object definitions by the transport administrators of the participating sites, in this case the sites 101 and 103, the definitions pass from the transport administrator to the middle row administrators for the Persistent storage in the site database. After reviewing the received public process definition 200 and the object definitions via a client GUI, users on participating sites 101 and 103 must approve or disapprove the public process definition, approval or disapproval is sent via the administrators of the process. transport of the sites associated with the authorization sites. Although the definition of public process 200 is reviewed at particular sites 101 and 103, authorization site 102 expects approval or disapproval votes by the transportation administrator 486 in step 508 to be received. Approval or disapproval for sites 101 and 103 is probably a commercial concern, plus. what technique. If an associated site finds the business arrangements described in the 200 acceptable definition, an approval signal returns to the authorization site, in this case site 102. In step 508, the system tests the universal approval, if any participating site 101 or 103 disapproves the public process 200, the authorization site 102 will distribute an abort message via the transport manager 486 to the partner sites 101 and 103, thereby reaching step 510. In this case, the definition of public process 200 it is abandoned and sites 101, 102 and 103 can begin to negotiate a new definition of public process. If the public process definition is universally accepted in step 508, the authorization site 102 distributes a trusted message to each of the associated sites. After the trusted message has been transmitted by the authorization site and received by the participating sites, both the authorization site and the participating sites proceed with the creation of the private processes associated with the public process owned nodes. for each site. This is represented by step 514 in Figure 5. Each user of the site creates a private process definition for each node of the public process definition associated with the user's site. For example, user 440 creates private process definition 300 for node 210 and a companion private process definition for node 220, since nodes 210 and 220 are each associated with site 102. Similarly, a user at site 101 would create private process definitions for nodes 205 and 225, while a user at site 103 would create a definition for node 215. After successively implementing the necessary private process definitions, each participating site sends a message to the authorization site indicating the conclusion of the implementation of the private process. In step 516, the authorized site gathers the signals of completion of the private process of all the sites. If any site fails to implement one or more of the private processes, it will send a failure message to the authorization site. In this case, the implementation of the process will be aborted (step 518), and the definition of process 200 will be abandoned. Once the authorization site is received, the messages of all the participating sites indicating the successful implementation of the private process, and have successfully implemented their own private processes, the Authorization site can begin the installation process (step 520). The installation of the process (step 520) begins with the sending of the installation message authorization site to all participating sites. After receiving the installation message, each participating site installs a public process locally. Figure 6 shows a flowchart of a process for installing in a single site the private process definitions associated with a public process definition. In step 602, the public process definition and the associated private process definitions are passed from the administrator set 482 to the execution engine 484. In step 604, the public process definitions are compiled to produce a state machine that contains States only for the site in question. For example, the process of collecting the definition of public process 200 in site 102 will result in states associated with nodes 210 and 220. Registered in the state machine is an initiating event of each state. Continuing with the example of public process definition 200, site 102 records that event 230, a purchase order from site 101, triggers the state associated with node 210, and that event 245, an acknowledgment from site 103, triggers the state associated with the node 220. In step 606, each state of the state machine is linked by a order to "call" an associated private process definition. For example, site 102 will link private process definition 300 with the state associated with node 210. The result of this union is that when the state associated with node 210 is triggered by a purchase order from site 101, the definition Private process 300 is called and executed. In step 608, a determination is made as to whether the site in question is the initiator of the public process. If not, as in the example of site 102, the execution engine determines the start of the message to be received and registers it in the transport administrator. In the example of site 102, the two start messages are purchase order 330 from site 101 and recognition 245 from site 103. If the site is the initiator of a public process, the initial event for the first private process is internal to the site and is recorded in step 612 as a start event, a scheduled start, or the start of a subprocess. After successfully installing the public process, each participating site sends a confirmation and installation message back to the authorization site. In step 522, the authorization site collects installation confirmation messages from all participating sites. If any site is unable to install the public process, the public process is aborted 524, as described above. Installation Successful authorization site triggers the transmission of messages to all participants, indicating that the public process has been installed in all the sites involved. At this point, the process is ready for execution (step 526). As discussed above, the execution of a public process is actually carried out by the interactive executions of the associated private processes in the associated sites. The execution of a public process installed by a single site is shown in Figure 7. Execution begins at step 702 with an initial event that may include the following: reception of a message from the associated site, an event associated with an application, a scheduled start, or the start of a subprocess. For example, the node 210 of the public process definition 200 is initiated by the receipt of a purchase order message from the site 101. In step 704, the execution engine in the started site creates a step in the host machine. appropriate condition and fix the machine to the initial state. In step 706, the execution engine extracts data from the private process associated with the associated public process node. For example, after activating node 210, the private process definition 300 is accessible. In step 708, the execution engine passes the appropriate data including the contention of event 230 to the private process and initiates its execution. In step 710, the private process executes and returns data to the engine of execution, and in step 712, the engine acts on the basis of the returned data. For example, the private process 300 returns to the execution engine 484 an instruction to send an acknowledgment to the site 101 or a purchase order to the site 103. It should be noted that during the execution of the private process in step 710, the 484 engine can do use of applications 420 and 430. The execution engine 484 responds accordingly. In step 714, a determination is made by the execution engine to see if a local terminal state of the public process definition has been reached. This determination is a local determination and is limited to the participation of the site in the public process. For example, the conclusion of node 220 is a local terminal state for site 102, since this is the final node in process 200 that corresponds to site 102. Similarly, depending on the result of the accompanying private process, the conclusion of the node 210 may be a local terminal state for the site 102. If the local termination is found, the public process ends for the site in step 716. Step 716 is not complete until a trust protocol of two has been executed. phases between the sites 101, 102 and 103, ensuring the mutual conclusion of the execution of the process 200. If the local terminal state is not found in step 714, the transport administrator awaits the activation of the messages from the associated sites (step 718). For example, if the result of the node 210 is the transmission of a purchase order in the event 240, the transport administrator 486 waits for the acknowledgment of the event 245 to trigger the private process associated with the node 220. Once it has been received the start message in step 720, the execution engine looks for the state of the associated process in step 722. The private process then begins execution in step 706 and is performed as described above.

Claims (10)

1. A method for coordinating a process between a first site and a second site using a public process definition, comprised of a first node associated with the first site, a second node associated with a second site, and an arc connected to the first and second nodes , characterized in that it comprises: executing the first node defining the public process in a first site, executing a first associated private process definition by the information shared with the first node; and, after receiving the message defined by the arc, execute the second node of the definition of the public process in the second site, executing a second definition of the private process, associated with the information shared with the second node.

2. The method of compliance with the claim 1, characterized in that the arc is a business object.

3. The method of compliance with the claim 2, characterized in that it also comprises: in the first site, creating the definition of public process; distribute the definition of public process to the second site; in the first site, associate with a first node by the shared information, a first definition of private process that contains an action that precedes the transmission of the message of the first site; and in the second site, associate with the second node by the shared information, a second definition of private process that contains an action that follows the reception of the message by the second site.

4. The method according to claim 3, characterized in that the distribution step comprises, in addition: reviewing the definition of public process in the second site; and in the case of an approval of the definition of the public process in the second site, transmit a signal of approval of the second site to the first site; and, in the case of a disapproval of the definition of the public process in the second site, transmit a disapproving signal from the second site to the first site.

5. The method according to claim 4, characterized in that the distribution step comprises, in addition; in the case of receiving in the first site a sign of approval of the second site, transmit a message of trust to the second site; install the definition of public process and the first definition of private process in the first site; and, in the step of receiving in the second site the trusted message of the first site, installing the definition of the public process and the second definition of private process in the second site.

6. The method according to claim 5, characterized in that the distribution step further comprises: in the case of receiving a disapproval signal from the second site in the first site, transmitting an abort message to the second site.

7. The method of compliance with the claim 3, characterized in that it also comprises: in the first site, transforming the definition of public process into a first state machine; and, in the second site, transform the definition of public process into, a second state machine. The method according to claim 3, characterized in that it also comprises: registering in a first execution history of the process, the execution of the first node of the public process definition; register in a second history of execution of the process, the execution of the second node of the public process definition; audit the first and second stories of the execution of the process. 9. A method for coordinating a process between a first site and a second site, characterized in that it comprises: creating in the first site a public process definition that includes a first node associated with the first site, a second node associated with the second site , and an arc interposed between the first node and the second node; distribute the definition of public process to the second site; create in the first site a first definition of private process associated with the information shared with the first node and which defines an action that precedes the transmission of the message from the first site; create in the second site a second definition of private process, associated by the information shared with the second node and in which an action is defined that follows the reception of the message by the second site; execute the first node of the public process definition by executing the first private process definition in the first site; Y, after receiving the message, execute the second node of the public process definition by executing the second private process definition in the second site. 10. A method for creating a process definition that governs a process between the first site and the second site, characterized in that it comprises: creating in the first site a public process definition that includes a first node associated with a first site, a second node associated with the second site, and an arc interposed between the first node and the second node; distribute the definition of public process to the second site; create in the first site a first definition of the private process associated by the information shared with the first node, and in which an action is defined that precedes the transmission of the message of the first site; and, creating in the second site a second definition of private process associated by the information shared with the second node, and in, which is defined an action that follows the reception of the message by the second site. ' SUMMARY. INVENTION A system and method for creating, executing and maintaining automated, shared business processes, through distributed organizations that include capabilities that allow interoperation between heterogeneous information systems. The system includes a plurality of independent communication subsystems called sites that have a server with common means of representation and that execute public process definitions and shared private process definitions. The process execution comprises coordinated intersitial message exchangers that are coupled with controlled action sequences that are local to each of the sites. The definition of public process module captures interactions between independent sites. Interactions include communication events in which a site sends a message of a known type to another site. Each definition specifies a set of < Valid sequences of communication events between the participating sites. Associated with any definition of public process, there is a lower level set or definitions or private process modules. The definition of private process specifies a set of possible local actions, which they can be executed on the site when the particular public process node is executed. In the preferred embodiment, the definition of the private process is defined from the point of view of constructs such as operation parameters and interactions of the application of the programs, and programming systems.