MXPA00011718A - Workflow synchronization - Google Patents

Abstract

A computer implemented method for workflow synchronization is provided. The first step comprises initializing the execution of a plurality of workflows. The next step is providing synchronization logic in at least one of the plurality of workflows. In the third step the execution of a workflow is paused until the synchronization logic is complete. In the final step the execution of the plurality of workflows continues.

Description

SYNCHRONIZATION OF WORK FLOW Technical Field of the invention This invention relates generally to the field of supply chain, enterprise and site planning and more particularly, to a work flow synchronization method.

Background of the Invention The applications and supply chain, business and site planning environments are widely used by the manufacturing entities for decision support and for assistance in administration operations. The decision support environments for the supply chain, the company and the planning site have evolved monolithic environments of single domain to monolithic environments d multiple domains. Conventional planning software applications are available in a wide range of products offered by several companies. These decision support tools allow entities to more efficiently handle complex manufacturing operations. However, supply chains are generally characterized by multiple, distributed and heterogeneous planning environments. Therefore, there are limits to the effectiveness of conventional environments when applied to the problem of supply chain planning due to monolithic application architectures. In addition, these problems are exacerbated when there is an "owner" of the entire supply chain.

It is desirable for the next evolutionary step for planning environments to establish a heterogeneous architecture of multiple domains that supports the multiple domain of product expansion, as well as multiple products and motor expansion. The integration of the various planning environments in a seamless solution can allow the supply chain planning between companies and between domains. In addition, an important function provided by some planning applications is object environment optimization rather than simply tracking transactions. In particular, the RHYTH family of products available from 12 Technologies provides optimization functionality. However, with respect to planning at the enterprise supply chain level, many conventional applications, such as those available from SAP, use enterprise resource planning (ERP) engines and n provide optimization.

The success or failure of a company can depend to a large extent on the quality of the decision made within the company. Therefore, decision support software, such as the 1 Technologies RHYTHM product family, which supports an optimal decision within the company can be particularly important to the success of the company. In general, optimal decisions are related to the domain of decision support where the domain is the extension of the "world" considered to reach the decision. For example, the decision that is being made may be how much of a given item a factory must produce during a given period of time. The "optimal" answer will depend on the domain of the decision. The domain can be, for example, just the same factory, the supply chain that contains the factory, the complete company, or the multiple company supply chain. (The last two can be considered as the largest domains or the multiple domains). Typically, the larger the domain of decision support, the better the decision will be. Consequently, it will be desirable for decision support software to cover even larger domains in the decision making process. One solution is to design workflows which can be a set of activities linked by data flows that together achieve some tasks. Workflows can be executed on one more workflow engines on one or more companies. Running work flows over different engines and different companies the ability to efficiently manage work flows becomes essential. What is required is a method of synchronizing workflows.

Synthesis of the Invention In accordance with the present invention, a workflow synchronization method is described that provides advantages over conventional site and enterprise planning and supply chain environments.

A method for synchronizing work flows is described. The first step comprises initializing the execution of a plurality of workflows. The next step is to provide logical synchronization in at least one of the plurality of workflows. In the third step the execution of the workflow is stopped until the logical synchronization is complete. In the final step the execution of the plurality of workflows continues.

A technical advantage of the present invention is the ability to design, synchronize and control distributed work flows over multiple companies. Another technical advantage is that of synchronizing and coordinating multiple instances of a work flow that runs on an engine.

The additional technical advantages should be readily apparent to one skilled in the art of the following figures, descriptions and claims.

Brief Description of the Drawings A more complete understanding of the present invention and the advantages thereof may be acquired with reference to the following description taken in conjunction with the accompanying drawings, in which like reference numbers indicate like characteristics and wherein: Figure 1 is a diagram of an implementation of a computer-implemented architecture that can support enterprise collaboration; Figure 2 is a diagram of an incorporation of the components of a global collaboration framework; Figure 3 is a diagram of the overall collaboration framework of Figure 2 wherein certain software elements constituting the particular modules are highlighted; Figure 4 is a block diagram of an incorporation of a system that allows collaboration within the companies for an optimal decision making.

Figure 5 is a block diagram of an incorporation of the use of a global collaborative workspace; Figure 6 is a diagram of an incorporation of a life cycle for a collaboration; Figure 7 is a diagram of situations where common software is present on both sides of a relationship and where it is not; Figure 8 is a block diagram of an embodiment of a security configuration for a case d axis to radius and from axis to network; Figure 9 is a block diagram of an embodiment of a security configuration of a case from eg to axis; Figure 10 is a diagram of an incorporation of an inter-firm workflow design that includes parameterization about groups; Figure 11 is a diagram of an incorporation of a change of administration by modifying a design of a workflow; Figure 12 is a diagram of an incorporation of the synchronization of work flows through multiple companies; Figure 13 is a diagram of the multiple instances of synchronization of a workflow; Figure 14 is a diagram of an incorporation of multiple synchronization workflows; Figure 15 is a diagram of an incorporation of the integration of a workflow with an outside world Figure 16 is a diagram of an incorporation of a data flow that runs in a single activity; Figure 17 is a diagram of an incorporation of a data flow divided through multiple activities Figure 18 is a block diagram of an incorporation of a common data model based on a transformation model; Figure 19 is a diagram of an embodiment of a direct transformation; Figure 20 is a diagram of an incorporation of different transformation and access levels; Y Figure 21 is a diagram of an incorporation of the replacement of an axle motor by a radio engine within a collaboration.

Detailed description of the invention The improvement of the decision support processes involves the expansion to provide a multi-company and enterprise level decision support for an optimal decision making. Technologically conceptually, providing multi-company or enterprise-level decision support differs from providing decision support at the factory level and at the supply chain level. The reasons for this may be, in the situations of multiple domains (such as business units within a company or multiple companies), different domains often operate a different decision support software. Also, in multiple domain situations, a domain can not usually force another domain to make a particular decision. In other words, the support of the optimal decision in this environment frequently requires that it be carried out in a negotiated environment as opposed to obligated.

