Abstract:
A method for automating a process includes the following steps: providing a user interface which graphically presents a plurality of icons to a user, wherein each icon represents an operation step having at least one input and at least one output; enabling the user to select one or more of the icons; enabling the user to form connections between the selected icons to represent data flow between the operation steps represented by the icons; and generating computer instructions for executing the operation steps corresponding to the selected icons, and in accordance with the connections, in such a way that each operation step can only be executed when data is present at all of its inputs, and cannot be executed when data is absent at any one of its inputs.

Description:
This application claims priority to Great Britain application 0501730.6, filed Jan. 27, 2005. 
     The present invention relates to business process automation, and may handle large numbers of complex messages very quickly. 
     BACKGROUND 
     The invention can be used in a large range of fields where process automation is required. The invention may be used for example to control machinery, such as a precision lathe or conveyor belts. It may also be used to automate processes in the fields of telecommunications, and to automate financial and business processes. 
     Traditionally experts in the field of a relevant technology or business formulate a set of requirements which for example may define a method of implementing a method or analyzing results. These requirements must then be translated into a formal set of processes and rules and converted into computer software processes which then implement the requirements. 
     For example a new pricing structure for gas and electricity may be devised by an energy supply company. The company managers and accountants will write a set of criteria by which the pricing structure is to be generated. In a simple example these criteria may include the cost to the company, the quantity used, the overheads and outgoings connected with supply and the profit to be achieved. These criteria, and their relationship to each other, might first be embodied in a written report. They must then be converted into a clear sequence of steps, for example by illustrating them in a flow chart diagram, and eventually a computer programmer translates the sequence of steps into computer code embodying the required process and rules to implement the new pricing structure. 
     This is an expensive and time consuming exercise and is vulnerable to the introduction of errors in the interpretation of the requirements and their translation into a finished software product because of the number of layers of personnel involved and the different “languages” or models of the world that they use. 
     Software packages are available to assist in the formulation of processes and rules but they are difficult for a non-computer expert to use directly and it is still necessary to employ an information technology expert. It is also known to use a data driven software model; see for example Dataflow Machine Architecture, Arthur H Veen, ACM Computing Surveys, Vol 18, No 4, December 1986. 
     SUMMARY 
     The invention provides a method of automating a business process and a computer system as set out in the accompanying claims. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which: 
         FIG. 1  illustrates, in graphical form, the automation of a process using the invention; 
         FIG. 2  illustrates a rule forming a part of the process of  FIG. 1 ; 
         FIG. 3  illustrates an example of a screen display during formulation of the rule of  FIG. 2 ; 
         FIG. 4  illustrates a set of icons for use in formulating the process of  FIG. 1 ; 
         FIG. 5  illustrates a set of icons for use in formulating the rule of  FIG. 2 ; 
         FIG. 6  is a flow diagram illustrating the compiled version of the rule of  FIG. 2 ; 
         FIG. 7  is a screen display illustrating one example of the process of the invention. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  shows the automation of an accounting process, but it is to be understood that the invention may of course be used in many different fields. 
     In  FIG. 1  a set of icons are shown connected together to illustrate one example of a business process. Each icon effectively represents a logic block or routine in the process and the icons fall into four general logic categories: source, routing, rules and target, each having their own distinctive appearance to make identification easier for the user. The icons can simply be selected from an on-screen menu and dragged and dropped in the appropriate place on the screen for example using a mouse to control a cursor shown as an arrow  40  in  FIG. 4 . 
     A suitable set of process icons is shown in  FIG. 4  and the icons represent: source, routing, rule, business process, batch split, batch merge, match and merge, sorting, reduction, storage, comment, abort, no operation, legacy, enrichment, legacy rule and target. Of course these are given as examples only. Thus, the user selects and positions, on the screen, each of a source icon, a routing icon, one or more rule icons and a corresponding number of target (output) icons. The user then generates lines on the display between icons to show functional connections between the logic blocks represented by the icons. 
     The icons are then labelled by the user who also adds further functional criteria defining operations to be carried out by the logic. For example, data attributes are chosen and operations for the rule blocks, are defined. These steps are typically taken using pop-up menus with predefined choices but the choices may be customised for particular business applications or particular users and may include options to define new definitions and operations as required. 
     The example of a process illustrated in  FIG. 1  is a relatively simple example and relates to the analysis of sales of a product. The process uses an external source comprising a sales report and produces output data for each of the total domestic and total foreign sales. The results can be supplied to an external data target such as a general ledger. 
     Thus a user selects a source block  1  and defines it as comprising a sales report  2  including a sales report database table  3 . The user then selects a routing block  4 , connects it to source block  1 , and defines the operation to be carried out by the routing block: ie to segregate the data from the database table  3  into two categories: “domestic”  5  and “ELSE”  6 . The user labels the output ports  5  and  6  accordingly. Two rule blocks  7  and  8  are then selected, positioned and connected so that domestic data  5  is supplied to “Domestic” rule block  7  and the rest of the data “ELSE”  6  is supplied to “Foreign” rule block  8 . Operations are carried out on the data according to the rules defined by the rule blocks  7  and  8  as will be explained in more detail with regard to  FIG. 2 . The results appear at the respective output ports  9  and  10 . The user selects two target blocks  13 ,  14  and connects one to each of the output ports  9  and  10 . The target blocks are then labelled appropriately “Domestic Sales”  13  and “Foreign Sales”  14 . These results at the output ports  9  and  10  are supplied to the respective database tables  11  and  12  of the target blocks  13  and  14  depending on whether the result relates to domestic sales or foreign sales. Data flow is of course from left to right in  FIG. 1 . 
     The rule blocks  7  and  8  are each defined by a similar method to that of  FIG. 1  and this is shown in  FIG. 2  where data flow is from top to bottom. The set of blocks for rule definition is shown in  FIG. 5 . These include Input, Input attribute, Expression, Case Reference Access, Reduction, Connect, Abort No Operation, Write Attribute, Route, Read Attribute, Output Attribute and Output. An input block  20  is selected and defined to comprise the sales report data segregated by the routing block  4 , either domestic  5  for domestic rule block  7  or foreign  6  for foreign rule block  8 . Attribute blocks are selected and defined as comprising “quantity”  21  and “price”  22  and these represent logic which extracts the relevant data attributes from the data. An expression block  25  is next chosen and defined to perform an operation to be conducted on the attribute values. In this case the attributes “quantity” appearing at input port  23  of the expression block  25  and “price” appearing at input port  24  are to be multiplied together and supplied at output port  26  to produce the resulting output attribute  27  comprising the “amount”. This result is written to the output report  28  appearing at output port  9 ,  10  respectively connected to a respective target block  13 ,  14 . 
     Thus it can be seen that a user of this system would select and connect appropriate process icons to define a process such as that illustrated in  FIG. 1  and would define the rules for rule blocks  7 ,  8  by selecting and connecting appropriate rule icons as shown in  FIG. 2 . Details would then be entered for each of the blocks to define, for example, the report to be used as a source, the attributes to be extracted, the operation to be carried out by the expression block  25  and what to call the data appearing at the output blocks  13 , 14 . This procedure is largely graphical and intuitive and it is not necessary to be a software engineer to use it. 
       FIG. 3  illustrates the process of defining the “amount” attribute block  27  in  FIG. 2 . The user clicks on the “amount” attribute block  27  and its properties are displayed in a pop-up property dialog box  29 . In this example three fields: attribute, type and description are included in the property box  29 . The user can enter alphanumeric data directly into the fields or can select the appropriate attribute from a pre-loaded list, for example as shown in the nested pop-up dialog box  33  which is displayed when the user clicks on the browse button  34 . In this example, the last item on the list “amount” is selected, as shown by the highlighting of this word. Also, in this example, the type of attribute is set as “numeric”. This may be automatically generated by the attribute selected, for example when “price”, “quantity” or “amount” is chosen and is indicated by the type of icon  34  adjacent the attribute description. This field controls the logic of the business rule and can be used to generate help or error messages to the user to guide them through the process. 
     Other blocks may also be defined by rules. For example routing block  4  must be defined by specifying the appropriate criteria by which data is selected for processing by the “domestic” route or the “foreign” route. This would typically be derived from the attribute “customer_country” in the list of attributes in box  33  in the illustration of  FIG. 3 . 
     The rule defined in  FIGS. 2 and 3  is an example of a flat data structure. Hierarchical data structures may also be used, in which multiple segments each containing attributes. For example, an invoice may contain “header information” giving details of each product on the invoice. There may be one or more “lines” for each header and such data is represented as a hierarchical structure. Of course very much more complex structured rules, and processes, can be formulated, as will be evident. 
     In addition to computations defined by the rules the system makes it possible to map many source attributes directly onto the target attributes and this is shown in  FIG. 7  where the user simply creates lines on the screen to join relevant source attributes in the sales report on the left to target attributes in the output report on the right, for example, transaction references and dates and customer identifiers (reference, name, telephone number) are all identical in both the input sales report and the output report. 
     The icons shown in  FIGS. 4 and 5 , illustrating sets of blocks for process and for rule definition respectively, are given as examples only and are not exhaustive. Alternative icons can be used and the icon set expanded to suit the particular process concerned. 
     Once the graphical representation of the process is completed by the user, and the rules have been defined and attributes selected, software according to the invention makes the necessary conversion into computer code to implement the process defined by the user. It does this by decomposing the logic block defined by each icon into intermediate code, representing elementary operators such as:
     Read—get data from a source.   eXtract—extract an attribute value from a message.   eValuate—evaluate a logical, arithmetic or relational expression.   Gate—perform a logical switch.   Store—write a value into a target attribute.   Write—write the output message to the target.   

     The compiled version of the rule illustrated in  FIG. 2 , using these elementary operators is shown in  FIG. 6 , and each box in  FIG. 6  represents one of the elementary operators, known as a “P-code operator”. Each of these P-code operators can be handled independently; the order of storage is irrelevant, because each P-code operator can only execute when there is data at all of its input ports, can only be in one of two states: not executed or executed, and can only be executed once. 
     The P-code operators for each rule or process are stored in a pool which is managed by an executive operator which periodically scans all of the P-code operators in the pool to search for operators which have data at all of their input ports, executes them, and changes their state from ‘not executed’ to ‘executed’. 
     The executive operator module starts execution of the program and it will then respond to input data by processing it through the nodes. The executive operator module can also cope with error handling, distributing the data load across multiple instances of the program, and/or managing low level functions such as caching reference data. 
     Thus, in the example of the rule of  FIGS. 2 and 6 , the following sequence of operations occurs:
     a) A first message arrives so data is presented to the source block  20  so that data is present at the input port of the Read operator (see  FIG. 6 ) which then becomes able to execute the Read operation. No other operators can execute because there is no data on any of their input ports.   b) When the Read operator executes, data is placed at the input ports of the operators eXtract  1  and eXtract  2 , so both of these could execute.   c) The executive operator will execute either one of these (the order does not matter), say eXtract  2  first, which places data at one of the input ports of the eValuate operator.   d) The eValuate operator cannot execute because it does not have data at both its input ports, therefore the only operator that can still execute is eXtract  1 .   e) When eXtract  1  executes, data is present at both input ports of the eValuate operator so this can now be executed which places data at the input port of the Store operator.   f) The Store operator executes which puts data at the input of the “Write” operator which then itself executes.   g) All the operators have now executed and are now in the state “executed”. They are reset and the whole cycle begins again for the next message.   

     This process has the significant advantage that a user does not need to specify a sequence of operations in the rules or processes, even where there is more than one possible path. Since operators only execute when data is present at all input ports the order of execution does not have to be predetermined in this model, and the user does not need to worry about the order of execution. For example in  FIG. 6  it does not matter which of the eXtract operators executes first, the result is the same since the evaluate operator will not execute until both eXtract operators have executed to put data at both data input ports for the evaluate operator. 
     Hence a user does not need to have any knowledge of computer language or procedure. 
     It will be seen that the system can use an entirely graphical interface to allow a user to design the necessary processes and rules. The interface works with a unique product architecture, made possible because of the data driven nature of the process. 
     Production of processes and rules is much faster and more efficient using the invention and subsequent maintenance costs much reduced. Processes and rules written using this software can, for example, process 20 million messages per hour. 
     Although the invention is shown and described with respect to certain embodiments, it is obvious that modifications will occur to those skilled in the art upon reading and understanding the specification, and the present invention includes all such modifications.