Patent Application
20070124185
Any enterprise executes a number of business processes whether explicitly or implicitly defined. A business process consists of business activities and the transitions between them. For example, a retail store may have business processes “Process Customer Order”, “Get Inventory from Suppliers”, “Process Monthly Payroll” and so on. The process “Process Customer Order” may include the activities “Display Catalog”, “Review Shopping Cart”, “Submit Order”, “Account Verification”, “Inventory Check”, “Ship Order”, etc.
In many cases the individual activities or groups of activities are implemented as separate computer systems or applications. The applications interact with each other through the variety of interfaces, for example, event brokers, Web Services and API calls.
Any process may have a number of process instances. For example, “Process Customer Order” will have a separate instance for every customer order being processed at any given time. If the processing of an order from its receipt to its shipment takes several days or even weeks, the number of process instances can be very large.
All process instances have State. The state determines where the instance is in its execution. In most cases the state means the business activity that is currently under execution for the specific instance. For example, the current state of the “Process Customer Order” process instance for order #123456 is in “Order Shipping”. The process state may also include the values of some set of parameters, relevant for all elements of the process. For example, a process may have “Start Date/Time”, “Order Number”, and “Order Total Value” as parameters whose values should be a part of the process state.
Many applications require the knowledge of the current state for every instance of their business processes. Examples of these type of applications include Business Process Management, Business Activity Monitoring, Business Performance Management and Process Simulations. The traditional approach to state maintenance is:
The task of identifying a specific process instance from the large pool of instances has existed since computer systems were first implemented in enterprises. Traditionally, two approaches were used for this purpose.
In the first approach, a unique process identifier (PID) is created when the process starts. All activities of the process are expected to carry this PID. For example, an online retail store may use an Order Number; an airline may use a Ticket Confirmation Code. This is precisely why when a person calls customer service of the store or airline, an agent asks for some form of the PID.
This approach is mostly used by systems implemented end-to-end using Business Process Automation (BPA) technology. The PID is sent to every business activity in the process and expected to be received when the activity reports its results. This approach does not produce the results when some of the business activities do not accept or return the PID. This problem causes the PID approach to be unusable in a large number of cases.
The second approach uses some combination of data available to an activity in order to locate the process instance. If a person tells the customer service agent that he does not know the confirmation code, the agent asks for some other data: name, date of the flight, departure airport.
In a similar fashion, when BPA systems are implemented with some activities that do not support PID, developers have to select the data suitable for identifying the process instance manually. This manual task has been performed again and again since the massive adoption of BPA in early 2000. The same approach is also described in the patent application Ser. No. 10/898,464.
The fundamental problem with this approach is that it requires the manual definition of the identifiable data in every activity of every business process in the enterprise. Moreover, software developers must maintain these definitions as the enterprise changes its business processes and activities. Another problem with this approach is that some activities may not provide sufficient identifiable data which can result in the system identifying more than one process instance to which activity could belong.
The present invention provides a system and a method, implemented on a computer system, for maintaining the current state of the instances of business processes.
The implementations set forth in the following description do not represent all possible implementations for the claimed invention. Other implementations can be used and structural and procedural changes may be made without departing from the scope of the present invention.
The present invention uses the definitions of the business processes to create a reliable, cost efficient and easy to maintain computer system that manages the current states of all business process instances. Consistent with the embodiments of the invention, the process definitions can be obtained from a plurality of sources such as automatic discovery as described in the patent application Ser. No. 11/163867, through an import procedure from other systems or applications, or they may be created by the users.
Consistent with the embodiments of the invention, the definitions of the business processes include or can be translated into the declarations of the properties of the processes, business activities that constitute the processes, descriptions of the messages that the business activities send and receive; data relationships between the properties of the processes, properties of the activities and the data fields of the messages.
Consistent with the embodiments of the invention, the process definitions are stored in the computer readable form accessible by the State Engine.
Consistent with the embodiments of the invention, the system is implemented as a computer program and is executed on one or more computers connected via the computer network as shown on
The State Engine has access to the definitions of the business processes 160. In the embodiments of the invention, the definitions of the business processes may be stored as database records, XML files, computer executable code or other forms. Consistent with the embodiments of the invention, the storage mechanism for the business process definitions 160 could be 140 and 150 or independent from them.
The State Engine receives the messages 120 from a plurality of computer systems and applications 130, capable of reporting the completion or progress of the business activities. The systems and applications 130 may include packaged applications such as ERP (Enterprise Resource Planning), CRM (Customer Relationships Management), Inventory Management, Sales; application and web servers; EAI (Enterprise Application Integration) systems, BPA (Business Process Automation) systems, BMP (Business Process Management) systems, etc.
The messages 120 include structured data related to business activities completion or the progress of the business activities. The term “structured” means the data in the message consists of or can be accessed as data fields 125. Consistent with the embodiments of the invention, one or more of the data fields of the message may represent the sender of the message; the same or another field may represent the business activity that initiated the sending of the message. This latter field is commonly referred to as the “Message Type” or “Message Name”. For the purposes of this description, we will use the term Message Type hereafter.
In one embodiment of the invention, the State Engine utilizes the method consisting if the following steps, shown on