Providing decision support and multi-domain situations can be achieved in order to pursue a collaborative approach to decision support rather than coercive one. Several communication and distribution processing technologies can be used to implement such an environment, including the Internet, the JAVA Web, XML, CORBA, etc., which help make possible a large-scale collaborative decision. The products will soon be available from 12 Technologies that allow a collaborative approach to decision support including the RHYTHM-GLOBAL COLLABORATION MANAGER (GCM) and RHYTHM-GLOBA COLLABORATION DESIGNER (GCD).

Collaboration System and Process Components Figure 1 is a diagram of an incorporation of a computer-implemented architecture that can support business collaboration. As shown, a global decision support architecture can be built on an underlying link, vision, global message, and data warehouse components. The collaboration can then involve a global collaboration designer (GCD) and a global collaboration manager (GCM) supported by the decision support architecture. The global collaboration designer can be used to design and initiate collaborations, and the global collaboration manager can be used to run the collaborations. In this scheme, collaborations can be referred to as modules and can be versions.

Figure 2 is a diagram of an incorporation of components of a global collaboration framework. As shown, the framework can allow an axis 2 company to collaborate with a radio company 4 and a network company 6. The company axis 2 and the company radio 4 each include or global collaboration administrator 8. The administrators of global collaboration 8 are coupled to and communicate with the respective internal global collaboration work spaces 10. An external global collaboration workspace 1 provides a means to share data between a company d axis 2, a company radio 4 and a company network 6. The company ej 2 can also collaborate through an electronic data exchange (EDI) 14 processor with an added value network (VAN). In addition, the axis 2 company can communicate collaborate with other companies axis using a global message bus 15.

In the operation, the primary collaboration driver may be the global collaboration manager engine 8 of an axis 2 company. The axis-to-axis relationship may be facilitated by the global message bus 15, and the axis-to-radio relationships and from axis to network can be facilitated by the external global collaboration workspace (GCW) 12. As shown, an axis 2 company can generally have a global collaboration work space 10 and an external global collaboration workspace 12. The internal global collaboration workspace 10 can be used to share data exchange with internet user interconnections as well as with an electronic information exchange processor 14. The external global collaboration workspace 1 can be used to share and exchange data with company radio 4 and companies network.

For security, the external global collaboration workspace 12 can be installed in a DMZ outside a corporate fire wall of an axis 2 company. This may mean that there are no direct connections necessary that have to be made from outside to inside the corporate protected re axis 2. The external global collaboration workspace can accept, for example IIOP, HTTP and HTTPS connections. In particular, the last two connections are useful for bridging existing fire wall configurations. In this way, a fire wall configuration on any client side (hub node) or server (radio node or network node that can make the solution more quickly deployable) is not necessary.

Figure 3 is a diagram of the overall collaboration framework of Figure 2 where certain software elements that constitute particular modules are highlighted. As can be seen, the software for the global collaboration management module can be present in the following places: the axis motor 8, in the radio engine 8, in the user-user user interconnection (Ul), in the radio-user user interconnection and in the network-node user interconnection. Additionally, the module can communicate with native applications 17 about the company axis 2 and the company radi 4. The communications with the native applications 17 can be either synchronous (dotted line) or asynchronous (solid line). Asynchronous communication with the native applications 17 can be facilitated by the internal global collaboration workspace 10, as shown. In addition, a global series data base (GSDB) can be present on side 2 of the company axis.

Figure 4 is a block diagram of an embodiment of a system, indicated generally with the number 16, which allows collaboration within and between companies for an optimal decision making. As shown, the system 16 includes an axis node 18 which can be a process within an axis motor running a computer system. The axis node 18 is coupled to and communicates with a radio node 20 which can also be a process within an engine of eg running on a computer system. As shown, the radio node 20 can be outside an enterprise limit 2 of the axis node 18. The axis node 18 is also coupled and communicates with a plurality of radio nodes 24 which can be processed within a radio engine that runs one or more computer systems. The axis node 18 can also be coupled to and communicate with a plurality of re-nodes 26 which can be processed within a network explorer running on a computer system. In addition, the axis node 18 is coupled to and communicates with an EDI representative (electronic data exchange) 28 which can provide a gate to the electronic data exchange systems.

Shaft motors and radio motors, together with the global collaborative workspace, can be primary entities of a global collaboration manager. In this environment, an axis motor is the primary controller of the collaboration. The shaft motor can coordinate with both global collaborations as well as with local collaborations. The global collaborations are those that extend to nodes d axis 18, to nodes of radius 20 and 24 and to network nodes 26. The local collaborations can run on a single paper axis or an axis or radio / radio group. These collaborations can be distributed, but remain within the confines of a single company. The axis motors can also be coordinated with the user-axis interconnections (Ul) as well as with the VAN-EDI processor of an electronic data exchange power 28. In one embodiment, the shaft motors or multi-spindle motors that You can coordinate simultaneously with multiple collaborations as well as multiple versions of such collaboration. In addition, axle motors can dynamically load and execute collaborations A radio engine can also operate to start a collaboration. In this environment, unlike an axis motor, a radio engine is not an independent entity. Instead of this a radio engine can only coordinate a collaboration in conjunction with an axis motor. In addition, a radio bike may not coordinate with other radio engines or other network nodes. As an axis motor, a radio engine can be multi-threaded and can simultaneously coordinate multiple collaborations as well as multiple versions of the same collaboration. Radio engines can also dynamically load and execute collaborations.

Figure 5 is a block diagram of an incorporation of the use of a global collaborative workspace 30. In Figure 5, the global collaborative workspace 30 provides the primary entity used to share data / objects among the various entities. entities in the collaboration As shown, the workspace 30 can interconnect with the global collaboration administrators (GCMs) 32, with the local system 34, with a network server 36 and a network interconnect 37 and with native applications 38. In general, the objects can be placed in a global collaborative workspace 30 by means of one entity and retrieved by another entity. The recovery can be accomplished either by mediant questions or by subscription. In this way, the global collaboration work space 30 combines the attributes of a database as well as a message bus.

