Embodiments of the invention relate generally to computer applications, and more specifically, to a system for automating the integration of the distributed computer applications.
The traditional deployment of enterprise applications or applications in similar distributed computing environments is characterized by the implementation and use of separate application programs among different users or teams in the overall organization. For example, in a manufacturing organization, one team may use a CAD/CAM program to design and manage the production of a product, while other teams may use finance programs, inventory management programs, customer relationship management (CRM) programs, and so on to manage their respective aspects of the project. Typically, each application is treated as a separate program with its own set of users, input/output data, business rules, timelines, process flows, and so on. Throughout the entire project lifecycle (referred to as the “checkpoint flow”), business content, in the form of documents; files, databases, contacts and the like is continually created and modified by the people and the processes within the system. However, it is usually the case that a common set of data or content is used by the different teams. The deployment of individual “silo applications” generally does not facilitate the sharing of common data and often results in little or no cross work team communications, as each user in each application is assigned a specific and unique role as well as sets of business rules and processes, and has little if any access or interaction with any other application or the business content of those applications. Because business content data and processes are usually managed by each individual application, little or no data synchronization or true sharing is typically possible. Normally the shared cross team business content information is controlled and managed by different groups of users and groups of silo applications. Thus, when a cross team member needs to synchronize the content or project status, he or she must often dump the shared business content to a flat file/spreadsheet from the application and email or fax it to the team members and partners in order to share this content. This manual and mesh-based communication method is error-prone, lacks integrity, virtually unmanageable, time consuming, and potentially very costly in the context of complicated enterprise projects.
The management of content, user communication, process interactions, and application rules is especially problematic in current deployed enterprise systems that involve several different teams all running disparate applications, yet require some degree of interactivity and efficient collaborations. This is largely due to the fact that content is usually stored in flat file structures and each team has its own application platform, deployment infrastructure and defined business processes and user roles. As mentioned above, user interaction in this case often requires individual transmission of business content and manual transmission modes, such as fax/phone/e-mail outside of each user's application platform without management of any overall project level integrity, and is thus an inefficient, insecure, and costly method of communication that results in a lack of synchronization, automation and unmanaged network of communications. Although enterprises can choose to implement the point-to-point integration of applications or users, such integration links typically result in a complicated mesh scheme where every application or user is connected to or integrated with every other application or user. Moreover, the lack of an efficient way to manage distributed project processes, such networks often contain a large number of conflict integration rules and business processes, resulting error-prone business interactions and poor business content integrity.
Embodiments of the present invention are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
Embodiments are directed to an application integration and collaboration platform process that facilitates the on-demand integration of business applications implemented on a distributed network platform. The entire business process for the involved applications and users within the system is defined as a project or process checkpoint flow. Each checkpoint represents a content modification or process routing step that involves one or more users and/or applications. The content data is modeled as content objects based on object metadata definitions, and the users or applications that use the content are defined by the rich object field matrix. The checkpoint flow, content data definitions and rich object field matrix definitions are combined to create database structures that store the business content data as multi-dimensional objects. In this manner, the content data and database structures incorporate dynamic rules representing the workflow process and the user and application information. Several components associated with the application integration process, such as versioning, logging, locking and business rule engines facilitate the protection of data integrity, and storage of history information associated with the business content as it is processed by the enterprise applications. This linkage model facilitates automated processes that help integrate different enterprise applications of the project, as well as graphical user interface elements that provide comprehensive control over the process steps and user interaction. The shared business content that is used by the separate enterprise applications and manipulated through multiple checkpoint and interactive processes involving different users and applications at different stages is managed as shared content objects under an integrated application platform. The integration of checkpoint processes, user and application information, and business content definitions also facilitates the creation of collaboration hubs among users who may be involved in different tasks associated with the project, or even in a variety of different enterprise applications that may share some common aspects such as data or users.
Embodiments of a system for providing a collaboration platform that integrates a number of different applications and work teams in a distributed enterprise environment are described. In the following description, numerous specific details are introduced to provide a thorough understanding of, and enabling description for, embodiments of the application integration process. One skilled in the relevant art, however, will recognize that these embodiments can be practiced without one or more of the specific details, or with other components, systems, and so on. In other instances, well-known structures or operations are not shown, or are not described in detail, to avoid obscuring aspects of the disclosed embodiments.
Aspects of the one or more embodiments described herein may be implemented on one or more computers executing software instructions. The computers may be networked in a client-server arrangement or similar distributed computer network.
In one embodiment, the server computer 104 includes an optional World-Wide Web (WWW) server 116 or server clustering environment that stores data in the form of web pages and transmits these pages as Hypertext Markup Language (HTML) files over the Internet 110 to the client computers. For this embodiment, the client computers typically run a web browser program, such as 114 to access the web pages served by server computer 116 and any available content provider or supplemental server 113.
The network client computers are configured to run a business application program, or to run as or as a dummy client which only has a web browser application available. As shown in
Another class of client computers is represented by mobile client 118. Mobile client 118 can be a mobile computing or communication device, such as a notebook computer, personal digital assistant (PDA), mobile phone, game console, or any similar class of mobile computing device with sufficient processing and communication capability. The mobile client 118 generally does not execute server like business applications, but may access the server computers over the network 110. For example, the mobile client may be operated by a user who has temporary access to resources on the server computers through Internet or similar network access.
In one embodiment, server 104 in network system 100 is a server that executes a server side application integration process 112. The application integration process includes functional components that perform the tasks of integrating different application programs used in the project, providing a collaboration hub for the different teams of the project, and automating the business process definitions for the individual business applications. For the embodiment illustrated in
The programs within the application integration process 112 or integration engine block 212 may represent one or more executable programs modules that are stored within network server 104 and executed locally within the server. Alternatively, process 112 may be stored on a remote storage or processing device coupled to server 104 or network 110 and accessed by server 104 to be locally executed. In a further alternative embodiment, the application integration process 112 may be implemented in a plurality of different program modules, each of which may be executed by two or more distributed server computers coupled to each other, or to network 110 separately.
For an embodiment in which network 110 is the Internet, network server 104 executes an optional web server process 116 to provide HTML objects, typically in the form of web pages, to client computers coupled to the network. To access the HTML files provided by server 104, client computer 102 executes a web browser process 114 that accesses web pages available on server 104 and resources, such as supplemental server 113. The client computers may access the Internet 110 through an Internet Service Provider (ISP). Content for any of the applications contained within or associated with a business application used by the client computer 102 may be provided by a data store 120 closely or loosely coupled to any of the server 104 and/or each client computer. In one embodiment, only the business content data or references to the content that is commonly shared among the applications and end users are stored at content store 120. In addition, each application may have its own database storage at the client side, and some of this data might not be of interest to other applications and users. A separate content provider 113 may provide some of the data that is included in any business application generated, transmitted, or executed over system 100. Although data store 120 is shown coupled to the network server 104, it should be noted that content data may be stored in one or more data stores coupled to any of the computers of the network, such as network client 102 or to devices within the network 110 itself.
In one embodiment, the users of each client computer 102 and 103 execute one or more business applications 105 and 107 that may be used as part of an overall business or project. For purposes of the following discussion the terms “overall business” or “project” refer to an endeavor that involves a number of different users operating a number of different computers that may execute different business application programs, and the terms “business application,” “application program,” and “enterprise application” all refer to an application program 105 or 107 that is executed on the client computer. In general, a business application is a computer program that may itself involve a number of different users, each of whom may be involved in one or more particular aspects of a business process. The business application, also referred to as an “enterprise application” involves the execution of a number of different task or processes involving the users. The business application typically also involves the creation, modification, storage and use of a number of different business content data used by the application. The overall project may involve the use of several different applications operated by different teams who perform different tasks and contribute to separate aspects of the project.
The overall business project implemented by system 100 typically embodies many different users, processes and content objects interacting with one another over a distributed computer network.
The applications illustrated in
Business content generally refers to any content that is created, modified, or otherwise used by the applications comprising the overall project. It should be noted that the term “content” can refer to any real or virtual collection of business data, objects or information used by the system. Such business content may be organized as files, documents, databases, pages, lists, or similar objects, and could include many different types of data, such as text, graphics, sound, video, and the like. For a typical project, a large number of different types of business content can be created and processed by the system. Each content object may be used by different users and applications within the project. For a complex project involving many users, applications and content objects, strict maintenance of content and process integrity is necessary to ensure that the overall project is performed properly.
In general, a project designer or administrator of a particular cross-team business defines the overall business flow and the people and business content involved in the project. The checkpoint flow usually involves a number of sub-processes and a number of different states. Different people may be involved in different states, this is also generally true for the applications within the project. The business content involved in a cross-team project will typically be managed by multiple user teams or applications, therefore stage and process management is important to maintain the integrity of the content.
Once stored in the collaboration hub platform 191, the content can be considered to be represented by a three-dimensional parameter model. The content for each application contains a regular object description (first dimension), a rich object field matrix (second dimension), and a distributed checkpoint model to manage the content being accessed and controlled by the multiple teams over a time period. The rich object field matrix links the content to the application or applications that use it. Thus, in general, the content is selected and abstracted from the original (silo) application, and stored in the collaboration hub with the three dimensions of descriptive parameters. The data is then leveraged by the program components of application integration process to establish the linkages within the overall project. In general, the collaboration hub stores the information related to the content, process, and users for each application of the project, and the application integration process integrates this information to derive the necessary linkages to create a virtually seamless unified enterprise system from the separate business applications.
In one embodiment, the application integration process 112 includes a number of different programs (also referred to as “engines”) to define and automate the user's business application, as well as provide a platform execute the application during runtime in a manner that integrates the users, processes, and content of the other applications in the project.
Business Content Engine
The business content engine 202 is a programming module that imports, stores and conditions the business content of the user application for runtime execution by the application integration process. It prepares the hooks that provides the content linkage from the different applications, and hands over the rich content data structures to the other engines of the integration engines 212. In general, each separate application, such as 105 and 107 in
The metadata is created within the business content engine based on definitions provided by the user. In one embodiment, the user can explicitly input, through tools such as the user interface component 210 or through the automatic programming interfaces to import critical content from the applications. The business content engine also includes a parser that can automatically derive the metadata from the raw content imported. The parser is configured to recognize the data type and then automatically define the metadata for the business content. Once the metadata is defined, the business content is imported into the application integration process, step 304. This business content comprises the shared business content that is used by one or more different user teams and/or applications within the overall project. Step 304 may be a substep of 302, or it may be a separate step, as shown. In general, the content creation programs used by the user application store data in a “flat” structure, the data is defined in relation to metadata, and stored in a one-dimensional structure. In one embodiment, the shared content is defined and abstracted from each application. The process then builds the rich object field matrix and provides elements such as application location, user profile and other parameter information. The checkpoint flow then adds an additional dimension based on the application processes.
Once the shared business content is defined within the system and/or imported into the application integration process, it is tagged with markers (or “hooks”), step 306. In one embodiment, the hooks include various version and source identifiers that facilitate dynamic process trigger points used by the other processing engines of application integration engines 212 during project definition and runtime execution.
Different applications can impact the same set or type of data constituting the shared content, even though this content may be treated differently by each application. For example, with reference to
Business User Engine
With reference to
Users and/or applications may be associated with different business content created and defined by the system. Each element of business content defined for the multiple applications and the users of that content comprise a “hub” (such as the collaboration hub 191 illustrated in
Business Process Engine
The business process engine 206 controls the series of critical checkpoints of business content within the application integration process 112. The application integration aspect of this process uses the concept of “checkpoints” to mark significant milestones or transition points during the checkpoint flow of the business content. The business process engine 206 is a content sensitive module that provides dynamic checkpoint control over any item or unit of business content. As business content is processed by the system, it undergoes modification or validation through the use of checkpoints defined by the business process engine. This engine defines and maintains one or more checkpoints at which the business content undergoes a transition or modification. The transition or modification can be effected by one or more users of the system and/or one or more applications of the system. The transition or modification at each checkpoint can be an act that modifies the business content in some way, validates the content, routes the content within the system, or any other processing step or combination of processing steps that impacts the business content.
In one embodiment, each checkpoint includes a gate or phase control point, a user hook, a content hook, and a transit locking mechanism. The business process engine is configured to learn or define the checkpoints of the business content, and create the metadata space for the business content phase hook for each of the checkpoints. The checkpoints can also include any business rule that triggers the automation of the business processes. In general, a business rule is a rule that modifies, validates, routes or otherwise processes the business content depending upon one or more variables or conditions. Rules are translated into event rules and locking rules and passed on to both an event engine and locking engine within the application integration process. These rules are also converted into passive read-only and interactive read/write action event components for involved silo applications, and interactive read/write graphical components for display to the end users.
The checkpoint flow of the process essentially comprises the timeline of the application and comprises transition points that result in content change by a user and/or application. The checkpoint flow of a content object can include one or more sub-checkpoint or even sub-bus-checkpoint flows recursively. Each sub checkpoint node (leaf node) can consist of interactive processes and business rules.
In one embodiment, each checkpoint 606 includes a gate or phase control point, a user hook, a content hook, and a transit locking mechanism. The business process engine 604 is configured to learn or define the checkpoints 606 of the business content 602, and create the metadata space for the business content phase hook for each of the checkpoints. The checkpoints can also include any business rules that may be defined by a group of users. In general, a business rule is a rule that modifies, validates, routes or otherwise processes the business content depending upon one or more variables or conditions. The business process engine 604 learns the business rules, which define which user can do what act and when, and generates the dynamic and interactive graphical user components of the business content and business process for users and the action events for applications to access and modify the business content. Rules are translated into event rules and locking rules and passed on to both an event engine and locking engine within the application integration engines 212. As the business content traverses over a checkpoint (represented in
In one embodiment, the process represented by checkpoint flow 610 in
Each checkpoint of the process may trigger an interactive process, such as an approval requirement of the business content by a user. The approval chain defines the hierarchies of the users and validates the approval of the business content to allow the process to progress to a successive checkpoint. Other types of interactive processes, such as notifications, actions, alarms, exception processes, and so on will implicate other applications and/or users, or the business rules of the process.
In one embodiment, when the checkpoint flow for a content object is started, as shown in step 802, the following programs of the application integration process are triggered. First, an instance of the collaboration process is generated. This is a process line which is represented as a linked list of the check points. A collaboration project is created as well which will be used to track the users and applications involved in the checkpoint flow of the content. As the process transitions from one phase of the project to a successive phase as designed in process engine, various processes are triggered. At the start point of each transition, a check point will be automatically added into the process line, the lock engine will lock the content object in the transition period if any sub-checkpoint or interactive process is defined, and a main node of the collaboration log will be created and attached to the project created at the process starting point and also to the content object.
At the end of the transition, the lock engine unlocks the content object and releases it to other users or applications. A new version of the content object is generated and marked with the phase. The main node will then be marked with the new version of the content object. As stated above, depending upon the application and its implementation, the main checkpoint flow can have one or more sub-checkpoints. Each sub-checkpoint flow can plug recursively into a checkpoint of the process, and interactive process chains can be plugged into any leaf node checkpoint. When the content reaches the end of the checkpoint flow, the project created will be marked as closed.
In general, the checkpoint flow of a project is defined as a series of transitions between checkpoints, sub-checkpoints and interactive processes.
For the example shown in
The process flow can also be represented as a tree structure consisting of the checkpoint and approval steps as nodes.
The collaboration hub defined by the application integration process that ties together the different teams can manage multi-layer approvals and process control. The checkpoints can thus be distributed to different teams, as can the derived interactive process chains. This creates a true collaborative platform for on-demand application integration.
In an embodiment of the application integration process, there are four objects involved in the business process engine, which are as follows: the process definition, the process instance, the content instance, and the collaboration log instance. The process definition is a checkpoint flow process represented as a tree structure of flows. The process instance is a tree structure representation of the process spread from the process definition. The tree structure levels are the mirror of the process definition. The number of state node instances in each level is programmatically defined by the real time movement of the process. The content instance is a flat list of versions of each content object. Each version is stamped with one of the process node identifiers. It is presented as a mirror of the tree structure of process instance, but trimmed off the interactive process chain nodes. The collaboration log instance starts with project, and is the mirror of the tree structure of the process instance. The collaboration log instance logs all of the activities along the process instance from both the checkpoint flow and the derived interactive process chain and approval chain processes.
As stated above, a collaboration log instance is created for each process instance.
As the process transitions from the checkpoint and sub-checkpoint transitions, the content may be modified. As stated above, the content instance is a flat list of versions of each content object.
It should be noted that the processes and various representation of the processes, logs, and content illustrated in all of
Additional Engines
In one embodiment, the application integration engine block 212 includes other processing components or engines to facilitate the automation and/or runtime integration of the business users and applications. A locking engine locks the content either at a checkpoint or in between checkpoints so that its integrity can be maintained. Different levels of locking can be defined. In one embodiment, the locking engine may be configured to overrule the access privileges defined for the users and applications. The locking engine can also be configured to control whether the process continues along the defined workflow. In this manner, a process may be halted at a particular checkpoint or sub-checkpoint regardless of whether business rules allows the process to continue. This facilitates the integration of fault recovery and alarm conditions with the entire project cycle.
In one embodiment, a business rule engine is incorporated within the application integration engines 212. Business rules may be applied to any or all checkpoints and sub-checkpoints within the checkpoint flow of a process. A business rule typically comprises a set of conditions. If the conditions are met, processing rules are invoked that may perform the combination of actions such as modifying the content, routing the process, sending an alert, terminating, or invoking an involved application process. The business rule engine monitors the condition of the checkpoint flow and causes execution of the business rule at a particular checkpoint if the condition is met during transition of the workflow through that checkpoint.
In one embodiment, the application integration process may be provided as a service that can be used by all involved cross teams without the need for the user to install or maintain any software and hardware on the user's computer or network. The application integration process is scalable so that the user can define any scope of the business project desired, from a single project to an entire integration system involving many distributed applications integration and data synchronizations.
Embodiments of the application integration system described herein may be applied to various types of computer applications, software applications, communications software such as mail, message or content delivery methods utilizing communication over the Internet or similar distributed network.
Aspects of the application integration system described herein may be implemented as functionality programmed into any of a variety of circuitry, including programmable logic devices (“PLDs”), such as field programmable gate arrays (“FPGAs”), programmable array logic (“PAL”) devices, electrically programmable logic and memory devices and standard cell-based devices, as well as application specific integrated circuits. Some other possibilities for implementing aspects of the application integration method include: microcontrollers with memory (such as EEPROM), embedded microprocessors, firmware, software, etc. Furthermore, aspects of the described method may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. The underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor (“MOSFET”) technologies like complementary metal-oxide semiconductor (“CMOS”), bipolar technologies like emitter-coupled logic (“ECL”), polymer technologies (e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital, and so on.
It should also be noted that the various functions disclosed herein may be described using any number of combinations of hardware, firmware, and/or as data and/or instructions embodied in various machine-readable or computer-readable media, in terms of their behavioral, register transfer, logic component, and/or other characteristics. Computer-readable media in which such formatted data and/or instructions may be embodied include, but are not limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) and carrier waves that may be used to transfer such formatted data and/or instructions through wireless, optical, or wired signaling media or any combination thereof. Examples of transfers of such formatted data and/or instructions by carrier waves include, but are not limited to, transfers (uploads, downloads, e-mail, etc.) over the Internet and/or other computer networks via one or more data transfer protocols (e.g., HTTP, FTP, SMTP, and so on).
Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” “above,” “below,” and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word “or” is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.
The above description of illustrated embodiments of the application integration system is not intended to be exhaustive or to limit the embodiments to the precise form or instructions disclosed. While specific embodiments of, and examples for, the system are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the described embodiments, as those skilled in the relevant art will recognize.
The elements and acts of the various embodiments described above can be combined to provide further embodiments. These and other changes can be made to the application integration system in light of the above detailed description.
In general, in any following claims, the terms used should not be construed to limit the described system to the specific embodiments disclosed in the specification and the claims, but should be construed to include all operations or processes that operate under the claims. Accordingly, the described system is not limited by the disclosure, but instead the scope of the recited method is to be determined entirely by the claims.
While certain aspects of the application integration system are presented below in certain claim forms, the inventor contemplates the various aspects of the methodology in any number of claim forms. For example, while only one aspect of the system is recited as embodied in machine-readable medium, other aspects may likewise be embodied in machine-readable medium. Accordingly, the inventor reserves the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the described systems and methods.
The current application is related to U.S. patent application entitled “Collaboration Hub System for Accessing and Managing Shared Business Content” filed on Apr. 25, 2006, and U.S. patent application entitled “Content Driven Process Routing for Integrated Enterprise Applications” filed on Apr. 25, 2006.