MXPA00012057A - Exemplar workflow used in the design and deployment of a workflow for multi-enterprise collaboration - Google Patents

Abstract

An exemplar workflow is disclosed for use in the design and deployment of a workflow for multi-enterprise collaboration. The computer implemented process involves allowing a workflow design to include at least one exemplar workflow. The exemplar workflow is associated with an exemplar node allowing at least one activity to be parameterized over a plurality of nodes within a node group. The process then involves instantiating the workflow such that the at least one exemplar workflow is instantiated as a plurality of activities each associated with a specific node in the node group. The workflow is deployed by distributing the activities over the nodes in the node group to provide multi-enterprise collaboration.

Description

WORKING FLOW OF EXAMPLE USED IN THE DESIGN AND DEPLOYMENT OF A WORK FLOW FOR THE COLLABORATION OF MULTIPLE COMPANIES TECHNICAL FIELD OF THE INVENTION This invention relates in general to the field of the supply chain, of the company and of the planning site and more particularly, to an exemplary workflow used for the design and deployment of a workflow for inter-enterprise collaboration.

BACKGROUND OF THE INVENTION The applications and supply chain, business and planning site environments are widely used by the manufacturing entities for decision support and to help administration operations. The decision support environment for the supply chain, the company and the planning site have evolved from single domain monolithic environments to multiple domain monolithic environments. Conventional planning software applications are available in a wide range of products offered by several companies. These decision support tools allow entities to manufacture complex operations more efficiently. 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 step to evolve for planning environments to establish a heterogeneous architecture of multiple domains that supports multiple product expansion domains, as well as expansion products and multiple engines. The integration of the various environments planning in a seamless solution can allow supply chain planning between company and between domini In addition, an important function provided by some planning applications is the optimization of the object environment rather than simply the transactions d tracking . In particular, the RHYTI product family. Available from i2 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 that has been made within the company. Therefore, decision support software, such as the RHYTHM family of products from Technologies, that supports an optimal decision within the companies can be particularly important for business success. 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 that a given item must produce a factory for 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 process of making the decision. However, this expansion of coverage can create significant problems SYNTHESIS OF THE INVENTION In accordance with the present invention, an example work flow used for inter-enterprise collaboration is described as providing advantages to conventional supply, enterprise and site planning network environments.

According to one aspect of the present invention, an exemplary workflow is described for use in the fold design of a workflow for the collaboration of companies. A process implemented by computer involves allowing a workflow design to include at least an exemplary workflow. The exemplary workflow is associated with an exemplary node that allows at least one activity to be parameterized over a plurality of nodes within a group of nodes. The process then involves placing the workflow instance so that at least one exemplary workflow is put into instances as a plurality of activities each associated with a specific node in the group of nodes. The workflow is deployed by distributing the activities over the nodes in the group of nodes to provide a collaboration of multiple companies.

A technical advantage of the present invention is the ability to design, deploy, deploy, execute, monitor and modify collaborations of sophisticated multiple companies using an example workflow for a group of related nodes.

The additional technical advantages should be readily apparent to one skilled in the art of the following figures, description 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 incorporation of a computer-implemented architecture that can support the collaboration of companies; 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 or incorporation of a system that allows collaboration within the companies for an optimal decision; Figure 5 is a block diagram of incorporating the use of a global collaborative workspace; Figure 6 is a diagram of an incorporation a life cycle for a collaboration; Figure 7 is a diagram of situations in which the 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 of 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 administration change incorporation by modifying a design of a workflow; Figures HA and 11B are a diagram of another incorporation of the design of an in-company workflow that includes the parameterization on groups; Figure 12 is a diagram of an incorporation of the integration of a workflow with the outside world Figure 13 is a diagram of an incorporation of a data flow that runs in a single activity; Figure 14 is a diagram of an incorporation of a data flow divided through multiple activities; Figure 15 is a block diagram of an incorporation of a common data model that is based on the transformation model; Figure 16 is a diagram of an incorporation of a direct transformation, - Figure 17 is a diagram of an incorporation of different levels of access and transformation; Y Figure 18 is a diagram of an embodiment of the replacement of an axle motor for a radio engine within a collaboration.