The global collaboration workspace can be organized as a hierarchy of slots which can be in memory or be persistent. The grooves can also be in glue or be regular, and large fine allowances can be attached to each groove. The allowances can be assigned by the operation by the user. The primary operations can be read, write, take and subscribe.

Memory slots retain their data in volatile memory. The writing and recovery of the memory slots is very fast but is subject to loss if the overall collaborative work space 30 goes down. When used with slot memories, the global collaboration workspace 30 can be considered as an object database information in fast and secure memory, with security and message capabilities. Persistent slots retain your data in stable storage. The write recovery of the persistent slots is slower than the memory slots, but the data is not lost if the global collaboration workspace 30 goes down.

The decision to either use persistent or memory slots may depend on the application. The global collaboration work space 30 stores the data in the object form and can store Java objects, CORRA objects, arbitrary byte arrays. This, coupled with its memory capabilities, makes the global collaboration workspace 3 suitable as a high-speed data sharing mechanism among other object-oriented memory engines such as the factory planner and the supply chain planner. Technologies.

A global collaboration designer (GCD provides a tool to allow collaboration of designers to interactively design, launch and deploy collaborations to be run using the global collaboration manager.) The output of the global collaboration designer is a code that can be automatically loaded run by the global collaboration manager The global collaboration designer can allow designers to create new collaborations, retrieve existing collaborations, and version collaborations The global collaboration designer can also allow designers to design the network Axis and radio work to collaborate and design events and messages for collaboration The global collaboration designer can integrate a standard object library and a standard component library for easy use from within the global collaboration designer. designer Global collaboration can be used to create workflows of sophisticated multiple companies with sub synchronous workflows, asynchronous, and divisions, divisions, synchronization-unions, divisions-heterofusion heterofusion-unions, and so on. Global workflows and local workflows can be created both. The global collaboration designer can provide automatic verification of collaborations and automatic code generation, whose code is run by the global collaboration administrator. The generated code can be manually edited if desired. In addition, the global collaboration designer can provide the initiation of a generation that includes the generation of security administrator configurations and global collaborative workspace configurations.

Figure 6 is a diagram of an incorporation of a work cycle for a collaboration. As shown, in step, a collaboration can be designed using the global collaboration designer. Then, in step 46, a collaboration can be initiated using the global collaboration designer. Instanced collaboration can then be deployed, in step 44, using the global collaboration designer and the global collaboration administrator. After deployment, the collaboration can be run using the global collaboration administrator in step 46. Subsequently, a new instance or version of the collaboration can be created. To create a new instance, the flow returns to step 42. For a new version, the global collaboration designer can be used in step 48 to modify the collaboration.

The extension of single domain decision support to multiple domain decision support can be complicated. In particular, the following discussion describes the number of challenges presented by the decision support of multiple domains and the incorporations of how these challenges are examined by the present system and the process that allows collaboration within and between companies for a decision making process. optimum Heterogeneity of Representation A problem with collaboration is making a bridge between companies through a representative heterogeneity. Before successful collaboration can occur, the heterogeneity of representation across companies requires being bridged. Companies often represent the same data in different ways. These differences vary from semantic differences to technological differences, to differences in names and so on. An obvious solution to bridge these differences is standardization. However, this immediately raises the issue of what is the standard on which to agree. The present system and process avoid such requirement.

It should be noted that there may be three relevant categories of standards that need to be examined. These three categories are format standards, transport standards and semantic standards. The format standards refer to the technological formats in which the data / objects are encoded. The examples include XML Java Serial Streams, IIOP Serial Streams and the electronic data exchange information format. The transport standards are used to pass data. These can include HTTP, IIOP, RMI, DCOM, FTP, Value Added Networks, asynchronous message bus such as MQSeries, and so on. Third, semantic standards are the way in which the semantic content of the data is described. Examples include electronic data exchange, 12 common data model (CDM).

By considering the standards in this light an understanding of the issues may arise. A large amount of the current confusion stems from the fact that there may be standards covering two or more of the above-mentioned categories and that discussions of the various standards fail to categorize which category is being discussed. For example, the exchange Electronic data is primarily a semantic standard, but it also typically involves a format standard (the electronic data exchange file format) and a transport (a value-added network). Once this is understood, it becomes clear that the Semantic standard of electronic data exchange can be separated from the other two. Therefore, semantic electronic data exchange objects can be encoded in other formats such as Java Serial Streams and can be passed on to other transport standards such as HTTP. Similarly, XML is primarily a format standard that can be used to code several semantic standards. Efforts are being made to codify the electronic and XML data exchange.

Several format standards can be supported by the current global collaboration manager, including XML, the electronic data exchange format, the Java series streams (mentioned as Java format and not to be confused with the Java language or the Java platform) and the IIOP series currents. Of these, in an incorporation, the Java format is the primary format, and the rest are derived formats. Because the Java format can contain the behavior to produce the other formats, it has been chosen as the primary format. The XML, EDI, and IIOP formats can be derived from the Java format.

Figure 7 is a diagram of situations where the common computer program of 12 Technologies is present on both sides of a relationship where it is not. As shown, for example, when the GLOBAL COLLABORATOR ADMINISTRATOR RHYTHM is on both sides, nothing will be gained by converting to an intermediate format. This will introduce unnecessary inefficiency, and only the data (not the objects would be interchangeable, limiting the range of applications.) So when the same computer program is present on both sides, ordinary Java objects can be exchanged directly. for example, when the GLOBAL RHYTHM COLLABORATION ADMINISTRATOR is present only on one side, the XML or EDI (output) and interpreted (input) "objects" can be produced.

With respect to transportation standards, this global collaboration manager can support a variety of transport standards including HTTP, IIOP, asynchronous message buses. More details are provided below with respect to the types of multiple management relationship.

