Real time business process analysis method and apparatus6763353Abstract A method for monitoring a business process model in which at least one business process object transitions between states. A query having at least one state for the business process object and at least one time-based condition is defined. The query is applied to the business process objects that have changed since a last query application step as a result of execution of the business process model. Events are published when the results of the query are different from previous results of the query. The time based conditions can include conditions compared to actual time and can aggregated values of attributes of plural business process objects and current time. Claims What is claimed: Description BACKGROUND
module quoteObjects {
struct Product {
long product_id;
string product_name;
};
struct SupplierQuote {
string supplier_name;
float price;
boolean available;
};
typedef sequence<SupplierQuote> SupplierQuotes;
// *** THE BPO IS DEFINED HERE ***
interface ProductQuote: bpe::BusinessProcessObject {
// *** Attributes ***
attribute Product product;
attribute SupplierQuotes supplierQuotes;
attribute long currentReplies;
// *** Methods ***
void notifySuppliers( );
void receiveQuotes(in bpe::BPID id,
in string supplier_name,
in float price,
in boolean available);
};
};
Business process objects can have attributes that describe the object. For example, the product quote object includes three attributes called "product," "supplierQuotes," and "currentReplies." The "attribute" portion of the business process object constitutes a source schema defining which data values of the business process object are available to a query. Business process objects can have any attributes, such product ID numbers, vendor ID numbers, or any type of data or metadata that may be useful. FIG. 3 illustrates integration server 30 in a schematic manner. Business process model 100 is executed by execution engine 32. Analyzer engine 36 extracts data from execution engine 32 relating to the execution status of business process model 100. For example, execution engine 32 notifies analyzer engine 36 of state changes in business process objects when it commits the changes. Analyzer engine 36 then applies process queries in query set 60 to the business process objects that have changed and adds the results to query results 50 which can be stored in repository 48 or in any memory device. Queries 62 and 64 are applied only to business process objects for which they are defined, as described below. Each query 62 and 64 then computes the changes in query results 50 as compared to a previous application of the queries. Each query then creates events for all changes in its results and the events are published by event service module 34 to channel 70. Target 80 subscribes to channel 70 in a known matter to thereby receive the events in substantially real time. Target 80 can be a business process model or other device, as described below. For example, events can be any one of "add," "change," and "delete" events as described in detail below. Process queries can be grouped into process query models, i.e. plural queries associated with a business process object type. Process queries can be of several types. For example, a query can be a time based query which includes time based conditions with respect to the current time. Also, a query can be an aggregation query which computes aggregate values of objects attributes. A query also can be a simple filter query which determines whether an object satisfies certain conditions that are not based on the current time and do not include an aggregation function. Queries can be generated using Object Query Language (OQL). For example, a query can be of the form of Query Example (1) below:
SELECT
QuoteID: c.oid
ProductName: c.product.product_id,
ProductName: c.product.product_name
FROM
c IN quoteObjects::ProductQuote
WHERE
(current_time - c.timeCreated) > 7000) AND
(c.bpStateAT "WaitForQuote")
This query, referred to as the "long response query" herein, returns all business process objects of business process model 100 which are still in the wait for quote state 104 7000 milliseconds after creation of the business process object. Note that, in the preferred embodiment queries utilize the Backus-Naur syntax form listed in Appendix A attached hereto. However, any syntax can be used. A target schema can be created to describe the structure of change events that are published by analyzer engine 36 on behalf of a query. Each query of the preferred embodiment includes a "select" clause defining the data items to be included in the target schema. In the example of the long responses query above, the select clause states that the target schema includes three variables, "quoteID," "ProductID," and "ProductName." Each change event generated by this query will contain the data that is defined by these three variables. Accordingly, the target will receive only the data that is defined by the target schema. Further, a query can include a "where" clause to remove specified business process objects from application to the query. A where clause can contain a logical expression of a time based filter condition which, if evaluated as false, will exclude the evaluated business process object. The "from" clause of the query specifies which business process objects are to be subjected to the query, i.e, the source of data. As noted above, queries of the preferred embodiment can be classified into three categories. A "filter query" monitors individual business process objects to detect violation of conditions in the query. For example, a filter query might have a condition that all incoming orders must be processed in less than one hour. If a specific business process object, i.e. an order, does not reach the processed state within an hour, such a query will add a record to its result set. Note that result set 50 can comprise plural result sets corresponding to plural queries. An "aggregate query" is performed on a related group of business process objects, as opposed to an individual business process object. Each record in a collection corresponding to an aggregate query is based on data gathered since the query began execution. An aggregate query is violated when a numeric quantity calculated from an aggregation of business process objects has crossed a predetermined threshold defined as a condition of the query. For example, a condition of an aggregate query may be that the system handles orders on average in under thirty minutes. If the average time to fill an order, i.e. the average time for business process objects to reach a state corresponding to a filled order, exceeds thirty minutes, such a query will add a record to its result set. An example of an aggregate query is found in Query Example (2) below.
SELECT
ProductID: c.product.product_id,
AverageTime: AVG(current_time - c.timeCreated)
FROM
c IN quoteObjects::ProductQuote
WHERE
(c.bpState AT "QuoteCompleted")
GROUP BY
ProductID
HAVING
AverageTime > 600000
The query above groups all the business process object that have reached QuoteCompleted state 106 of business process model 100 by their ProductID parameter and, for each ProductID parameter, calculates a record that contains the ProductID parameter and the average time the system took to fulfill all the quotes that relate to that ProductID parameter. The query then returns only those records where the average time is greater than ten seconds (600,000 milliseconds). This query is an aggregate query because of the "AVG" function, which is computed as the average value of the quantity (current_time--c.timeCreated) for all the qualifying business process objects that have the same ProductID parameter. Note that this query is not applied to all business process objects because the "where" clause selects only those business process objects that are currently in QuoteCompleted state. There are three "value functions" that are used in the select clause to create an aggregate query in the preferred embodiment. Of course, any type of calculation or other processing can be incorporated into a value function. The "sum" function returns the sum of a given parameter, or parameter-based expression, for all the business process objects that have been grouped together. The "avg" function returns the average value of a given parameter, or parameter-based expression, for all the business process objects that have been grouped together. The "count" function returns the number of business process objects that have been grouped together. A "group by" clause can be used to cause the matching data to be organized by a given query variable. If the "group by" clause is present, a value function in the select clause causes all the records that have the same value in the "group by" field to be collapsed into one data record. A group by clause can list more than one query variable. If this is the case, the aggregate query adds one record to its collection for each unique combination of query variable values. A "having" clause can be used to cause the expression following the having keyword to evaluate to a logical value, e.g., true or false. The only "variables" allowed in this expression are query variable that were defined in the select clause. The "having" clause can act as a final filter on the query. For a record to be included in the query's result, the expression in the having clause must evaluate to true. Time-based queries, have a "current time" variable which returns the current "wall clock" time to permit the query result set to change with passage of time by comparing time attributes of a business process object with the current time. Time-related variables in such queries can be expressed in any time units and can be expressed in actual time, or time relative to a fixed time. In the preferred embodiment, time-based queries use the current time variable in the where clause. For example, query example (1) above creates records for business process objects that are still in the wait for quote state 7000 milliseconds after being created. Significantly, time-based queries do not require a change in a business process object to cause change events to be published. In particular, because the where clause of a time-based query includes the current time variable, the value of any time-based query may change between true and false based on the passage of time alone. Keep in mind that, while the preferred embodiment only applies queries to changed business process objects, a query's result set can persist records corresponding to business process objects that have not changed in the last transaction commit. Accordingly, query results can include records corresponding to unchanged business process objects. A query can be both time-based and aggregate by using the current time variable inside a value function that is part of the "select" clause. When a transaction commits, an epoch group, which represents the accumulated changes made to all business process objects since the last transaction commit, is sent to the analyzer engine 36. For each query, analyzer engine 36 computes the resulting changes, if any, to the query result associated with that query. The changes to each query's result are represented as a list of change events and are published to the appropriate query channel, channel 70 in the preferred embodiment. In the preferred embodiment, the change events include "add," "change," and "delete" events. Event service module 34 of sends an add event when a new record needs to be added to the target collection. This event contains the data needed to add a new record to the collection. A change event is sent when an existing record in the target needs to be changed. This event contains a copy of the record before the change, plus a copy of the record after the change. A delete event is sent when a record needs to be deleted from the target collection. This event contains a copy of the record to be deleted. In the case of an aggregate query or a time-based query, analyzer engine 36 stores intermediate query results that enable it to keep each query's collection up to date with minimal computation. Accordingly, event service module 34 defines an event interface based on the query. The structure of a query's change events is determined by the query's target schema. Each query can have its own set of change events, which can be different from the change events of any other query. The definitions of a query's change events can be embodied in an event interface named "queryName_Updates," where "queryName" is the name of the query in question. The structure of the events created by the long response query is shown in FIG. 4. The query's name is LongResponses, the name of the event interface is LongResponses_Updates. You can see that this event interface contains the "add," "change," and "delete" events. The event interface is thus generated from the query. As illustrated in FIG. 4, the add and delete events of the preferred embodiment contain a parameter, named "obj." The change event of the preferred embodiment contains two parameters, named "oldObj" and "newObj." Each parameter includes appropriate variables to be transmitted with the event record in a tree structure. All of the parameters have the same data type, which is given by the query's name. The structure of these events is: event void add(in LongResponses obj); event void change(in LongResponses oldObj, in LongResponses newObj); event void delete(in LongResponses obj); While the structure of the delete event of the preferred embodiment is identical to the structure of the add event, the change event contains two parameters, "oldObj" and "newObj," because it is notifying target 80 that an existing record in the collection (identified by "oldObj") should be changed to contain the information in "newObj." Each "obj" struct contains the data specified by the target schema for the query. Using the sample aggregate query above to illustrate a change event, assume that this query's collection contains the record [4011, 7055], wherefore 4011 is the value of its ProductID field and 7055 is the value of its AverageTime field. Now assume that some time has passed and the value of AverageTime for the same product has changed to 6983, changing the record into [4011, 6983]. The query will publish a change event, since the change that has occurred is simply a change in one or more of the fields of the already existing collection record. The old value of the record is [4011, 7055], while the new value of the same record is [4011, 6983]. Analyzer engine 36 will set the value of oldObj to [4011, 7055] and the value of newObj to [4011, 6983]. Then it will publish the following change event to channel 70: change(oldObj, newObj) Target 80, i.e. a target process, upon receiving this change event, has the responsibility for finding the record [4011, 7055] and changing the value of the second field, AverageTime, from 7055 to 6983--in effect, the change event changes an existing collection record. For example, target 80 can be a business process model for enforcing a service-level agreement, that dictates a minimum level of service performance agreed to by trading partners. In addition to recreating the query's collection using the change events, target 80 can use the incoming change events in other manners to achieve any desired result. Target 80 can use a subscriber program, i.e., a custom program that receives the change events published to channel 70. Further, target 80 can be a separate execution engine which can receive change events from channel 70 and enforce a service-level agreement. For example, target 80 may be configured to monitor business process model 100 for business process objects that have been in state 104 for more than seven seconds. To do this, a process model can be created to listen to channel 70 to which the long response query publishes events. Such a business process model would be designed to recreate the query's collection and react appropriately to each business process object represented by a record in the collection. If it were assumed that a business process object delayed for seven seconds indicates a serious error, one possible response would be for target 80 to send a pager message notifying the appropriate personnel of the problem. Target 80 can also be a portal or other system for displaying information. Execution engine 32 is operatively coupled to analyzer engine 36 to permit initialization of business process objects. For example, upon initialization due to hardware boot up or the like, an initial collection of business process objects is computed and queries are applied to the initial collection before any state changes are published. This coordination establishes the initial query results which are needed for comparisons against subsequent query results computed by analyzer engine 36. The invention can be used with any type of queries and can be applied to any type of business process. The invention can be implemented as software modules on any type of computer or computer system. For example, one or more general purpose programmable computers can be programmed to accomplish the functionality disclosed above. The invention can be used to generate any type of reports, or other actions in response to business process activity. Any type of programming languages, protocols, messaging standards and the like can be used to accomplish the invention. Queries can be constructed in any appropriate format. Queries can be embodied as components of an integration model as described in the concurrently filed application entitled Integrated Business Process Modeling Environment and Models Created Thereby The various functions and modules can be grouped in software or hardware in any matter. The invention has been described through a preferred embodiment. However, various modifications can be made without departing from the scope of the invention as defined by the appended claims and legal equivalents thereof.
APPENDIX
The tables below define the subset of OQL that
Business Ware uses for SLA
queries. Here are some conventions that you should
keep in mind:
The description of the query language grammar below
uses the Backus-Naur
Form syntax, which describes the syntax for tokens
that combine with each
other to create a valid top-level production. In this
case, the top-level
production is the query token. For details on how to
read this notation, see the
tutorial located at
http://braid.rad.jhu.edu/til/AboutBNF.html.
Text in italics represents a token and is not to be
typed into a query. Tokens
combine to create other tokens, with a fully formed
query resulting from a
query token. Text in bold, fixed-width font is part of
the query. Text in square
brackets is optional.
When a single or double non-alphabetic character
string is meant to be part of
a token, it is enclosed in double quotation marks. In
the query itself, only
strings and single-character constants are surrounded
by double quotation
marks. For example, the definition sum "("expr")"
means the string "sum"
followed by a left parenthesis, followed by whatever
text is a valid expr,
followed by a right parenthesis. The quotation marks
exist only to alert you of
the non-alphabetic character stringinthe.
The keywords in the tables below (represented with
bold, fixed-width text) are
shown using lowercase characters. However, these
keywords are
case-insensitive, and you can use either lowercase or
uppercase letters. Note
that this rule does not apply to the attributes
mentioned earlier in this appendix.
query Defined query : :=
select selectDeclarationList from
variableDeclarationList [whereClause]
.vertline.
select selectDeclarationList from
variableDeclarationList [whereClause][group
by identifierList][having expr]of
Explanation This is the top-level production that represents a
query. All queries must conform to one
of the two forms listed in the definition above. The
first form represents a filter query,
while the second form represents an aggregate query.
In an aggregate query, for each "alias: expr" in the
selectDeclarationList, one of
the following must be true: either the alias name
appears in the group by clause, or expr
is a valueFunction. This means that if the group by
clause is absent, every expr must be a
valueFunction.
Examples 1. This filter query returns the account number,
customer name, and balance for all
accounts with a negative balance:
select acct :a.acctNum, name:a.custName,
bal:a.balance
from a in BankModule.Account
where a.balance < 0
2. This aggregates query returns the account number
and total balance of all accounts that
have a combined balance of over $50,000.
select myName:a.custName, totalBal:sum(a.balance)
from a in BankModule.Account
group by myName
having totalBal > 50000
selectDeclarationList selectDeclarationList : :=
Defined alias ":" expr
.vertline.
selectDeclarationList "," alias ":" expr
Explanation This token represents the list of one or more data
items to be returned in each query result.
Each data item has an alias name (alias) and value
(expression).
Examples totalBal:sum(a.balance)
currBal:a.balance, alteredBal:a.balance -12.34
variableDeclarationList variableDeclarationList : :=
Defined identifier in pathExpression
Explanation This token represents the named variable (identifier)
that represents an individual BPO
from the BPO data type being queried (pathExpression).
Examples a in BankModule.Account
identifier Defined see "Explanation"
Explanation This token represents an arbitrary name (like a
variable name) for data item you wish to refer
to elsewhere.
Example a (as in select . . . from a in Account)
identifierList Defined identifierList ::= identifier ".vertline."
identifiert "," identifierList
Explanation This token occurs after the group by keyword. It lists
one or more aliases by which
intermediate results will be grouped.
Example a (as in select . . . from a in Account)
pathExpression Defined pathExpression : :=
identifier
.vertline.
pathIdentifier "." identifier
pathIdentifier "-> " identifier
Explanation This token refers to a BPO data type or data within
that data type. The dot operator (".") is
used to separate the module name from the BPO name or
to extract an element from within
a BPO. The arrow operator ("->") is a synonym for
the dot operator.
Examples BankModule.Account
BankModule.Account.balance
whereClause Defined whereClause : :=
where expr
Explanation This token expresses a condition that limits the
results the query returns. The expr
token must evaluate to either true or false.
Example where a.balance > 5000
where (current_time - a.timeCreated) > 20 * 1000
valueFunction Defined valueFunction : :=
sum "("expr")"
.vertline.
avg "("expr")"
.vertline.
count "("expr")"
.vertline.
count (*)
Explanation This token returns a numeric value that is based on a
series of BPO records that
have been grouped together. When the argument of the
function is expr, the function
works on the named expression. When the function is
"count (*)", this function returns
the number of BPO records that have been grouped
together.
Example The following query returns, for each customer, the
customer's name and the total of all that
customer's accounts.
select custName:a.custName, custTotal:sum(a.balance)
from a in BankModule::Account
group by custName
literal Defined literal : := integerConstant / characterConstant /
floatConstant / longConstant
/ stringConstant / current_time / true / false
Explanation This token represents some kind of unchanging value. A
characterConstant is a
single character, surrounded by double quotes. A
stringConstant is a series of
characters, surrounded by double quotes. The last
three possibilities,
current_time, true, and false , are not tokens but are
items to be entered,
as-is, into the query. They represents the current
time, a Boolean true value, and a
Boolean false value.
Examples 12345 (integer), "q" (character), 123.45 (float or
long), "navy van" (string),
current_time, true, false
expr Defined expr : :=
literal /
pathExpression /
valueFunction .vertline.
"("expr")".vertline.
"+" expr .vertline.
"-" expr .vertline.
expr "+" expr .vertline.
expr "-" expr .vertline.
expr "*" expr .vertline.
expr "/" expr .vertline.
expr "%" expr .vertline.
"!" expr .vertline.
not expr .vertline.
expr and expr .vertline.
expr or expr .vertline.
expr "=" expr .vertline.
expr "==" expr .vertline.
expr "!=" expr .vertline.
expr "<" expr .vertline.
expr ">" expr .vertline.
expr "<=" expr .vertline.
expr ">=" expr .vertline.
expr like expr .vertline.
expr at expr .vertline.
expr in expr .vertline.
Explanation This token defines how literals, path expressions, and
value functions can be
combined. Most of these combinations are obvious, but
several require some
explanation. to The "%" operator computes remainders;
for example, 7 %3 = 1. The "="
and "==" operators both check for the equality of
their two operands. In the case of logical
operators (for example, and and not), the argument or
arguments to these operators must
be logical, not numeric or string, values. The like,
at, and in operators are explained in
"Notes on Selected Operators and Attributes" on page
C-7.
Examples (a.balance * 1.17)
! (a.bpState at "Wait_for_signal")
totalBal - (a.balance / 2.0)
|
Same subclass Same class Consider this |
||||||||||