DETAILED DESCRIPTION OF THE INVENTION The improvement of decision support processes involves the expansion to provide 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 that in situations of multiple domains (such as business units within a company or multiple companies), different domains frequently operate a different decision support software. Also, in multiple domain situations, one domain generally can not force another domain to be a particular decision. In other words, the support of the optimal decision in this environment often needs to be carried out in a negotiated environment in coercive opposition.

The provision of decision support situations of multiple domains can be achieved for the purpose of a collaborative approach to decision support rather than a coercive one. Several communication and distributed processing technologies can be used to implement such an environment, including the Internet, We JAVA, XML, CORBA, etc., which help to make possible a large-scale collaboration decision. The products will soon be available from 12 Technologies that allows collaborative approach for decision support include RHYTHM-GLOBAL COLLABORATION MANAGER (GCM) and RHYTHM-GLOB COLLABORATION DESIGNER (GCD).

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

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

In the operation, the primary controller of the collaboration can be the GCM engine 8 of a company axis 2. L axis-to-axis ratio can be facilitated by the global message bus 15, and the relations of axis to radius and axis to The network can be facilitated by the external global collaboration workspace (GCW) 12. As shown, an axis 2 company can generally have a global collaborative workspace 10 and an external global collaborative workspace 12. E space of internal global collaboration work 10 can be used to share and exchange information with internet user interconnections as well as with an electronic information exchange process 14. The global collaboration work space 12 can be used to share and exchange information with 4 radio companies and companies axis For security, the external global collaboration workspace 12 can be installed in a DM2 outside a corporate fire wall of a company axis 2 In this way there are no necessary direct connections that have to be made from outside to the protected corporate network of the company axis 2. The external global collaboration workspace can accept, for example, IIOP, HTTP connections HTTPS. 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 (radio node or network node) server (hub node) that can make the solution more rapidly deployable is not necessary.

Figure 3 is a diagram of a global collaboration network 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: in the engine of axis 8, in the radio engine 8, in user-user-user interconnection (Ul), in the user radi Ul and the network-node Ul. Additionally, the module can communicate with native applications 17 about the company axis 2 the company radio 4. The communications with the native applications 17 can be either synchronous (dotted line) asynchronous (solid line). Asynchronous communication with the native applications 17 can be facilitated by the internal global collaboration work space 10, as was shown In addition, a global serial database (GSDB) can be present on the side 2 of the enterprise axis.

Figure 4 is ur. block diagram of an incorporation of a system, indicated generally with the number 16, which allows collaboration between and through the company for an optimal decision making. As shown, the system 16 includes an axis node 18 which can be a proces within an axis motor running a computer system The axis node 18 is coupled to and communicates with a radio node 20 which also It can be a process inside an axle motorcycle that runs on a computer system. As shown, the radio node 20 may be outside a company boundary 22 of the hub node 18. The hub node 18 is also coupled to and communicates with a plurality of radio nodes which can be processed within an engine. of radio that runs one or more computer systems. The cube node can further be coupled to and communicate with a plurality of network nodes 26 which can be processed within the network browser running on a computer system. In addition, cube node 18 is coupled to and communicates with the 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, a cube engine is the primary controller the collaboration. The shaft motor can coordinate with global collaborations as well as with local collaborations. L global collaborations are those that reach nodes of ej 18, radio nodes 20 and 24 and network nodes 26. A local collaboration can run on a single paper any radio or radio station. 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 processing of an electronic data exchange representative 28. In an embodiment, the shaft motors are multiteech motors that can coordinate simultaneously multiple collaborations as well as multiple versions of the same collaboration In addition, axis engines 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 can not coordinate with other radio engines or other network nodes. As an axis motor, a radio engine can be multi-wore and can simultaneously coordinate multiple collaborations as well as multiple versions of the same collaboration. Radio engines can also dynamically load 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 information / objects among the various entities. entities in the collaboration. As shown, the workspace 30 can interface with the global collaboration managers (GCMs) 32, with a local system 34, with a network server 36 a network interconnect 37 and native applications 38. general, the objects can be placed in a global collaborative work space 30 by one entity and retrieved by another entity. The recovery can be achieved either by question 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 slots can also be queued or be regular, and large or fi permissions can be attached to each slot. The permissions can be assigned per user per operation. The primary operations can be read, write, take and subscribe.