With respect to semantic standards, the present global collaboration manager can primarily support two semantic standards, EDI and RHYTHM-CDM. And electronic data exchange can be supported because this is generally the most popular semantic standard. However, it suffers from the disadvantage (among others) of n providing a deep coverage of the planning domain. The RHYTHM-CDM, on the other hand, provides a deep coverage of the planning domain and will provide appropriate constructions to carry out a support of Multiple company decision. Additionally, this format is supported by all the 12 Technologies planning engines.

In general, a problem with public standards, such as electronic data exchange, is that they can not adequately cover the data / object classes that companies would like to exchange. In addition, waiting for standards bodies to be standardized on a particular object may not be an option, and a supply chain will have no particular competitive advantage by using public standards. For these and other reasons the present global collaboration manager supports or alternative approach to standardization by supporting proprietary community standards. For example, using the RHYTHM-GCD, a community of companies can design a set of standards that are relevant to only that community. The RHYTHM GCM will support and enforce these proprietary community standards. The RHYTHM-GCD also supports a library of building block objects that may be composed of proprietary community standards. The proprietary community standards have a number of advances, including these can be designed to cover exactly the kinds of data / objects that companies would like to exchange; only the relevant parts require to agree on the particular standard, therefore the process will be faster than waiting for a standard body; the different standards can be developed for different categories of partners and, in the extreme case, a different standard for each partner; and standards can be developed that give the supply chain a competitive advantage over competitors.

Types of Multiple Relationships Another problem to allow collaboration is the management of multiple relationship types. Companies have relationships of various types with their partners. Some forms of relationships that may vary are: between the main trading partners on the one hand and between the trading partners on the other; between companies of approximately equal influence on the supply chain and between companies of unequal influence on the supply chain; and between companies with a high degree of technological sophistication on the other hand and between companies with an unequal degree of technological sophistication on the other. As it should be understood, these types of different relationships must be handled in a different way.

The present global collaboration manager can model business relationships as a radio axis nek, as described above and is shown in Figure 4. In this embodiment, the four types of relations are nek axes; axis -VAN-electronic data exchange; of radius axis and of axis to axis. Each type of relationship has its proper use.

With regard to the nek axis, when people spoke today of "E-Commerce", they often imply an architecture where the nek explorer speaks to a centralized server. This architecture has some advantages: the infrastructure for the support of this architecture is and typically in place; and all administration can be centralized on the server side. However, this architecture also has a great disadvantage in the sense that it requires the presence of a human on the browser side of the nek. Therefore, the system system automation is not possible. Based on these advantages disadvantages, this type of relationship can be seen when a company requires the exchange of information with either a smaller partner or a partner with less technological sophistication.

With respect to axis-to-VAN-electronic data exchange, the vast majority of the trade between electronic companies takes place today by sending electronic data exchange over value-added neks. The advantage of this approach may be that the system integration system is possible and that it is currently held on day d today. The disadvantages of this approach are: the great costs to send data on proprietary VANs; the high administrative costs due to the lack of a true standardization; the requirement of third-party tools just to convert from the true "standard" to an appropriate form for the company; there is no support for system-to-human integration; and there is no support for standard owners or corporate standards. Based on these other advantages and disadvantages, this type of relationship may be appropriate when supporting a legacy VAN-electronic data exchange environment.

With respect to the axis-to-radio, this type of relationship also allows a system-to-system integration such as the VAN electronic data exchange. Architecturally, the radio axis is a collaboration between an axis motor and a radio engine. The ratio of axis to radio can have the advantages of VAN-electronic data exchange; it can use the public Internet to reduce nek costs; the administrative costs are much lower than those of VAN-electronic data exchange because a large part of the nek infrastructure from axis to radio can be centrally displayed and managed; the real objects (and addition to only the information) can be exchanged allowing much more advanced collaborations; and multiple semantic standards can be supported including electronic data exchange, 12 - common data model and proprietary community standards. Based on the aforementioned characteristics, the axis-to-radio ratio may be appropriate when companies wish to carry out system-to-system collaboration. It may also be appropriate where a software program of 12 Technologies is not present in any of the companies. This is due to the ratio of axis to radius that can be deployed centrally by the axis company.

With respect to the axis to axis, the ratio is similar to that of axis to radius except that it takes place between the axis motors rather than an axis motor and a radius motor. Based on this characteristic, the ratio of axis to axis It may be appropriate among companies that wish to carry out a system-to-system collaboration. In addition, the axis-to-axis ratio may be appropriate when two companies have a separately purchased RHYTHM-GCM and have placed shaft motors.

There are differences between the shaft motors and the radio motors. In general, some engine capacities are superimposed on radio engine capabilities. The following Table provides an example of some of the differences.

TABLE Security An additional problem with a collaboration is the challenge of providing comprehensive security. Before companies can collaborate effectively, you need to examine the security issue. There can be many different facets to security in a collaborative context. A table of collaboration of any multiple companies must refer to all these different facets. The requirements for a collaborative security re may include that: exchange of data between the two partners should only be seen by the partners; that the data exchanged between the two partners must be invasion proof; a company must be able to verify that a partner is who says it is; the table should not introduce new security holes in the partners' network and the table should be relatively easy to implement and administer.

A security collaboration framework can be provided by implementing a comprehensive security strategy to refer to the above mentioned requirements. In an incorporation, the strategy has three different aspects for this: technological security, a frame allowance and data division.

The technological security can refer to the technological means used to guarantee security. This security can be used to provide: privacy verification, and information integrity. The privacy assured that no unauthorized person can see the data. Authentication involves authenticating that the parties to the collaboration are really who they claim to be. The integrity of data involves making it impossible for an unauthorized person to modify the data that is being sent in any form.

The precise security approach may vary based on the type of relationship described above. For example, a schema is detailed in the Table below TABLE As can be seen from the Table, all relationship types, with the exception of the axis-to-VAN EDI, can support security from SSL 3.0.

