Introduction

This sample shows how you can use the complex event processing capabilities of ActiveVOS. We will use eventing with the HumanApproval sample process ("loanProcessHumanCompleted") to discover situations where too many loan applications are having to be processed by hand (over 5% in the past hour). When this situation is discovered, a new human workflow will be started which will allow a manager to review and possibly adjust the threshold amount that forces loans to be handled by a full review.

In addition to describing the primary scenario, we will also look at examples of other interesting event queries that can be written.

Generating events from processes

The first step to using complex event processing with a business process is to add events that should be generated during the execution of the process. This does not require modifying the process itself, but only its deployment descriptor. In this example, we've added four events to be generated. A screen shot of the eventing tab of the deployment descriptor is here:

 



The event types are:

LoanRequest: This is generated for every loan application and is triggered when the receive event that kicks off the process completes. It includes as business data the SSN and the amount requested in the application. Remember that the business data is in addition to the automatically generated properties of the event, such as the processId, the time of the event, and others.

AutoReviewComplete: This is generated when the process is about to end, after having followed a path that does not require human review (when the reply is about to be sent). The business data includes the risk assessment and the response that is being sent to the applicant.

FullReview: This is generated when the process is following the path that requires a full human review, and is sent just before the human task for that review begins.

LoanProcessComplete: This is sent at the end of the process, irrespective of the path taken. It is sent when the <flow> activity that surrounds all of the other activities is complete. Note that there is also an automatically generated event (with a type of AeEngineEvent) when processes complete, but explicitly declaring this event at the completion of the flow allows us to add business data in with the event. In this case we include the SSN, amount requested, and the response.

Querying process events

The next step is to create an EPL statement document (one of the document types), which holds EPL "statements". In most cases the statements will be "insert" statements, which generate new events when some pattern of the underlying process events are discovered. Other statements, such as creating named windows, are also possible, but not shown in these examples.

For the main scenario, there is a statement file called "pathsTaken.eps", which has two queries:

insert into PathsTaken
   select a.size as numReviewed, t.size as total
   from FullReview.win:time(1 hour).std:size() as a, 
      LoanRequest.win:time(1 hour).std:size() as t

This generates events that contain the number of processes in the past hour that followed the "full review" and the total number of processes in that hour.

insert into TooFewAutoApprovals
   select numReviewed, total, numReviewed*100 / total as percent
   from PathsTaken where total > 5 and numReviewed*100 / total > 5
   output first every 1 hour

This generates an event when the percentage of reviewed processes is greater than 5 percent (although it requires that the total be at least 5). Once such a condition is discovered, it does not generate another event for this until at least 1 hour has passed.

 

Kicking off a process

Whenever a "TooFewAutoApprovals" event is generated, we want to kick off a process to adjust the review threshold. The example contains an "EPL Pattern" file named "detectTooFewAutoApprovals.epp". This specifies the pattern to be detected, and the service to call if it is detected. In this case, our pattern is:

every (evt=TooFewAutoApprovals)

Most patterns will probably look like this. The assignment is important here, since the event that is given to the service contains the properties of any variable that is assigned inside the pattern.

In our case, the service to be called in reaction to this pattern is the "AdjustAutoReviewThreshold" process, which kicks off a simple process that allows any user in the "loanmgrs" group to update the review threshold.

 

Other Queries

The example project also contains a file called "epl/otherEventQueries.eps", which just show a few example queries that can be done with the events generated from our loan approval process. Here is a brief explanation of what each statement does.

 

insert into AutoReviewTimes
   select a.timeStamp.time-r.timeStamp.time as duration_ms
   from pattern [every r=LoanRequest -> a=AutoReviewComplete
   (a.processId = r.processId)].win:time(1 hour)

The pattern in this query joins the LoanRequest event stream with the AutoReviewComplete event stream, based on them having the same processId. This gives start and end events, but only for processes that went down the auto-review path of the process. Given the two events, it then generates a new stream that contains how long it took for that process (in milliseconds). It maintains these durations for only the past hour.


insert into AutoReviewsTakingTooLong
   select avg(duration_ms) as average_ms
   from AutoReviewTimes
   having avg(duration_ms) > 2000

This query looks at the average duration found in the 1 hour window described by the last query, and generates an event if the average is ever greater than 2 seconds (2000 milliseconds).


insert into SameDayDuplicates
   select r1.SSN as SSN,
          r1.processId as applicationProcess1,
          r2.processId as applicationProcess2
   from pattern [every (r1=LoanRequest -> r2=LoanRequest(r1.SSN = r2.SSN))]
   .win:time(1 day)

This query looks for any two loan requests that come in for the same social security number within a 24 hour period. A pattern could be created that uses these events to send a service request to the second of these processes, causing it to be rejected (perhaps).


insert into ApplicationAmountFor1Day
   select sum(amountRequested) as amount
   from LoanRequest.win:time(24 hours)

This query generates events that contain the current total for all applications received in the previous 24 hours. It can be useful as an input to another query.


insert into ReviewedLoanAverageAmount
   select count(*) as number, avg(amountRequested) as avg_amount
   from FullReview.win:time(1 hour)

This query maintains the average loan amounts that have needed to go to a full review over the past hour.


insert into FaultRate1Hour
   select completed.size as completed,
      faulted.size as faulted,
      faulted.size*100/(completed.size+faulted.size) as fault_rate
   from AeEngineEvent(state=1).win:time(1 hour).std:size() as completed, AeEngineEvent(state=7).win:time(1 hour).std:size() as faulted where faulted.size * 100 / (completed.size + faulted.size) > 20

This query takes advantage of the fact that the engine automatically generates events for major changes in a processes state (created, completed, suspended, resumed, faulted, etc). In this case, we are looking at the average fault rate for all process instances of all process definitions in the last hour.


insert into FaultRate1HourApprovalProcess
   select completed.size as completed,
      faulted.size as faulted,
      faulted.size * 100 / (completed.size + faulted.size) as fault_rate
   from AeEngineEvent(state=1, processName.localPart='loanProcessCompleted').win:time(1 hour).std:size() as completed, AeEngineEvent(state=7, processName.localPart='loanProcessCompleted').win:time(1 hour).std:size() as faulted

This query is like the query above, but it limits the search for process instances of a particular process definition. The "processName" property is a Java QName, so the easiest way to compare it is to just look at the localPart property of the QName (if that is unique enough).

 

Running the sample

Detailed instructions for working with this sample can be found in the "Working with the On_Event_Adjust_Threshold Sample" Cheat Sheet. This Cheat Sheet can be accessed by selecting Help > Cheat Sheets... > ActiveVOS Designer Samples > On Event Adjust Threshold from the ActiveVOS Designer main menu and then pressing <OK>.

 

Copyright (c) 2004-2009 Active Endpoints, Inc.