Abstract:
The present disclosure provides methods and apparatuses for managing system events. Using the methods and apparatus herein, users can create events that are based on changes in a business process or a business system due to a business process activity. Users can create and manage events that evaluate and execute policies outside of the context of the business process workflow and policy management systems.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    The present application claim benefit to U.S. Patent Application No. 60/896,730, METHOD AND APPARATUS FOR DESIGNING WORK FLOWS, filed on Mar. 23, 2007; and U.S. Patent Application No. 60/939,279, METHODS AND APPARATUS FOR MANAGING WORKFLOW EVENTS, filed on May 21, 2007, the entire contents of which are incorporated herein by reference. 
     
    
     BACKGROUND 
       [0002]    A business process is a combination of operational steps or activities that a business undertakes. A business may conduct a high number of business processes throughout the course of a day or year, in order to accomplish the business&#39;s goals. An operational step or activity may be any action from the mundane to the complex. 
         [0003]    Through the use of technology, businesses can now model their business processes in a graphical nature. What used to be a loosely defined set of procedures can now be formalized into complex business process workflows. The formalized business processes allow managers to understand the bottlenecks of a process, and to redesign the business processes for efficiency. 
         [0004]    Business can now also incorporate business process design into their existing technology systems. Instead of providing a simple map of a business process, integration with computer systems allows business process designers to design interactive business processes that drive business workflow. Business process designers can receive data from various sources and perform a wide range of actions on the data directly, and create business processes in an easy to understand visual manner. 
         [0005]    Businesses create workflows as a part of business process design to assist in managing their internal operations. Business processes allow users to represent the current state of their business operations in a graphical manner. Users can also simulate new business operations through the use of business processes. 
         [0006]    Business processes have a defined workflow and new actions that have to be performed usually must be included in a redesigned business process. Redesigning the process every time a new function is to be performed may be time consuming. Additionally, a business process may perform an action that triggers a number of optional sub-actions, unrelated to the main business process. Reconfiguring the business process for each scenario or creating a large number of nearly identical business processes could be costly and time consuming as well. 
         [0007]    Some business process software allows certain data to be monitored, so that events may be triggered by changes in the data. However, those software systems require the event logic to be coded into the data source, such as directly into the database system. The hard coding of the event logic makes it difficult for a non-technical user to change the event logic or to understand what events are being monitored. Additionally, such systems require an external process to periodically poll the data source to look for changes that would trigger an event. The polling requires substantial processing time if the polling is done frequently, or an event may not be triggered quickly enough if the polling time is set to a longer time period. Also, the systems may require administrator level access to add or alter event logic, which adds to the difficulty for a standard business user to configure the system. 
       SUMMARY 
       [0008]    The present disclosure provides methods and apparatuses for managing system events. Using the methods and apparatus herein, users can create events that are based on changes in a business process or a business system due to a business process activity. Users can create and manage events that evaluate and execute policies outside of the context of the business process workflow and policy management systems. 
         [0009]    Additionally, using the methods and apparatus of the present disclosure, users can create events that are triggered as a result of periodic polling of the stored data. 
         [0010]    Additional features and advantages are described herein, and will be apparent from, the following Detailed Description and the figures. 
     
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         [0011]      FIG. 1  is a high level block diagram of an example system event system. 
           [0012]      FIG. 2  is a more detailed block diagram showing one example of a client device. 
           [0013]      FIG. 3  is a more detailed block diagram showing one example of a server. 
           [0014]      FIG. 4  is a screenshot of an example event management system. 
           [0015]      FIG. 5  is a screenshot of an example event selection screen. 
           [0016]      FIG. 6  is a screenshot of an example event data screen. 
           [0017]      FIG. 7  is a screenshot of an example add condition screen. 
           [0018]      FIG. 8  is a screenshot of an example add policy screen. 
           [0019]      FIG. 9  is a screenshot of a example data mapping screen. 
           [0020]      FIG. 10  is a screenshot of another example data mapping screen. 
           [0021]      FIG. 11  is a screenshot of an exception selection screen. 
       
    
    
     DETAILED DESCRIPTION 
       [0022]    The present system is most readily realized in a network communications system. A high level block diagram of an exemplary network communications system  100  is illustrated in  FIG. 1 . The illustrated system  100  includes one or more business process designer terminals  102 , one or more business process servers  104 , and one or more business process databases  106 . Each of these devices may communicate with each other via a connection to one or more communications channels  108  such as the Internet or some other data network, including, but not limited to, any suitable wide area network or local area network. It will be appreciated that any of the devices described herein may be directly connected to each other instead of over a network. 
         [0023]    The business process server  104  stores a plurality of files, programs, and/or web pages in one or more business process databases  106  for use by the business process designer terminals  102 . The business process database  106  may be connected directly to the business process server  104  or via one or more network connections. The business process database  106  preferably stores business process data. 
         [0024]    One business process server  104  may interact with a large number of business process designer terminals  102 . Additionally, the business process server  104  may be a plurality of business process servers. Accordingly, each business process server  104  is typically a high end computer with a large storage capacity, one or more fast microprocessors, and one or more high speed network connections. Conversely, relative to a typical business process server  104 , each business process designer terminal  102  typically includes less storage capacity, a single microprocessor, and a single network connection. 
         [0025]    A more detailed block diagram of a business process designer terminal  102  is illustrated in  FIG. 2 . The business process designer terminal  102  may include a personal computer (PC), a personal digital assistant (PDA), an Internet appliance, a cellular telephone, or any other suitable communication device. The business process designer terminal  102  preferably includes a main unit  202  which preferably includes one or more processors  204  electrically coupled by an address/data bus  206  to one or more memory devices  208 , other computer circuitry  210 , and one or more interface circuits  212 . The processor  204  may be any suitable processor, such as a microprocessor from the INTEL PENTIUM® family of microprocessors. The memory  208  preferably includes volatile memory and non-volatile memory. Preferably, the memory  208  stores a software program that interacts with one or more of the other devices in the system  100  as described below. This program may be executed by the processor  204  in any suitable manner. The memory  208  may also store digital data indicative of documents, files, programs, web pages, etc. retrieved from one or more of the other devices in the system  100  and/or loaded via an input device  214 . 
         [0026]    The interface circuit  212  may be implemented using any suitable interface standard, such as an Ethernet interface and/or a Universal Serial Bus (USB) interface. One or more input devices  214  may be connected to the interface circuit  212  for entering data and commands into the main unit  202 . For example, the input device  214  may be a keyboard, mouse, touch screen, track pad, track ball, isopoint, and/or a voice recognition system. 
         [0027]    One or more displays, printers, speakers, and/or other output devices  216  may also be connected to the main unit  202  via the interface circuit  212 . The display  216  may be a cathode ray tube (CRTs), liquid crystal displays (LCDs), or any other type of display. The display  216  generates visual displays of data generated during operation of the business process designer terminal  102 . For example, the display  216  may be used to display web pages received from the business process server  104 . The visual displays may include prompts for human input, run time statistics, calculated values, data, etc. 
         [0028]    One or more storage devices  218  may also be connected to the main unit  202  via the interface circuit  212 . For example, a hard drive, CD drive, DVD drive, and/or other storage devices may be connected to the main unit  202 . The storage devices  218  may store any type of data used by the business process designer terminal  102 . 
         [0029]    The business process designer terminal  102  may also exchange data with other network devices  220  via a connection to the network  112 . The network connection may be any type of network connection, such as an Ethernet connection, digital subscriber line (DSL), telephone line, coaxial cable, etc. Users of a business process designer terminal  102  may be required to register with the business process server  104 . In such an instance, each user of a business process designer terminal  102 , may choose a user identifier (e.g., e-mail address) and a password which may be required for the activation of services. The user identifier and password may be passed across the network  108  using encryption built into the business process designer terminal  102  browser. Alternatively, the user identifier and/or password may be assigned by the business process server  104 . 
         [0030]    A more detailed block diagram of a business process server  104  is illustrated in  FIG. 3 . Like the business process designer terminal  102 , the main unit  302  in the business process server  104  preferably includes one or more processors  304  electrically coupled by an address/data bus  306  to a memory device  308  and a network interface circuit  310 . The network interface circuit  310  may be implemented using any suitable data transceiver, such as an Ethernet transceiver. The processor  304  may be any type of suitable processor, and the memory device  308  preferably includes volatile memory and non-volatile memory. Preferably, the memory device  308  stores a software program that implements all or part of the method described below. 
         [0031]    In particular, the memory  308  preferably stores an event bus  312  and a messaging queue  314 . The event bus will be discussed in further detail in relation to  FIG. 4 . The messaging queue  314  will also be discussed in further detail in relation to  FIG. 4 . 
         [0032]    A screenshot of an example event management system  400  is presented in  FIG. 4 . Although the example event management system  400  is described in reference  FIG. 4 , it will be appreciated that many other configurations are possible. For example, elements could be in different locations, elements could have different names, and elements could have different graphical representations. 
         [0033]    The example event management system  400  may have a number of sources for the event to be triggered from. For example, the event management system  400  may have events created from workflow events  402 , SmartObjects events  404 , custom events  406  or scheduled events. 
         [0034]    A workflow event  402  may be created in the normal design of a workflow process. For example, a workflow process designer may create a workflow in a workflow editor and include an “E-Mail Customer” event in the workflow process. 
         [0035]    A SmartObject may be a specialized construct that abstracts data and provides a business process designer with a set of standardized functions to interact with the data. The SmartObject may have a set of associated events. For example, the SmartObject may have a create event, update event, delete event, etc. A business process designer can create custom events  406 . The business process designer would need to implement a custom event recorder in order to properly interact with the generic client recorder  408 . 
         [0036]    A custom event  406  may be integrated with another business system and the customer event recorder may subscribe to specific events from a custom system through an event handler. For example, a custom event may be created for information retrieved from an external tax system. The custom event handler recorder may subscribe to an event of a rate in a tax table being updated. 
         [0037]    A scheduled event may be one designed to be executed at a specific time. For example, a scheduled event may occur once a week. 
         [0038]    The generic client recorder  408  may have a number of generic programming interfaces (APIs) for registering events, policies and message queue systems, allowing for customization of event systems. The generic client recorder  408  may also allow for any business system to be registered as part of the event management system, through the APIs. Once a system is registered, users can subscribe to events raised by that business system. 
         [0039]    When the event occurs, the generic client recorder  408  may receive notice that the executing event occurred from the specific event recorders. For example, the executing event may be “New Customer,” and once the executing event occurs, the event recorder may raise the event in the generic client recorder  408 . 
         [0040]    The generic client recorder  408  may determine what type of policy or policies will be run based on the executed event. For example, the generic client recorder  408  may interrogate the policies storage  412 , which may be stored on the business process database  106 , to determine which policies are associated with the executed event. For example, the generic client recorder  408  may determine that a “Send Email” policy is associated with the “New Customer” event. 
         [0041]    The policies may be of a conditional, action or exception type among others. A conditional policy may be a condition with a result in a true or false result. An action policy may merely perform an action without a true or false result. An exception policy may be used for error scenarios and be executed when certain error conditions are met. For example, a conditional policy may evaluate whether the “New Customer” name begins with an “A” and returns true or false. An action policy may be emailing a follow up email to a customer. An error policy may be to email a systems administrator with information regarding the executed event. 
         [0042]    The policies are all independently created and managed in the policy management system  412 . This allows a business to organize and manage the business policies independently of the usage of the policies. For example, a policy may be to email a user when the “New User” event is executed. If the business changed the policy to be to email a user and a customer representative, a business process designer only needs to access the policy instead of the entire new customer business process. 
         [0043]    After resolving what type of policy is to be executed, the generic client recorder  408  may determine what data from the executed event is necessary for the policies. The generic client recorder  408  may place the event, policies, and data onto the messaging queue  410 . The messaging queue  410  is an example messaging queue that may be implemented by messaging queue  314 . Alternatively, the generic client recorder may place the policies and data onto the messaging queue  410 . 
         [0044]    The messaging queue  410  may be any software messaging service, including commercial products such as MSMQ, Biztalk, etc., or custom messaging solutions. The message queue  410  may work in an asynchronous, first in first out order. For example, the oldest event in the queue will be the first event that is taken off of the queue, and will not be dependent on the clock cycle. 
         [0045]    The event bus  312  may receive the data and the policies from the message queue  314 . The event bus  312  may also save the policy mappings to the database for processing. The event bus  312  may then map the data to the policy and process the policy. For example, the data may be “User Name” and the policy may be an email action policy. The “User Name” data may be mapped to the correct data field of the email action policy by the event bus  312 . 
         [0046]    If execution of the policy results in failure, the event bus  312  may retry to execute the policy and after a retry count is exceeded an exception policy may be executed. For example, if an email action policy fails three times, and the retry count is three, then an email administrator exception policy may be executed and an email detailing the error may be sent to a systems administrator. 
         [0047]    The event bus  312  may also provide client server methods for administration. For example, the event bus  312  may provide the business designer terminal  102  with methods for administering the business process server  104 . 
         [0048]    A screenshot of an example event selection screen  500  is presented in  FIG. 5 . Although the example event selection screen  500  is described in reference  FIG. 5 , it will be appreciated that many other configurations are possible. For example, elements could be in different locations, elements could have different names, and elements could have different graphical representations. 
         [0049]    The event selection screen  500  may assist a user in setting up events to monitor. The event selection screen  500  may have a folder view area. The folder view area may have an object browser showing the different sources of objects. For example, a SmartObject browser  502  may correspond to a SmartObject Event source  404 . A Workflow Object browser  504  may correspond to a workflow event source  402 . The event selection screen  500  may allow the user to select a specific event  506  from an event source. 
         [0050]    A screenshot of an example event data screen  600  is presented in  FIG. 6 . Although the example event data screen  600  is described in reference  FIG. 6 , it will be appreciated that many other configurations are possible. For example, elements could be in different locations, elements could have different names, and elements could have different graphical representations. 
         [0051]    The user may be presented with an event data screen  600 . For example, the business process server  104  may transmit the event data screen  600  to the business process designer terminal  102 . The event data screen  600  may have an event data section  602 , that shows the selected event&#39;s information. For example, the event data section  602  may include a description, id, name, etc. The event data screen  600  may also provide the user with options of adding a policy or a condition  606 . 
         [0052]    A screenshot of an example add condition screen  700  is presented in  FIG. 7 . Although the example add condition screen  700  is described in reference  FIG. 7 , it will be appreciated that many other configurations are possible. For example, elements could be in different locations, elements could have different names, and elements could have different graphical representations. 
         [0053]    If the user selects to add a condition on the event data screen  600 , the business process server  104  may transmit an add condition screen  700 . The add condition screen  700  may provide a simple interface for adding logic for a policy. For example, a condition entry tool  702  may provide some common conditional logic  704  for a user to select from. The conditional logic  704  may include “and,” “or” and “not” operations. 
         [0054]    A screenshot of an example add policy screen  800  is presented in  FIG. 8 . Although the example add condition screen  800  is described in reference  FIG. 8 , it will be appreciated that many other configurations are possible. For example, elements could be in different locations, elements could have different names, and elements could have different graphical representations. 
         [0055]    If the user chooses to add a policy from the event data screen  600 , the user may be brought to the add policy screen  800 . The add policy screen  800  may have a policy selection window  802 . The policy selection window may allow the user to search for policies and select a desired policy or assist in creating a new policy. 
         [0056]    A screenshot of an example data mapping screen  900  is presented in  FIG. 9 . Although the example data mapping screen  900  is described in reference  FIG. 9 , it will be appreciated that many other configurations are possible. For example, elements could be in different locations, elements could have different names, and elements could have different graphical representations. 
         [0057]    Once a policy is selected, the business process server  104  may transmit a data mapping screen  900 . The data mapping screen  900  may display the data fields that the policy requires. The data mapping screen  900  may allow the user to map the data from the event to the policy. The data mapping screen  900  may have a data inputs section  902  displaying the required data. For example, an email user policy may have a “username” field to which the user can map an event&#39;s “new customer name” field. The user may drag and drop a field from the object browser  904  to the data inputs section  902 . 
         [0058]    A screenshot of another example data mapping screen  1000  is presented in  FIG. 10 . Although the example data mapping screen  1000  is described in reference  FIG. 10 , it will be appreciated that many other configurations are possible. For example, elements could be in different locations, elements could have different names, and elements could have different graphical representations. 
         [0059]    After selecting the fields to map from the event to the policy, the data mapping screen  1000  may display the finalized mapping  1002 . 
         [0060]    A screenshot of an exception selection screen  1100  is presented in  FIG. 11 . Although the example exception selection screen  1100  is described in reference  FIG. 11 , it will be appreciated that many other configurations are possible. For example, elements could be in different locations, elements could have different names, and elements could have different graphical representations. 
         [0061]    After configuring a policy, the user may select an exception policy on the exception selection screen  1100 . The exception selection screen  1100  allows the user to select an exception policy to run in the case of failure of the originally selected policy. For example, a user may wish to create or select a mail an administrator policy if the original policy fails to execute properly. 
         [0062]    It should be understood that various changes and modifications to the presently preferred embodiments described herein will be apparent to those skilled in the art. Such changes and modifications can be made without departing from the spirit and scope of the present subject matter and without diminishing its intended advantages. It is therefore intended that such changes and modifications be covered by the appended claims.