SSL 3.0 is a standard industry protocol used to support public key encryption over a socket-based connection and provides: privacy, client and server certification, data integrity and certified management. SSL 3.0 is a higher level protocol in which several public key cryptographic algorithms can be connected including RSA and Diffie-Helman.

Once the SSL greeting is completed, the next step is the authentication of the keyword of the user's name. This provides a certification beyond the one provided by SSL 3.0 itself. Keys can be stored using keyword-based PKCS coding (an RSA standard). Once a user or radio is certified, it is returned to an access sample. This access sample has a life of time specified by the administrator. The user can then access the system for the duration of the validity of the access sample. This has the beneficial effect of not requiring certification for each access. The application, which is accessed, certifies the access sample by validating the signature (which is a coded summary using the private key of the security administrator) of the administrator of said security.

The technological safety box is a part of the safety scheme. The other part has to do with the design of the collaborations themselves. The table should allow companies to easily give permits to various actions that other companies can carry out. The global collaboration workspace can support a hierarchical permission model with individual permissions attached to different data elements in the hierarchy. In particular, it can support read, write, take and subscribe permissions of specific user and specific speaker. Therefore, companies can fine-tune in detail who can read and what data, who can write what data, who can take what data and who can subscribe to write notifications about what data.

A third element in the security strategy of the collaboration table is the ability of the data division through several collaborative workspaces. In particular, collaborating work spaces are divided into an internal collaborative work space and an external collaborative work space. Only the data that requires the truly shared with the partners are in the external collaborator work space. The rest is in the internal collaborating work space. The external collaborated workspace is designed to be set up either outside the corporate fire wall or in an extranet or DMZ. The collaborative framework design does not require the external collaborated workspace to make decisions through the corporate fire wall on the Intranet (even though it could do so).

In an incorporation, global collaborations can use both external and internal collaborative workspaces. Local collaborations can use only the internal collaborative workspace and are therefore invisible to partner companies. Even for global collaborations only relevant parties use the external collaborated workspace. In addition, due to the permisibilida work framework described above, each partner company can only see (read write, take, subscribe) their own data.

Figure 8 is a block diagram of an embodiment of a security configuration for a case d axis to radius and from axis to network. As shown, a hub company 5 is coupled to and communicates with an internal global collaboration workspace 52 and an external global collaboration workspace 54. A radio company 56 and a network company 58 are connected through a server of network 60 au workspace of external global collaboration 54. The company network 56, as the company axis 50, has a workspace of global internal collaboration 62. Companies 50, 56 and 58 can be protected by walls of fire associated, while the extranet formed by the network server 60 and the external global collaboration work space 54 can be protected by a filtering director and communication via HTT over SSL 3.0.

Figure 9 is a block diagram of or incorporating a security configuration for an axis-to-axis case. As shown, a 64-axis company and a 66-axis company can communicate over a SSL 3.0 protected TCP / I connection. The communication can be between the separate global message agents 68 and 69. Both companies of axis 6 and 66 are protected by a wall of fire, as shown.

Work Flows Between Companies One of the problems with the decision support of multiple companies may be that there is no closed circuit collaboration. Instead, data can be thrown from one company to the next without a coherent workflow. In order to implement a closed-loop collaboration, and necessary support to create multiple enterprise workflows. The present administrator and designer of global collaboration makes it possible to build, deploy, monitor and change workflows of multiple sophisticated companies.

In general, a "workflow" can be a set of "activities" linked together by data flows that together accomplish some task. Workflows are typically executed on workflow engines. A "distributed workflow" can refer to a workflow that is executed on multiple workflow engines. In other words, the different parts of the workflow are executed on different machines or engines. A "node" can refer to the abstract entities on which different workflow engines run from a distributed workflow run and a "node group" can be a set of nodes grouped by some characteristics. A "distributed work flow of multiple companies" can be distributed workflows where the nodes are companies.

The parameterization of the workflows can be important for the collaboration of the companies. A "parametric work flow" is a workflow that is parameterized on several variables and can be distributed regular. The instantiation of the parametric workflow with different values of the parameter variables produces different instances of the workflow. A "distributed workflow parametized on nodes in a node group" can refer to distributed workflows where the workflow parameters are the nodes in a node group. Therefore, when the workflow is instantiated, it is ready for a particular node in a node group.

There are several important features for the workflows that can be supported by the present global collaboration. These workflows can be heavily typified. Strong typing will be essential to produce error-free and robust workflows. In essence, strong typing guarantees the type of a message at a design time. For example, if the workflow is designed to send a material account, then the strong typification ensures that it is physically impossible for a different object to a material account to be sent. For a workflow designed with the global collaboration designer executed with the global collaboration manager, this can make it impossible to still send an object of the wrong type. This capability is important to produce error-free and robust workflows.

Despite strong typing there are, for example, two scenarios in which the wrong object types would concbly be passed in the workflow: due to an error on the part of the designer of the workflow; and a malicious attempt by someone to harm the work flow. Both of these scenarios can be managed. The first can be handled by means of which it is impossible for an error in design to lead to such a scenario. The second can be handled by making the data flow tamper-proof by using a public clav encoding or other encoding scheme (characteristic integrity) as described above.

Another important characteristic is the support for the parameterized workflows on the groups. Some workflows of multiple companies involve a large number of companies. In such cases, it would be impractical to create individualized work flows for each partner. Instead of this it can be advantageous to create workflows that are parameterized on groups of partners. For example, in the field of procurement, two groups can be primary providers secondary suppliers. The primary provider group may have one type of workflow and the secondary provider group may have another type of workflow. Group-based workflows can be parametric in the sense that at the time run, an actual workflow can be created specific for a member of a group.