The memory slots retain 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 is dropped. When used in memory slots, the global collaboration space 30 can be considered an object database in secure and fast memory, with security and messaging capabilities. The persistent slots retain your data in a stable warehouse. Writing and recovering persistent slots is slower than for memory slots, but data does not lose if the collaborative glob workspace 30 is dropped.

The decision as to whether to use the memory or persistent slots may depend on the application. The global collaborative workspace 30 stores the data in the form of objects and can store JAVA objects, CORBA objects, an arbitrary BITE array, this, coupled with its memory capabilities, makes the global collaboration workspace appropriate as a mechanism of sharing high-speed data among other object-oriented memory engines such as FACTORY PLANNING AND CHAIN PLANNER SUPPLY OF TECHNOLOGIES.

A global collaboration designer (GC provides a tool to allow designers to interactively design, instantiate and deploy collaborations that will be run using the global collaboration manager.) The output of the global collaboration designer is a code that can be loaded The global collaboration designer can allow the designers to create new collaborations, retrieve existing collaborations and version collaborations, and the global collaboration designer can also allow the designers to design the network. axis and radio pa collaborations and design of events and collaboration messages The global collaboration designer can integrate a standard object library and a standard component library for easy use from within the global collaboration design. glo bal can be used to create workflows of multiple sophisticated companies with synchrony to synchrony, its workflow divisions or -divisions, unions-synchronization, heterofundid divisions, heterofundido unions, etc. Global workflows and local workflows can both be created. The global collaboration designer can provide automatic verification of collaborations and automatic code generation, whose code is managed by the global collaboration manager. The generated code can be manually edited if desired. In addition, the global collaboration designer can provide the initiation of a collaboration that includes the generation of security administrator configurations and global collaborative workspace configurations.

Figure 6 is a diagram of a life cycle incorporation for a collaboration. As shown, in the step, a collaboration can be designed using the global collaboration designer. Then, in step 46, a collaboration can be instantiated using the global collaboration designer.

Instanced collaboration can then be deployed, on floor 44, using the global collaboration designer and global collaboration administrator. After the deployment, collaboration can be run using the global collaboration manager in step 46. Subsequently, a new instance can be created or a new version of the collaboration can be created. To create a new instance, the flu 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 dominion decision support to multiple domain support can be complicated. In particular, the following discussion describes a number of challenges presented by multiple domain decision support incorporations of how these challenges are examined by the present system in processes that allow collaboration within and between companies for optimal decision making.

Representational Heterogeneity 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 etc. 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. For example, the examples include XML, Java Serial Streams, IIOP Serial Streams, and the electronic data exchange information format. Transportation standards are used to pass data. These can include HTTP, IIOP, RMI, DCOM, FTP, Value Added Networks, asynchronous message bus such as MQSeries, etc. 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 The electronic data exchange semantic standard can be separated from the others. 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 data exchange in KML.

Several format standards can be supported by the current global collaboration administrator, 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 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. Further details are provided below with respect to the types of multiple management relationship.

With respect to semantic standards, present global collaboration manager can primarily support two semantic standards, EDI and RHYTHM-CDM. Electronic data exchange can be supported because this is generally the most popular semantic standard. However, it suffers from the disadvantage (among others) of providing deep coverage of the planning domain. The RHYTHM-CDM, on the other hand, provides deep coverage of the planning domain and will provide appropriate constructions to carry out decision support. of multiple companies. 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 just 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.

Multiple Relationship Types 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 smaller trading partners on the other; between companies of approximately equal influence on the supply chain and between-companies __ unequal influence on the supply chain; and between the 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 different ways.

The present global collaboration manager can model the relationships of companies as a radio axis network, as described above and shown in figure 4. In this embodiment, the four types of relations are network 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 network axis, when people spoke today of "E-Commerce", they often imply an architecture where the network 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 network. Therefore, the system system automation is not possible. Based on these advantages disadvantages, this type of relationship can be appreciated 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 electronic business-to-business commerce takes place today by sending electronic data exchange over aggregate heat networks. The advantage of this approach may be that the system integration system is possible and that you are currently holding the day 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 a legacy VAN-electronic data exchange environment is supported.

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 axis to radio is a collaboration between an axis motor and a radio engine. The ratio of axis to radius can have the advantages VAN-electronic data exchange; it can use the public network to reduce network costs; the administrative costs are much lower than those of VAN-electronic data exchange because a large part of the network infrastructure from axis to radio can be centrally displayed and managed; the real objects (addition to information only) 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 above-mentioned characteristics, the axis-to-rad ratio may be appropriate when companies wish to implement a 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 displayed 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 occurs between the axis motors rather than an axis motor and a radius motor. Because of this characteristic, the ratio of Axis may be appropriate among companies that wish to carry out a system-to-system collaboration. In addition, axis-to-axis ratio may be appropriate when two companies have a separately purchased RHYTHM-GCM and have put axle motors.

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

