Abstract:
A method of improving the operational efficiency of segments of a data pipeline of a cloud based transactional processing system with multiple cloud based resources. The Method having a first step to virtually determine an approximation of a processing runtime of computations computing a value from transactions using potentially available resources of said cloud based transactional processing system for processing segments of a pipeline of data wherein said data comprising compensation and payment type data. A second step to determine an actual processing runtime of computations computing a value from actual transactions using actual available resources using available resources for processing segments of a pipeline of data wherein said data comprising compensation and payment type data. A third step for adjusting a difference between the approximation of the runtime of said first step and the actual processing runtime of said second step by changing material parameters at least including the volume of transactions and available resources at particular segments of the pipeline, to produce an optimum result in adjusted processing runtime.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of provisional Patent Application Ser. No. 61/578,205, filed Dec. 20, 2011. Both applications are assigned to the assignee of the present application, and incorporated herein by reference. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The present invention relates generally to grid-based application workflows in a flexible pipeline architecture, and more specifically to dynamically optimizing grid resource usage in a multi-stage operation by using data to perform calculations within each stage, and outputting the results of each stage to the subsequent stage and in the case of the first stage, performing calculations based on an initial set of data. 
       RELATED ART 
       [0003]    In a grid computation environment, particularly when executing multiple routines at any given time the customary approach has been to dedicate a fixed set of resources for each of the routines so as not to interfere with other routines executing. However, with increased data generation and stored such fixed pathway structure leads to inefficient execution time when large data sets are being processed. Hence, while in the past such fixed architecture has proved to be efficient and easy to develop and add to with multiple customers in an on-demand or server side environment because of the ever increasing complexities of instruction sets to execute a large data set for a particular customer an ever increasing amount of resources are needed. Further, the model of having a fixed set of resources for a particular pipeline operation has proved to be inefficient not only from resource allocation perspectives but also from the need for intermittent fast execution and cost basis when dedicated resources are left idle. 
         [0004]    A pipeline computation shall be defined as a number of sequential computational phases that begins processing a various amount of multidimensional data, where the output of one computational phase, being a various amount of processed multidimensional data, will be the input to the next computational phase in the sequence, until all of the multidimensional data has been sequentially processed through all of the computational phases, yielding a various amount of resultant multidimensional data. 
         [0005]    There is a need for a non-fixed pipeline architecture for pipeline computations that allows for the flexibility of using distributed resources to reduce complex processing time of data sets while still enabling prioritization of resources for chosen customers. 
         [0006]    There is a need for a resource allocation model for pipeline computations using for faster processing times during peak hours using idle resources dedicated to other customers to make up for the lag time while not interfering with already in use or about to be used resources with other customers. 
         [0007]    Finally, there is a need for a business model to charge customers for allocation of additional resources for pipeline computations in order to enable them to have results generated from faster processing of data sets. 
       SUMMARY OF THE INVENTION 
       [0008]    The present invention is directed to a method of improving the operational efficiency of segments of a data pipeline of a cloud based transactional processing system with multiple cloud based resources. The present invention has a first step to virtually determine an approximation of a processing runtime of computations computing a value from transactions using potentially available resources of said cloud based transactional processing system for processing segments of a pipeline of data wherein said data comprising compensation and payment type data. A second step to determine an actual processing runtime of computations computing a value from actual transactions using actual available resources using available resources for processing segments of a pipeline of data wherein said data comprising compensation and payment type data. A third step for adjusting a difference between the approximation of the runtime of said first step and the actual processing runtime of said second step by changing material parameters at least including the volume of transactions and available resources at particular segments of the pipeline, to produce an optimum result in adjusted processing runtime. 
         [0009]    The present invention is additionally directed to a method of determining incentive based compensation. It includes modeling a pipeline using a grid configuration for workers having a set of incentive based characteristics being associated with each of the workers and Allocating resources for each of the workers in the grid configuration for processing with the incentive based characteristics through the modeled pipeline. Additionally, Modeling a set of rules associated with the incentive based characteristics for the workers using resources of the grid configuration and figuring out the runtime for processing both the rule set and characteristics of the workers through the modeled pipeline. Also, there is an ascertaining an actual runtime of a pipeline using a grid configuration for workers having a set of incentive based characteristics being associated with each of the workers. Then Determining an allocation of resources for each of the workers in the grid configuration for processing with the incentive based characteristics through the modeled pipeline, and Determining a set of rules associated with the incentive based characteristics for the workers using resources of the grid configuration and the actual runtime for processing both the rule set and characteristics of the workers through the modeled pipeline. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0010]      FIG. 1  shows a block diagram of a computational pipeline according to an embodiment of the present invention. 
           [0011]      FIG. 2  shows a table of stages, rules processed, and actions according to an embodiment of the present invention. 
           [0012]      FIG. 3  shows a system level architecture for the multiple connections in the pipeline computational process according to an embodiment of the present invention. 
           [0013]      FIG. 4  shows a system level block diagram of an embodiment of the present invention. 
           [0014]      FIGS. 5A-E  are flowcharts of the provisioning and grid requirements of the multi-grid configuration for processing the computational pipeline according to an embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0015]    The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiments and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features described herein. 
         [0016]    The basis for this invention is an auto-configuring distributed computing grid where a pipeline computation will begin with a various amount of data, have each computational phase produce a various amount of data and yield a various amount of resultant data, as described above, yet complete the total pipeline computation in a specified amount of time by dynamically allocating its resource usage for each computational phase. 
         [0017]    With reference to  FIG. 1  a block diagram of a pipeline is shown in accordance with a preferred embodiment of the present invention. The pipeline  10 - 40  pipeline is a computation engine that performs processing tasks to validate and transfer data, calculate compensation, and create payments. The pipeline  10 - 40  processes order, transaction, and reference data (compensation plans, participants, positions, territories, quotas, etc.) to calculate compensation. Typically, data is imported in the form of orders received and transaction data. In addition, for some organizations, credit data  15  may also be imported from an outside system. The end result of pipeline processing is a payment  40  amount for each position assignment for the specified period. Payments are then exported to a payroll system. A pipeline is typically run to calculate compensation and payments at least once per given period. 
         [0018]    During a pipeline run the computation engine processes data in stages, each of which takes input data, performs actions based on the rules for that stage, and produces output data. The output of each stage is used as input to the next stage in the sequence. A sequence in this instance is a set of one or more pipeline stages. 
         [0019]      FIG. 2  illustrates a table containing each of the pipeline stages. An individual pipeline stage may be run independently, or an entire sequence including all of the stages may be run. Each stage corresponds to a set of rules which belong specific to a particular stage. The rules are applied within each stage, and the actions that occur (shown in  FIG. 2 ) result from the rules applied ( 55  to  75 ) in the table. 
         [0020]    Beginning with the Classify Stage  50 , transactions which were previously stored in a repository are input to the Classify Stage. The Classify Stage  50  uses clarification rules  5565  to determine how to bundle the transactions using categories, and the output of the Classify Stage  50  is classified transactions. During the Classify Stage  50 , transactions are grouped in meaningful ways. For example, product, geography, channels, and customers is one way to group the transactions. Grouping the transactions advantageously allows for more efficient and effective processing of the transactions. For example, when assigning credits for transactions to a set of participants, it may be faster and easier to identify such participants by their workplace location, or customer grouping. Classification rules are different from the other rules because they are not assigned to a particular plan. 
         [0021]    Credit Stage  55  calculates credits and then allocates the calculated credits to positions. In this instance, a credit is a value that may be allocated to either the transaction or the order itself. Credit Stage  55  differentiates between two types of credits: direct and rolled. A direct credit is allocated to the sales representative who is directly responsible for the transaction, while a rolled credit is allocated to others as defined by roll relationships. The input for Credit Stage  55  is the classified transactions which were the output from Classify Stage  50 . The output for Credit Stage  55  consists of calculated credits for each position assignment. Primary Measurement Stage  60  calculates primary measurements by aggregating credits from Credit Stage  55 . The calculated credits from Credit Stage  55  are the input for Primary Measurement Stage  60 , and the output of Primary Measurement Stage  60  are primary measurements for each position assignment. The primary measurements are an aggregate of credit amounts that were specified by the user for each position assignment. 
         [0022]    For Secondary Measurement Stage  65 , the pipeline calculates secondary measurements using one of two methods: a) calculating values based on formulas; or b) aggregating primary measurements based on secondary measurement rules. For example, many companies create a secondary measurement rule to calculate a measurement called attainment, calculated by dividing the sum of primary measurements by a quota. The attainment value can then be used in rate tables used by rules in the incentive stage to calculate award amounts based on different rates of attainment. The input to Secondary Measurement Stage  65  is primary measurements for each position assignment (output of Primary Measurement Stage  60 ), and the output of the stage is secondary measurements for each position assignment. 
         [0023]    Incentive Stage  70  calculates potential earnings (incentives and commissions) by comparing primary measurements or secondary measurements against the incentives for each position assignment in a compensation plan. The input to Incentive Stage  70  is primary and secondary measurements for each position assignment. The output of Incentive Stage  70  is incentives associated with each position assignment. 
         [0024]    Deposit Stage  75  calculates incentives which are to be paid and converts them into deposits. A deposit is the amount of compensation calculated for a position for the period for which the pipeline is run. Pipeline calculates the amount of incentive earnings deposited as well as when the deposit may be made. For example, a user may wish to hold deposits that are associated with an unpaid customer invoice. In the alternative, a user may wish to hold deposits that exceed a maximum earnings policy for a product. In addition, in establishing deposit rules, a user may also specify conditions for a hold, as well as the release date. The input to Deposit Stage  75  is the incentive amount from each position assignment. The output of Deposit Stage  75  consists of deposit amounts and the dates of each payment. 
         [0025]    The deposit amounts and payment dates output from Deposit Stage  75  are input to Pay Stage  80 , where pipeline aggregates the deposits for each position assignment and converts those that are ready to be paid into trial payments. Deposits are associated with current period earnings, while payments represent incremental earnings for the period plus any balances from prior period earnings. The output of Pay Stage  80  is trial payments for non-finalized periods, and trial balances for finalized periods. 
         [0026]    The trial payments and trial balances output from Pay Stage  80  are input to Post Stage  85  where they are permanently stored and marked “posted”. Each posted payment represents a check that will be paid to a participant or user. Both the posted payments and balances are output from Post Stage  85  and input to Finalize Stage  90 . In Finalize Stage  90 , pipeline closes payments for a specified period. Balances are then calculated for all closed positions. In addition, any negative incremental deposits that remain may be converted to a negative balance at this point. 
         [0027]    The pipeline includes each of the stages described above (Classify Stage  50 , Credit Stage  55 , Primary Allocate Stage  60 , Secondary Measurement Stage  65 , Incentive Stage  70 , Deposit Stage  75 , Pay Stage  80 , Post Stage  85 , and Finalize Stage  90 ). To calculate compensation or create payments, one or more of the pipeline stages must be run. For the most efficient pipeline operation, a particular segment may be run. A segment consists of multiple stages which are consecutively run. In a preferred embodiment, pipeline contains a total of three segments (not shown), each of which are driven by different kinds of processes: 1) Classify segment; 2) Compensation segment; and 3) Pay, post, and finalize segment. The Classify segment operates based on user-defined classification rules. The Compensation segment (shown in  FIG. 1 ) operates based on user-defined compensation rules and consists of Credit Stage, Primary Allocate Stage  15 - 20 , Secondary Measurement Stage  25 , Incentive Stage  30 , and Deposit Stage  35 . The Pay, post, and finalize segment differs from both the Classify segment and the Compensation segment because it is driven by system-defined processes instead of the user-defined rules which form the basis of the other segments. 
         [0028]    The first part of the process to is to theoretically determine the time that the pipeline processing is to take. There are three types of pipeline computational methods and a determination is made with respect to the amount of data i.e. input stage, the amount of conditions and the amount of resources (the classify to the pay stages) as to which method is the optimum method to use. Hence, an user can subjectively decide which method is most application with to determine the processing times vs. data amounts, and use the following methodology: 
         [0029]    1) Computational phases (with reference to  FIG. 3  block  95 ) where the data amount processed contributes in a linear manner to the processing time will be shown as: 
         [0000]        T 1= L ( v*n )       i. T 1 =processing time   ii. v=a data amount unit   iii. n=a number of units   iv. L=a linear function         
         [0034]    As shown in the equation above there are 4 factors that determine the processing time T 1  and there are proportional to the amount of data units V, the number of the data units N, and the linear function; this is basically that the upon an increase in the V,N the linear function which processes the units on a case by case basis increases in time exponentially. 
         [0035]    A second scenario is when computational phases where the data amount processed contributes to some factor of processing time will be shown as: 
         [0000]        T 2= F ( v*n )       i. T 2 =processing time   ii. v=a data amount unit   iii. n=a number of units   iv. F=a non-linear function         
         [0040]    In the second scenario the processing time  12  is calculated by a data amount unit V, a number of units N, and a non-linear function of the units F. If there is a non-linear function that the time allocation is proportional to the non-linear amount from the function. 
         [0041]    Computational phases where various data amounts will be processed in a constant processing time will be shown as: 
         [0000]        T 3= C ( T 3)       i. T 3 =processing time   ii. C=a constant function         
         [0044]    With phases B, D and F being Constant time phases and to arrive at this run time approximation, the amount of time from the phases with linear functions (T 1 ) and non-linear functions (T 2 ) will be computed and summed. Their combined time (Tc=T 1 +T 2 ) establishes the time required to process data amounts where the processing time is determined by the data amounts. Subtracting Tc from the amount of time specified to complete the pipeline computation (Ta) results in the time remaining to completion (Tr=Ta−Tc). The value of Tr will then be divided. Among the Constant time phases, however, each Constant time phase may not contribute equally to Tr but their sum will equal Tr. 
         [0045]    The above three methods all use a determination of the processing time, and the processing time or run time can be figured out using the below equation and then then entire processing of the pipeline can be determined by one of the above three methods. The equation is as follows: 
         [0000]        Ta=Σ 1 SaL ( Va*Na )+Σ1 SbF ( Vb*Nb )+Σ1 Sc  
 
         [0046]    Fig. A 
         [0047]    In the above equation the processing time or Run-Time is determined as follows by referencing Figure A above and with reference to  FIG. 3  block  100 . As an example, during the run-time (or actuals with reference to  FIG. 3 , block  105 ), phase A may have produced a larger or smaller data amount than estimated and may have taken 8 minutes instead of the approximated 5 minutes to complete. The time remaining to complete Phase B within its projected target time will now be 15 minutes instead of 18 minutes. Phase B will make the necessary distributed computing adjustments to complete processing in 15 minutes. Both phase B and phase C&#39;s processing time and data amount estimates may or may not be on target with the actuals, but phase D will make the necessary adjustments to complete at its target time (this goes for being both behind schedule and ahead of schedule). This continues until all phases have been processed which will result in a run completion time very close to the specified amount of time given. C(T) Single Computation Grid shared by multiple tenants. 
         [0048]    As shown in  FIG. 4 , there is a parameter library  110  and input/output data  115  combined to customer supplies input data outputs required and length processing time  120 . It should be noted that the computational phase is when a computing algorithm applied to input data that yields output data. The computational node is a Java Virtual Machine (“JVM”) process that runs a Computational Phase and the Distributed Computing Grid is a grouping of physical servers  190  that run one or more Computational Nodes  200 . During a Multi-Node Phase is when more than one Computational Node (of the same Computational Phase) run concurrently where each Node processes a subset of the total input data and yields a subset of the output data until the total input data has been processed yielding the total output data. 
         [0049]    Next, the single-Node Phase  190  is a single Computational Node that processes the total input data and yields the total output data. The Computing Stage  130  is a predefined sequence of Single-Node and Multi-Node Computational Phases, where each Phase executes a unique computing algorithm, with each Phase in the sequence using the output data of the previous Phase as its input data (with the exception of the first Phase whose input data is supplied by the customer). The Distributed Computing Adjustments are the Phases with Constant processing time are Single Job queue shared by multiple tenants  140 . The Jobs for different tenants can run in parallel to each other. 
         [0050]    As shown in  FIG. 5   a , the grid provisional model includes a single computational grid  210 , a single job shared by multiple tenants  220 , jobs for different tenants run in parallel  230 . With reference to  FIG. 5   a , parallelism  240  within the tenant is still governed by current rules i.e. two exclusive jobs cannot be run parallel for a given tenant. There is no static pooling of worker resources. All workers get assigned for a given Computation run at runtime by the OD Administrator. In today&#39;s Grid, OD Admin has to specify worker host resources for each tenant to use  250 . Worker resource allocation to a Job happens as a part of changing a job state from Queued to Submitted  260 , done by OD Administrator. Additionally, there is a need to have a staging queue where all the submitted jobs are queued by submit time. OD Admin will start the jobs manually and specifying which worker resource  270  to use and when the operation should begin for example during night time and the worker resource who is to start the job  280 . Next, there is an auto mode where jobs are to be run based on priority in a FIFO round robin fashion. Hence, jobs are routed according to those jobs first submitted and to the jobs last submitted. 
         [0051]    More worker resources can be allocated to an already running Pipeline Run at run time based on the availability of resources. Users should be able to startup a Grid Service and it will join the Grid automatically. i.e. once Grid Services is started, the machine should be available for worker resource allocation. A concern here is the how many worker resources can be allocated to a machine or what is the total number of worker resources that a machine can hold. The OD Administrator can specify by user or worker allocation number or by the Grid Service and then can figure out the architecture and available memory for the machine. 
         [0052]    The Grid Administrator User Interface  300  shows a multi-tenant view of the Jobs and Worker Resources. The Grid Admin UI is generally displayed in a tile layout with all the available workers and their status. This Grid Admin UI  310  should show how many workers are available and how many are used for a particular host instead of showing worker itself. Grid Admin UI  310  to check the status of availability of worker resources i.e. which worker VMs are busy and which ones are idle. All worker resources are defined globally across tenants i.e. run n workers on Host X, run n workers on Host Y without any association with tenant. Worker failure will not bring down the run. The portion of the job that was being processed by the worker, gets picked up by other workers. This only works for Allocate partially. 
         [0053]    The grid requirements for the pipeline allocation process are shown in  FIG. 5   c  and require the following: the OD Administrator should control  400  when a Job goes from Pending State  410  to Submitted State  400 , given the availability of worker resources. All Jobs run from command line or UI are always queued up in a global Job Queue. Job Queue will run in two modes: Manual  440 —In this mode all incoming Jobs are queued in the Job queue and do not start until marked as Runnable by OD administrator. Auto  450 —In this mode all incoming jobs are queued in the Job queue but the Job Queue Manager will start the job at the top of the queue if resources are available. 
         [0054]    A Job can go through following states: —Queued  470 . This is when a job is Submitted  480 . (when the job is marked as Runnable manually be OD admin or in case of Auto Mode when Job Queue Mgr. puts it in Runnable mode)  490 ; Running In-cancel (for a cancelled job only)  500  and Stopped  510 . 
         [0055]    Notification system  520  will let OD Administrator configure a set of email addresses to be notified when a Job comes in. A Job can have one of the following End Status at the end of the run  530 : —Successful  540 , Failed  550  and Cancelled  560 . 
         [0056]    The OD Administrator can Monitor activity across the Grid  570 : such monitoring would include—Phases with Constant processing time are Multi-Node Phases that utilize various amounts of distributed  580 ; Computing resources such that the processing of various data amounts will complete in the amount of time calculated for the phase  590 . This is accomplished by adjusting the number of Computational Nodes per Multi-Node Phase. Since a Computational Node is a JVM, the total amount of RAM used by the JVM also needs to be calculated for each Node. Since a physical server has a specific amount of RAM, the number of concurrently running Nodes on a physical server is therefore limited by the RAM allocated for each Node and the amount of specific RAM on the server. 
         [0057]    The total number of concurrently running Nodes in the Grid is therefore the total number of Nodes that can be run on each server for each server that&#39;s in the Grid. Nodes will be allocated on each server using a “best fit” calculation to maximize the number of Nodes that can run concurrently given the RAM usage of each Node. 
         [0058]    Since servers contain multi-core CPUs, another calculation will also limit the number of concurrent Nodes to not over utilize the number of cores on each server. Since any Phase of a Computing Stage can be simultaneously running on any server in the Grid (since many concurrent pipeline computations can be running), this Adjustment calculation will also consider the CPU load imposed by a Phase. 
         [0059]    The Distributed Computing Adjustments take into account both RAM and CPU usage of each Computational Phase and its partial allocation of overall server resources within the Grid when calculating the computing resources required to complete the computation in a specified amount of time Show all running jobs. Below is the pipeline report showing an example of the computation of resources. 
         [0000]    
       
         
               
             
               
               
               
               
               
               
               
             
           
               
                   
               
               
                 Report A 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 Submit 
                 Tenant 
                 Command 
                 Argu- 
                 Status 
                 Progress 
                 Error 
               
               
                 Date 
                 Id 
                   
                 ments 
                   
                   
                 Count 
               
               
                   
               
             
          
         
       
     
         [0060]    For example from the about report (See Report A above), there is seen all pending jobs  580  and show detailed status of a given Job such as a Cancel a running job  600 . Additionally there is shown all active workers on all Worker Hosts; Grid Configuration  620 ; Set up Grid Server  630 ; Added Worker Hosts Specify number of workers on a Host  640  and Specify maximum memory  670  for each worker. Minimum memory will be a global default but if the OD Admin wants, it can edit that too  660 . 
         [0061]    Grid Configuration changes  660  require Grid Restart. Define worker configuration for a Tenant  670 . Starting a Queued Job  680 . OD Administrator can start a queued Job by selecting that Job and click on Start button. OD Admin is taken to the UI to override worker resources for the Job being started, if needed. In case the OD admin wants to start the run by overriding static worker configuration, OD Admin can view a list of Worker Resources that are available for allocation. Cancelling a Running Job. OD Administrator can cancel a running job  690  by selecting that job and clicking Cancel button. 
         [0062]    The job being cancelled will go from state Running to In-Cancel. Once the job is successfully cancelled, the workers allocated to the job will become idle and once again available for allocation. The job will change its state to Stopped with Status Cancelled. 
         [0063]    Locking Edits  700  across multiple users and Editing of Grid Configuration will require obtaining a lock before editing Grid Configuration so that multiple users don&#39;t overwrite each other&#39;s changes. Starting a Job will also put the job in the exclusive lock so that some other OD Admin user may not be able to start it at the same time as well. The lock will be removed once the job is successfully started. Cancel job will go through exclusive locking process like the one for Starting a Job. 
         [0064]    The many features and advantages of the embodiments are apparent from the detailed specification and, thus, it is intended by the appended claims to cover all such features and advantages of the embodiments that fall within the true spirit and scope thereof. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the inventive embodiments to the exact construction and operation illustrated and described, and accordingly all suitable modifications and equivalents may be resorted to, falling within the scope thereof.