In the context of multiple companies, a company can collaborate, for example, with hundreds or thousands potentially from other companies. Each collaboration or workflow of multiple companies can be potentially (and typically unique.) However, the design of hundreds or thousands of specialized workflows with business partners is neither desirable nor possible. work or simply parametric variations on an underlying parameterized work flow For example, a company A can collaborate (in sales) with retailers, distributors, direct sales, etc. Therefore, it makes sense to group the various partners. example can be: WalMart Sears; the rest of the retailers besides WalMart and Sear (group); primary distributors (group) and secondary distributors (group). Now, the workflows with all the members, for example, of the group of primary distributors are variations on an underlying parametric distributed workflow, parameterized on the particular distributor and that group.

The workflows parameterized on a group can be supported by a workflow definition technique of HETEROCASTING. The HETEROCASTIN definition technique usually involves using a workflow definition with parameters to initiate heterogeneous workflow based on differences in the parameters. Therefore, the HETEROCASTING definition technique allows a distributed workflow not in parameters to be easily done (through a visual design tool) with parameters on nodes in a node group. There may be two primary workflow activities used to achieve this definition: a divided activity HETEROCAST and a linked activity HETEROCAST. All the activities between divided HETEROCAST and the HETEROCAST junction are set on parameters on the nodes of a node group to which these activities correspond.

Figure 10 is a diagram of an incorporation of the design of a workflow between companies that includes and put parameters on groups. As shown, the workflow can begin with a listening activity that waits for an event. Activity 70 can be linked to parallel activities 71 that link to a work sub-work 7 and a division of HETEROCAST 73. The work sub-work itself can include a workflow definition. With respect to HETEROCASTING, the workflow after dividing HETEROCAST 73 is done with parameters. Therefore, in the example of Figure 10, activity 74 is an activity with parameters. After activity 74, a bound HETEROCAST 75 receives the flow of activity 74. Sub-workflow 72 and bound HETEROCAST 75 are linked to an asynchronous synchronous union 76 which, in turn, links to an integrated event 7 (for example, multi-delivery). A type of workflow of l Figure 10 can be designed using the present global collaboration designer and can allow a complete representation of workflow for decision support between companies. This workflow can then be instanced implemented through the global collaboration manager present.

Figure 11 is a diagram of an administration change incorporation by modifying a design of a workflow. As shown, an initial workflow design may have an event 70 linked to a parallel activity division 71. Between the activity division 71 a link 76 may have for example, two activities 78. This workflow is once designed, it can be instantiated implemented using the global collaboration manager. If a change to the workflow is required, the global collaboration designer greatly alleviates the problem of making change. For example, a new activity 79 can be added between division 71 and junction 76. The workflow can then be reinstated and implemented centrally.

In particular, the HETEROCAST technique can allow the construction of distributed workflows and co parameters on nodes in a node group. This can allow a huge productivity gain on the design of individual workflows for members of individual groups. In addition, this technique makes a rapid design and prototype of workflows among sophisticated companies with hundreds of thousands of possible partners. The technique must be distinguished from conventional "multi-part" in which identical messages are sent to the various nodes (partners). In essence, multi-pairing allows a person to design a unique workflow that runs identically through multiple nodes. This differs from the HETEROCASTING technique, where the work flows run differently based on which node is rng.

A third important characteristic is support for workflows based on distribution. Workflows based on the distribution allow these work flows to be used specifically for generic distributions. This capacity allows the creation of generic or temperate workflows that can be instantiated in various scenarios. For example, the types of roles or distribution can be: partner paper, axle papers; radio group papers; network papers; network group papers; user roles. As an example of the roles or distributions, the partners' papers refer to the different roles or characters played by the partners. Therefore, a role of partner in the case of procurement is that of primary provider and secondary supplier.

Workflows based on sharing can lead to the concept of three different phases in the design execution of a workflow. The design phase is the fas in which the workflows based on distribution are defined The phase of the instance is the phase in which the distributions are mapped to instances. For example, the primary provider can be mapped to a first company, and the approver_PO can be mapped to John Doe. Third, the run-time phase may be the phase in which the workflow and instance runs.

An additional important feature is the integration of automated workflows with user-oriented workflows. Workflows can often be described as having two varieties: automated system-to-system workflows, and user interconnection workflows. Even though there are workflows that are fully automated, there are workflows that are completely user-driven, most workflows have automated interconnection elements as well as user interconnection. The present global collaboration of administrator and designer n It requires making this artificial distinction between the types of workflow. Therefore, workflows can be automated into parts and interact with users elsewhere. Both automated parts and user parts can span multiple companies.

An additional important feature is the synchronization of workflows. This can be the synchronization of work flows across multiple companies. The synchronization of more than one instance of workflow running on one or more engines or the synchronization of multiple workflows on one or more engines.

Figure 12 is a diagram of a workflow synchronization incorporation through multiple companies. To illustrate a workflow 200, it comprises an initial listening activity 70 that waits for some event. Then the workflow is divided into the parallel activity division 71 into a first branch of workflow 7 and a second branch of workflow 73, Each branch of work flow runs on a different company. Before workflow 200 is able to continue, it must wait for both branches to complete. This through a synchronization board 76 which expects the activities in all the different activities to be completed before continuing on an integrated event 77. Alternatively, if many companies are running the workflow, which requires being synchronized then the board of 76 synchronization can wait until all the activities in each company have been completed or this can wait until a certain number of companies have completed their tasks / activities.

Figure 13 is a diagram of a multiple instance synchronization incorporation of a workflow 210 running on one or more companies or engines. An instanci is a workflow of a certain kind. Multiple instances of a workflow are multiple copies of the workflow running on the same engine or through multiple engines (for example, engine set). A first workflow 210 is illustrated. A second instance 212 through a workflow instance 214 is also illustrated running. All these instances are running in parallel on the same engine. The difficulty lies in distinguishing different workflows for purposes of distinguishing where messages and data have come from and where messages and data are going to be directed. For example, each workflow can represent a workflow for the projection of purchase orders. At a point in the workflow information regarding the verification of a seller's account number can be sent from a workflow. Once the account number is verified, a message needs to be returned to the workflow. If only one instance is running, the technical workflow is direct. The complexity above when many instances of the workflow are running simultaneously One solution is to assign to each workflow instance a global workflow identification which is associated with that instance of the workflow as long as the workflow is running. Any message sent or sent by an instance can include identification of the unique global workflow. Based on this identification, multiple instances of the workflow can be managed and synchronized using the synchronization link activity.