Security An additional problem with a collaboration is the challenge of providing a comprehensive security.

Before companies can collaborate effectively, the security issue needs to be examined. There are many different facets to security in a collaborative context. A collaboration table of any multiple companies must refer to all these different facets. The requirement for a collaborative security network can include: data exchange between the two partners should only be seen by the two partners; that the data exchanged between the two partners should be invasion proof; a company to be able to verify that a partner is who says it is; box should not introduce new security holes in the r of the partners; 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 address the above requirements. In an incorporation, the strategy has three different aspects for this: technological security, or 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 As can be seen from the table, all the 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 certification as well as server, data integrity and certificate handling. 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. The 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 codified summary using the administrator's private security key) 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, this 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 invisible to the 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 50 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 connect through a server 60 network to an external global collaboration workspace 54. The 56 network enterprise, like the 50 axis company, has an internal global collaboration 62 workspace. Companies 50, 56 and 58 can be protected by associated firewalls, while that the extranet formed by the network server 60 and the external global collaboration space 54 can be protected by a filtering director and the communication via HT over SSL 3.0.

Figure 9 is a block diagram of an embodiment of a security configuration for a case d axis to axis. 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 global message agents 68 and 69. Both companies of axis 64 and 66 are protected by a firewall, as shown.

Workflows Entre-Empresas 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 streams that together accomplish some task. Workflows are typically executed over workflow engines. A "distributed work flow" can refer to a workflow that is executed over multiple workflow engines. In other words, 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 node set grouped by some characteristics. A "distributed work flow of multiple companies" can be distributed workflows where the nodes are companies.

The parameterization of work flows can be important for the collaboration of 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 parametizado on nodes in a node group can refer to distributed workflows of the workflow parameters are the nodes in a node group Therefore, when the workflow is instantiated it is made to a node particular 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 conceivably 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 managed by making it impossible for an error in design to lead to such a scenario. Second can be handled by making the data fluy tamper-proof by using a public cry encoding or other coding scheme (integrid feature) 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, it may 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, a workflow can be created specifically for a member of a group.