Figure 14 is a diagram of an incorporation of the synchronization of multiple workflows. A first workflow 240 and a second workflow 242 are illustrated. The second workflow 242 requires that an event occur in the first workflow 240 or requires some information from the first workflow 240 before proceeding. Therefore, the first workflow 240 has a division d activity 71 which divides between the second workflow 24 and the continued operation of the first workflow 240. This is not a real connection of the workflows but rather what represents the flow of work. the information between work flows. In a second workflow 242 there is a junction-synchronization 75 which waits until it receives messages or data of its own activity 74 and the event information from the activity division 71. The logic for synchronizing the workflows is constructed in the synchronization-board 75 and may be specific to the type of workflow that is executed.

The above mentioned are a few examples of the different types of workflow flow synchronization. Workflows can also be synchronized temporarily, by the state of the workflow or on the basis of the user's input.

Integration with the outside world Figure 15 is a diagram of an incorporation of the integration of a workflow with the outside world. As described in the previous section, workflow can be created between companies and within companies. These workflows can be composed of activities tied together in various configurations. There is no restriction on what different activities of the workflow can do, however, one of the main tasks of these activities is to integrate with the outside world. Figure 15 shows how a workflow can be integrated with the outside world using a component-based approach to integration. Components can include accessors 80, transformations 82 transection objects 84, adapters, and flows 86.

The global collaboration manager can support a component-based integration model. E component-based integration model allows flexibility in the structuring of integration. There may be two types of components: primitive components and compound components. Primitive components may include accessor 80, transformers 82 and transfer objects 84 Compound components include adapters and flows 86. Compound components are constructed in terms of primitive components. In this scheme, the accessors 80 are used to access an external source such as SCP (supply chain glider), SAP, a database of network servers, e-mail, message buses, and so on. Accessors 80 can be used to read, write or listen to data sources and destinations. The transformers 8 can be used to transform the data in one way or another form. The transfer objects 84 are objects that can be passed from an activity to an activity or from a company to a company. Transfer objects 84 can optionally be converted to EDI, XML, CORBA, and so on. The accessors 80 and the transformers 82 can be tied together to form flows. A complete flow can be executed in a single activity as shown in Figure 16.

Figure 16 is a diagram of an incorporation of a data stream running in a single activity 92. As shown, a data source 90 may be accessible from providing data to an accessor component 94. The accessor component 94 may then be passing data through the transformer components 96 and 98 which provide data to the second accessor component 100. The data can then be stored in a data destination 102.

Figure 17 is a diagram of an incorporation of a division of data flow through multiple activities 104 and 106. As shown, the flow of Figure 1 differs from that of Figure 16 in that the components of Transformer 96 and 98 are within separate activities 104 and 106 and communicate with a transfer object. The data flows of multiple companies can be based on the model of Figure 17 rather than Figure 16.

With respect to the transformations, in an incorporation, two types of fundamental transformació can be supported: the transformations based on I2-CDM and the direct transformations. Transformations based on I2-CD are based on the COMMON DATA MODEL OF 12 TECHNOLOGIES (CDM) The common data model is a scheme available in both form of relationship and object.

Figure 18 is a block diagram of an incorporation of a transformation model based on 12 -CDM. As shown, transformers and accessors can be coupled to transform a data application into a data object CDM 110 and vice versa. For example, a supply chain planner (SCP) object 112 may be created by a supply chain glider accessor from the supply chain glider data 114. The supply chain glider object 112 may then be Transformed by a chain glider transformer d-CDM supply in a CDM 110 object. Similarly, an SAP 116 object can be created by an SAP accessor of the SA 118 data. The SAP 116 object can then be transformed by a transformer SAP-CDM in a CDM 110 object. The SAP accessor and transformer, as with other accessories and transformers can be combined into a standard SAP-CDM 120 adapter that can be used for CDM-based transformations and other components. As another example, a VAAN object 122 can be created by a VAAN accessor from VAAN data 124. The VAAN object 122 can then be transformed into a common data model object 110 by a VAAN-CDM transformer. These transformations work in another direction as well.

Figure 19 is a diagram of an embodiment of a direct transformation. In direct transformers objects are converted from one form to another without passing through an intermediate format. For example, as shown in FIG. 19, the supply chain glider (SCP) data 130 can be accessed by an SCP accessor to create SCP object 132. The supply chain glider object 132 can then be transformed. directly in a factory glider object (FP) 134. The factory glider object 134 can then be converted to factory glider data 136 through a factory glider accessor. This data flow can operate in another direction as well.

In these processes, there are several levels of granulation to which access and transformation can take place including the relation (table), the generic object (tree, graph, matrix, etc.) and the specific object (material count, plan, etcetera) to levels. Sometimes the access can only be available at one level (say table) but the transformation may be more appropriate at another level (generic object). For example, the hierarchical aggregate (a transformation form) is frequently appropriate over a tree object. However, the data can only be accessible in a tabular form. In this case, for example, the data must be accessed at the tabular level, transformed into a tree, and then the hierarchical aggregate applied to it.

Figure 20 is a diagram of an incorporation of different levels of access and transformation. As shown, access and transformation can have three levels A first level 140 can involve transformations access to the table. A second level 142 may involve access and transformations of a generic object (tree, graph, etc.) and a third level may involve a specific objective access (construction of materials, plan, etc.), transformations. In addition to the transformations between application formats, there may also be transformation between three levels as shown.

Development of Collaborations An important factor in a collaborative system of multiple companies is the ease with which collaboration can be deployed. As discussed, the present global collaboration manager can support four different kinds of partner relationships: from axis to network, from axis to radius from axis to axis, and from axis to VAN-EDI. Of these four, the a re axis has all the deployment characteristics of the traditional network applications. The axis-to-VAN EDI can be deployed to the extent that it levels an existing VAN-ED infrastructure. Even though the relation of axis to network is highly deployable, it may suffer from the problem of requiring a human on the network side of the relationship. In other words, it may not be suitable for a system-to-system collaboration.

The solution from axis to radio can provide maximum deployment in the system system collaboration environment. In the axis-to-radio realm, the radio engine is analogous to the network explorer, and the radio part of the collaboration is analogous to a network page. In a similar way the network page, the radio part of the collaboration can be designed centrally and deployed to the remote radio engines. Unlike the network page, there may be an integration that needs to be done remotely. This remote integration may be inevitable but it can be circumscribed defined precisely by the network part of the collaboration.

Another aspect of the deployment is the management d versions. Collaborations once designed and deployed are feasible to require change (in several different ways) as time progresses. It may be important that subsequent versions of collaborations are easily deployable as the initial versions. The present global collaboration manager can provide a complete support for the versions and the centralized redespllegue of the collaborations. In addition, the different versions of the collaborations can run simultaneously without impacting one another. This allows an existing version to be amusedly phased out while another version is phased in.

Another element of the deployment of the present global collaboration manager is the existing infrastructure level. This element is evident, for example, in the support of the relationship of axis to radio over the existing network protocols. The support of axis to radio on the existing network protocols can be important for rapid deployment since the modification or reconfiguration of an existing network infrastructure is not required. The large time savings in this regard can come from having to carefully modify the wall of fire designed safety infrastructures that may already be in place.

Many-to-Many Collaborations Support The present radio architecture to eg provides easy administration and deployment. However, in practice companies collaborate with many companies which in turn collaborate with other companies. Therefore, companies often form a graph or collaborating network. This can be supported through the ability to replace an axis motor with a radio engine at any time. This substitution capacity allows many to many collaboration networks to be grown organically rather than all at the same time.

Figure 21 is a diagram of an incorporation of the replacement of a network engine by a radio engine within a collaboration. As shown, a company (El) can deploy a 150-axis motor on itself and a radio-152 engine on all partner sites. In particular, a radio engine 154 may be a partner site (E2). If the partner site (E2) desires to design and control its own collaboration it can replace the radio engine 154 with an ej 156 engine. From El's perspective, E2 can still be a radio in collaboration with the El. However, this radio now runs on an axis motor 156 which can control its own collaborations with the radio engines 158. In addition, the radio motors 160 and 162 can be associated with a third device (E3) that interacts with both the hub motor 150 and the motor d shaft 156 on behalf of the company E3.

Extension of the Work Frame An important aspect of the present framework of work is its extension. Without the extension, the work frame may not be able to handle new situations and challenges it confronts. There may be several different dimensions for this extension. For example, a primary area of extension is in the area of semantic object rules. If the supported frameworks are not sufficient for a particular problem then the work framework can be augmented with new semantic standards. Additionally, the work frame allows the construction of proprietary semantic standards. In addition, the work frame can be extended by adding new accessors, transformers, adapters, etc. The standard component library can be extended both generally and by the end users.

Although the present invention has been described in detail, it should be understood that various changes, substitutions and alterations may be made thereto without departing from the spirit and scope of the invention as defined in the appended claims.

Claims (16)

R E V I N D I C A C I O N S

1. A method to synchronize workflows that includes: represent by a specific instance l execution of a plurality of workflows; provide a synchronization logic in at least one of the plurality of workflows; pause the execution of a workflow until the synchronization logic is completed; Y The execution of the plurality of workflow will continue.

2. The method, as claimed in clause 1, characterized in that the plurality of work flows are running through different companies.

3. The method, as claimed in clause 2, characterized in that the step of pausing the execution of the workflow further comprises the step d waiting until at least one sub-game of work flows reaches the same point.

4. The method, as claimed in clause 1, characterized in that the plurality of work flows are instances of the same work flow running on at least one company.

5. The method, as claimed in clause 4, characterized in that it further comprises the step d providing a unique identification number for each instance of the plurality of work flows.

6. The method, as claimed in clause 5, characterized in that the step of providing a logical synchronization further comprises using a global collaboration manager d engine in a company to coordinate messages and data between instances of the plurality of workflows using the unique identification number.

7. The method, as claimed in clause 1, characterized in that the plurality of work flows are different work flows and at least one work flow depends on another.

8. The method, as claimed in clause 7, characterized in that the synchronization logic is contained within a joining and synchronization activity.

9. A system for synchronizing work flows that includes: at least one engine that runs over at least one company; Y a plurality of workflows that run over the engine where the workflows are operable to execute a synchronization logic that causes the workflows to wait for a message or data.

10. The system, as claimed in clause 9, characterized in that at least a part of one of the plurality of work flows are running on different engines on different companies.

11. The system, as claimed in clause 10, characterized in that the workflow waits until all the workflows reach the same execution point.

12. The system, as claimed in clause 9, characterized in that all the plurality of work flows are instances of the same work flow running on the engine.

13. The system, as claimed in clause 12, characterized in that a unique identification number d is provided for each instance of the plurality of workflows.

14. The system, as claimed in clause 12, characterized in that the engine in the company coordinates messages and data between the instances of the plurality of workflow using the unique identification number.

15. The system, as claimed in clause 9, characterized in that the plurality of work flows are different work flows and at least one work flow depends on another.

16. The system, as claimed in clause 9, characterized in that the synchronization logic is contained within a joining and synchronization activity E M E N A method implemented by computer for workflow synchronization is provided. The first step involves the representation by a specific instance of the execution of a plurality of workflows. The next step is to provide the logical synchronization in at least one of the plurality of workflows. In a third step, the execution of the workflow is paused until the synchronization logic is completed. In the final step, execution of the plurality of workflows continues.