In the context of multiple companies, a company can collaborate, for example, with hundreds or thousands potentially other companies. Each collaboration or workflow of multiple companies can be potentially (and typically unique).The design of thousands of specialized workflows with business partners is neither desirable nor possible. On the other hand, many of these workflows are simply parametric variations on an underlying parameterized workflow. For example, a company A can be a collaborator (in sales) with retailers, distributors, direct sales, etc. Therefore, it makes sense to group the various partners. An example grouping can be: WalMart, Sears; the rest of the retailers besides WalMart and Sears (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 in 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 activities divided between HETEROCAST and HETEROCAST are placed on parameters on the nodes of a group from node to l corresponding to these activities.

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

Figure 11 is a diagram of an administration change incorporation by modifying a design of a workflow. As shown, an initial workflow design can have an event 70 linked to a parallel activity division 71. Between the activity division 71 a link 76 there can be, for example, two activities 78. This workflow, 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 parameters on nodes in a node group. This can allow a huge productivity gain over the design of individual work flows for members of individual groups. In addition, this technique makes a rapid design and prototype of sophisticated inter-company workflows with hundreds of thousands of possible partners. The technique must be distinguished from conventional "multi-delivery" in which identical messages are sent to the various nodes (partners). In essence, multi-delivery allows a person to design a unique work flow that runs identically through non-multiples. This differs from the heterorepair technique, where workflows run differently based on which node they are running.

Figures HA and 11B are a diagram of the incorporation of the design of an inter-empres workflow that includes the parameterisation on groups. As described above, an axis node 170 may be coupled to radio nodes 172 and network nodes 174. In addition, the axis node 170 may be coupled to a radio group 176 and a network group 178. general, the group radio 176 comprises a collaboration of related radio nodes and a network group 178 comprises a collection of related network nodes.

As indicated above, in the design of a work flow running on multiple nodes within a radio group 176 or a network group 178, the problem arises from designing for the separate nodes within the group. It is a disadvantage for a designer to be forced to design workflow activity specific to the node. This can be time consuming and inflexible. It is better to provide a designer with a capability to set parameters on the node group and to treat the nodes more generally with respect to the common characteristics. The construction of HETEROCASTING workflow definition technique described above provides a solution to this problem and allows the pon parameters on a node group.

According to the present invention, an example workflow provides another solution for the parameters on the nodes if it can be used in the design and deployment of workflow for business collaboration. Exemplary workflow allows a designer to design a workflow as if the workflow is crossing over a single node (the exemplary node) in a node group. At the time of the run or of the deployment, the real nodes in the nod group can then be replaced by the example node when the workflow is instanced, deployed and executed.

An embodiment of the use of an example workflow in the design and deployment of workflow is shown in Figure 11B. An example workflow design, indicated generally with the number 180 may include a first activity 182 to be executed on a specified axis node. Then, the workflow design 18 includes an activity 184 to be executed on nodes within a radio group. In workflow design 180, activity 184 is designed using an exemplary workflow that represents the execution of activity 184 over an example node. The exemplary node generically represents dent nodes of the radio group. The workflow design 180 also includes an activity 186 which is to be executed on a radio node. As an example, activity 184 appears in workflow design 180 to be associated with a non-unique. However, activity 184 is parameterized on nodes in the radio group and may be deployed and executed with respect to two or more nodes within the group of nodes. This provides a workflow designer with significant flexibility in the design modification of the workflows that distribute similar activities through the related nodes.

As shown in FIG. 11B, a workflow display 188 generated from workflow design 18 has activities that match the activities in workflow design 180. In workflow deployment 183 an activity is displayed. for the hub node based on the activity 180 stopped in the workflow design 180. A plurality of activities 192 are displayed for the radio nodes (1 to N) in the radio group based on the exemplary workflow activity 184. When each activity is created and displayed 192 it is made specific for its associated node. And additional workflow deployment also includes an activity 194 displayed for the axis node based on the activity 186 in the workflow design 180.

In this way, the workflow design can represent nodes in a radio / network group as a non-unique (exemplary node) and still treat the example node as more a node during the deployment and execution of the workflow. , during the design phase, exemplary workflows can be designed by assigning activity to the example node. During the instantiation if deployed, the activities assigned to the exemplary node are duplicated to the appropriate nodes in the node group. Different parameters are selected at a running time based on the appropriate radio node that is instantiated. This allows a designer to generate a generic or general workflow more easily than being applied to numerous nodes within a node group.

The exemplary workflow is advantageous for allowing simplicity during the design phase and multiple deployment during run time for members of the node group. For example, when returning to Figure 11B, the node d axis can be associated with the retailer exit, and the radio nodes in the radio group can be associated with the suppliers for the exit of retailers. In the creation of a workflow design 180, the designer may desire and execute the same or a similar activity in each of the provider nodes. The sample workflow 184 allows the designer to represent this activity as an activity to be executed on a single example node. Therefore, the workflow design 180 is greatly simplified.

A third important feature is e support for workflows based on distribution. Workflows based on the distribution allow these workflows to be used specifically for generic distributions. This capacity allows the creation of generic or tempered workflows that can be instantiated in various scenarios. For example, the types of roles or distribution can be : role of partners, roles of axes; radio group papers; network papers; network group papers; user roles. As an example of the roles or distributions, the roles of partners 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 supplier 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 instance runs.

An additional important feature is the integration of automated workflows with user-oriented work flows. Workflows can often be described as having two varieties: • automated system-to-system workflows, and • user interconnection workflows. Even when h workflows are fully automated, and h workflows that are fully user-driven, most workflows have automated interconnection elements as well as user interconnection. The present global collaboration of administrator and designer n requires the Make 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.

Integration with the outside world Figure 12 is a diagram of an integration of the integration of a workflow with the outside world. As described in the previous section, inter and intra-enterprise work flows can be closed. These workflows can be composed of activities inserted together in various configurations. There is no restriction on what different workflow activities can do, but one of the main tasks of these activities is to integrate with the outside world. Figure 12 shows how a workflow can be integrated with the outside world using a component-based approach to integration. The components may include accessories 80, transformations 82, transfer 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 structuring the integration. There may be types of components: primitive components and compound components. Primitive components can include accessory 80, the transformers 82 and the transfer objects 84 The composite components include the adapters and the fluxes 86. The composite components are constructed in terms of primitive components. In this scheme, the accessories 80 are used to access an external source such as an SC (SUPPLY CHAIN PLANNER), an SAP, a relative data base, network servers, E-mail, message buses etc. The accessories 80 can be used to read, write or listen to the sources and destinations of the data. Transformers 82 can be used to transform data one way to another form. Transfer objects 84 s objects that can be passed from one activity to another activity from company to company. The transfer objects 84 can optionally be converted to EDI, XML, CORB, etc. structures. The accessories 80 and the transformers 82 can be inserted together to form flows. A complete flow can be executed in a single activity as shown in Figure 13.

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

Fig. 14 is a diagram of an incorporation of a data stream divided by multiple activities 104 and 106. As shown, the flow of Fig. 14 differs from that of Fig. 13 in the sense that the transformer components 96 and 98 are within separate activities 10 and 106 and communicate through a transfer object. The data flows of multiple companies can be based on the model of Figure 14 rather than on that of Figure 13.

With respect to the transformations, in u incorporation, two types of fundamental transformation can be supported: transformations based on I2-CDM direct transformations. Transformations based on 12C are based on the common data model of technology 12 (CDM). The common data model is an abstract scheme that is available in both rational and object forms.

Figure 15 is a block diagram of an incorporation of a transformation model based on 12 -CDM. As shown, the transformers and accessors can be coupled to transform application data into a common data model data object. and vice versa. For example a SUPPLY CHAIN PLANER (SCP) object can be created by a supply chain glider accessor from the supply chain glider data 114. The supply chain glider object 112 can then be transformed by a transformer chain glider d supply-data model common in a common data model object 110. Analogously, an SAP object 116 can be created by an SAP accessor from SAP data 118. The SAP object 11 can then be transformed using a planned SAP supply chain transformer in a common data model object 110. The SAP accessor and the transformer, as with other accessors and transformers can be combined into an SAP adapter-standard common data model 120 that can be used for Transformations based on common data model of other components. As another example, a BAAN object 122 can be created by a BAAN accessor of the BAAN data 124. An object BA 122 can then be transformed into a CDM object 110 by means of a BAAN-CDM transformer. These transformers work in another direction too.

Figure 16 is a diagram of an incorporation 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 Figure 16, the Supply Chain Glider (SCP) data 130 can be accessed by a supply chain glider accessor to create a supply chain glider object 132. The object of the supply chain glider The supply chain 132 can then be directly transformed into an object FACTORY PLANER (FP) 134. The factory glider object 134 can then be converted into the factory planned data 136 through a factory glider accessor This data stream can operate in the different direction too.

In these processes, there are several levels of granul to which access and transformation can take place including levels of relationship (table) generic object (graphic tree, matrix, etc.) and specific object (plan materials account, etc.) . Sometimes access can only be available at one level (say table) but the transformation may be more appropriate to another level (say generic object). For example, the hierarchical aggregate (a form of transformation) and frequently appropriate on a tree object. However, the data can only be accessed in tabular form. In this case, for example, the data must be accessed at the tabular level, they must be transformed into a tree and then have a hierarchical aggregate applied to them.

Figure 17 is a diagram of an incorporation of different levels of transformation and access. As shown, access and transformation can have three levels. A first level 140 can involve a table access transformations. A second level 142 may involve transformations and generic object access (tree, graph, etc.) and a third level may involve specific object access transformations (material accumulation, plan, etc.). In addition to the transformations between the application formats, there may also be transformations between the tre 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 administrator can support four different kinds of society relationships: axis to network, radius axis, axis to axis and a-VAN-EDI axis. Of these four, the network axis has all the features of deploying traditional network applications. The a-VAN-EDI axis can be deployed to the extent that it levels an existing VAN EDI infrastructure. Even though the relationship from 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 e-a-radio solution can provide maximum deployment in the system system collaboration environment. In the axis-to-radio field, the radio engine and analogous to the network explorer, and the radio part of the collaboration is analogous to the network page or applet. In a form similar to a network page or applet, the radio part of the collaboration can be designed and deployed centrally to the remote network engines. Unlike an applet network page, there may still be integration that requires doing remotely. This remote integration may be inevitable but it can be circumscribed and defined precisely by the radio part of the collaboration.

Another aspect of the deployment is the version management. The collaborations once designed and deployed are feasible to require changes (in different ways) to pass the time. It may be important that the subsequent versions of the collaborations are easily deployable as initial versions. The present global collaboration administrator can provide full support for the versions and centralized redeployment 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 phased amicably while another version is being phased.

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 relation of axis to radio on existing network protocols. The support of axis to radio on existing network protocols can be important for rapid deployment since a reconfiguration modification of an existing network infrastructure is not required. The large time savings in this regard can come from having to carefully modify the firewall and the security infrastructures that may already be in place.

Support from Many to Many Collaborations The present radio architecture a ej provides easy management and development. However, in practice companies collaborate with many companies which in turn collaborate with other companies. Therefore, companies often form a graph or collaborative network. This can be supported through the ability to replace an engine of eg by a radio engine at any time. This substitution capacity allows collaborative networks of many many to be grown organically rather than all at once.

Figure 18 is a diagram of an embodiment of replacing a network engine with a radio engine within a collaboration. As shown, a company (El) can deploy a 150-axis motor on itself and a radio engine 152 on all partner sites. In particular, a radio engine 15 can be a partner site (E2). If the partner site (E2) wishes to design and control its own collaboration, it can replace the radio engine 154 with an axis motor 156. From the perspective of the company 1, the company 2 can still be a radio in the collaboration of the company 1. However, this radio now runs on a shaft motor 156 which can control its own collaborations with rad motors 158. In addition, radio engines 160 and 162 can be associated with a third entity (E3 ) which interacts with the shaft motor 150 and the shaft motor 156 in the name of the company E3.

Extension of the Work Frame An important aspect of the present work framework is its extension. Without extension, the locking frame may not be able to handle new situations and challenges. There may be several different dimensions for it's extension. For example, a primary extension area is in the area of semantic object rules. If the supported standards are not sufficient for a particular problem then the working framework can be increased 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. Standard component library can be extended both generally and by the end users.

Although the present invention has described 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 (7)

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

1 . A process implemented by computer for the collaboration of multiple companies, which includes: allowing a workflow design to include at least one example workflow, the example workflow associated with an exemplary node allows for at least one activity to be parameterized on a plurality of nodes within a group of nodes; in instances the workflow so that at least one exemplary workflow is instantiated as a plurality of activities each associated with a specific node in the group of nodes; deploy the workflow by distributing the activities over the nodes in the nodc group to provide a multi-enterprise collaboration.

2. The process implemented by computer as claimed in clause 1, further characterized in that it comprises executing the workflow.

3. The process implemented by computer as claimed in clause 1, characterized in that node group is a group of radio nodes.

. The process implemented by computer as claimed in clause 1, characterized in that group of nodes is a group of network nodes.

5. An example workflow, which includes an exemplary node with a parameter on a plurality of nodes within a group of nodes; Y an activity that is going to be executed by the exemplary one; where the activity can be set and instances as a plurality of activities each associated with a specific node in the group of nodes when the example workflow is deployed.

6. The exemplary workflow as claimed in clause 5, characterized in that the group d node is a group of radio nodes.

7. The exemplary workflow as claimed in clause 6, characterized in that the group d node is a group of network nodes. IS IN An exemplary workflow is described for use in the design and deployment of a workflow for multiple enterprise collaborations. The process implemented by computer involves allowing a workflow design to include at least one exemplary workflow. Exemplary workflow is associated with an exemplary node that allows at least one activity to be parameterized on a plurality of nodes within a group of nodes. The process then involves putting instances into the workflow so that at least one exemplary workflow is put into instances as a plurality of activities each associated with a specific node in the group of nodes. The workflow is deployed by distributing the activities on the nodes in the group of nodes to provide a multi-company collaboration.