Analytic model and systems for business activity monitoring

Methods, systems, and computer program products for monitoring, aggregating, and correlating business events in real time and acting on the results with near zero latency, wherein each event is processed in the first order relative to the event density, are described herein. In an embodiment, the method operates by receiving historical values comprising keys and data fields at an analytic model. Rules associated with actions are applied to the historical values. Actions including updating data are executed pursuant to the rules, and then the method determines whether additional rules are to be applied; and performs actions associated with these additional rules until there are no remaining rules to apply. The method stores updated data in a database.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is generally directed to business intelligence systems, and more particularly directed to monitoring, aggregating, and correlating business events and acting on the results.

2. Background Art

Real time business intelligence is the process of delivering information about business operations without any latency.

Traditional business intelligence systems present historical information to users for analysis. Real time business intelligence compares current business events with historical patterns to detect problems or opportunities automatically. Organizations have been using business intelligence (BI) for many years to monitor, report on, analyze, and improve the performance of their business operations. Most BI applications to date have focused on managing strategic and tactical business plans and initiatives.

SYBASE™ BIZTRACKER™ is an example of a business activity monitoring solution that is currently available.

There are three main types of BI—strategic, tactical, and operational. Strategic BI is used for managing long-term business plans and goals. Executives and senior managers use the high-level business performance metrics (sometimes called key performance indicators, or KPIs) produced by strategic BI to track how well the business is doing against long-term business goals such as growing market share, reducing costs, and increasing revenues. As business initiatives such as marketing campaigns and new products are launched to help align actual business performance with planned performance, tactical BI analytics are employed by senior managers, business analysts, and line-of-business (LOB) managers to measure and optimize the performance of those initiatives. This tactical BI analyzes business operations over a period of days, weeks, or months.

To fully leverage the value of data, many companies use Business Intelligence (BI) solutions. Operational BI supports process optimization by pushing needed data to front-line analysts and managers in real time, supporting intra-day decisions. BI systems and solutions can dramatically improve efficiencies and decision-making across all facets of an enterprise.

To achieve operational BI, companies must overcome a number of challenges. They need a data warehousing and analytics solution that can extract real-time data from multiple sources on the fly. This solution also must transform the data into actionable business intelligence and make it accessible to those who need it. Also the solution must be able to handle huge volumes of data with many users making simultaneous complex ad hoc queries.

An example of an operational BI system is the SYBASE™ IQ™ product, which is an optimized analytics server designed to handle the challenges of operational BI. Operational BI is concerned with managing and optimizing daily business operations. It delivers the right information at the right time to the right business users to enable them to react rapidly to solve business problems and satisfy new business requirements. Fraud detection, risk management, customer segmentation, network management, and inventory management are examples of operational processes that can be improved using operational BI.

Operational BI improves the speed of reporting, analysis, and information delivery for faster operational decision-making and action-taking. The time for the business to react to operational issues or requirements is often called the action time. This action time may be a few seconds, minutes, or hours, depending on business needs. The action time requirement for fraud detection, for example, may be a few seconds, whereas intra-day inventory management may only require an action time of a few minutes or hours. Current operational BI systems are not real-time, because action times are based on what is right for any given business process, rather than on trying to reduce action as close to real-time as possible.

Business action time in operational BI processing has three components: data latency; reporting and analysis latency; and decision latency.

Data latency is the time it takes for the BI system to gather the data required for analyzing actionable operational events. Examples of events are the use of a credit card or ATM card, store purchase, manufacturing part request, stock trade, loan application, CSR request for customer data, database update, and so forth.

Reporting and Analysis latency is the time it takes for operational BI applications to report on and analyze the event data, and deliver the results to a business user or automated decision-making software for appropriate action.

Decision latency is the time it takes for the user, or decision-making software, to take action (if required) to solve a business issue or satisfy a business need identified by the original business event.

There are four main types of BI applications used to process and analyze actionable operational events and to help reduce data, analysis and decision latency: right-time data integration; operational BI reporting applications; decision automation software; and Decision automation software agents.

Right-time data integration applications collect and integrate information about actionable operational events for analysis. These events may originate from a variety of sources—for example, operational applications and databases, hardware devices (such as point-of-sale terminals or telecommunication switches), Web click streams, and so forth. The objective of right-time data integration is to reduce data latency.

Operational BI reporting applications produce reports about operational business transaction (BTx) data. In some applications these reports may be produced by accessing live operational data. In other cases, when a certain degree of data latency can be tolerated, the reports are produced using the information collected by right-time data integration applications. The objective of operational BI reporting is to reduce reporting latency.

Operational BI performance management (BI-PM) applications analyze the information collected by right-time data integration applications, produce business metrics about operational performance, and then deliver the results of the analyses to business users for decision-making and action-taking. The objective of operational BI-PM is to reduce analysis latency.

Decision automation software agents notify users about business issues and requirements that need urgent action. They also help business users evaluate BI-PM results and recommend actions that could help resolve business issues or satisfy business needs. In some cases, decision automation agents may take business action on behalf of business users. The objective of decision automation is to reduce decision latency.

What is needed are systems, methods, and computer program products that manage and optimize daily business operations by delivering information about business operations without any latency. What is further needed are real time business intelligence systems that compare current business events with historical patterns to automatically detect problems.

BRIEF SUMMARY OF THE INVENTION

The present invention includes system, method, and computer program product embodiments for modeling, monitoring, aggregating, and correlating business events in real time and acting on the results with near zero latency, wherein each event is processed in the first order relative to the event density. Methods and systems to model, monitor, aggregate and correlate business events in real time and act on the results with near zero latency while each event is processed relative to the event density are presented. The system, method, and computer program product embodiments disclosed herein perform near real-time business activity monitoring. In an embodiment, the invention operates by producing an analytic model, wherein the analytic model applies rules to business data and takes appropriate actions. In another embodiment of the present invention, business activities and data are aggregated and monitored in real-time. According to another embodiment of the invention, multiple analytic models are arranged or composed so that the output from one model provides input to another model. In this embodiment, a first analytic model feeds its output into a subsequent or downstream analytic model after the first model has processed rules and taken actions corresponding actions.

An embodiment of the present invention performs real-time business activity monitoring (BAM) by providing real-time access to critical business performance indicators. Unlike traditional real-time monitoring, the real-time BAM of the present invention draws information from multiple application systems and other internal and external sources, enabling a broader and richer view of business activities.

The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. Generally, the drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

DETAILED DESCRIPTION OF THE INVENTION

1. Overview of the Invention

The present invention is directed to systems, methods, and computer program products for monitoring, aggregating, and correlating business events in real time and acting on the results with near zero latency, wherein each event is processed in the first order relative to the event density. In an embodiment, the invention operates by producing an analytic model.

The analytic model represents a type of logical entity that has a state, intelligence, and behavior. The analytic meta-model defines the schema that applies to all analytic models. An instance of an analytic model is referred to as an analytic object.

2. Components of the Analytic Model

According to an embodiment, the basic components of an analytic model are fields, rules, timers, and actions. Fields define state, rules define intelligence, timers define event expiration, and actions define the activities performed by an analytic object when it detects a specified state. Behavior results from the interaction of state, intelligence, and actions. An analytic model associates rules and timers with actions such that action execution is governed by rule-based intelligence and timer expiration events.

According to an embodiment, an analytic object is uniquely identified by the values of its key fields. Many analytic objects may be instantiated from the same analytic model because an analytic object is implicitly created whenever a new set of key field values is presented. An analytic object is destroyed when its purge action executes.

An analytic model may be bound to a physical data store at which point it is referred to as a bound analytic model. Various qualities of service (data persistence, isolation level, transactionality) are implied through the choice of analytic model binding.

According to an embodiment, an analytic model represents its state as fields. Fields are conceptually similar to the member variables of a class. Each field in an analytic model has an associated data type. Field data types of embodiments of the present invention include, but are not limited to, those listed and described in Table 1.

TABLE 1Supported Field Data TypesField Data TypeData Type DescriptionStringRepresents a string value. Size limits maybe imposed by the binding.NumericRepresents a generic numeric value thatcan hold integer, double, and float values.BooleanRepresents a Boolean value, True or False.CalendarRepresents a date/time value.DurationRepresents a period of time. In anembodiment of the invention, duration is asix-dimensional space where thecoordinates designate the Gregorian year,day, hour, minute, and second.AttachmentRepresents an opaque blob of data.Attachment fields are opaque from theperspective of the model in which they aredeclared. In an embodiment of theinvention, the analytic model mayinterrogate attachments within actions or“cast” attachments to stronger data types.

In addition to a data type, each field in an analytic model also has one or more associated qualifiers. According to an embodiment of the invention, the analytic model supports the field qualifiers described in the table 2. Qualifiers of embodiments of the present invention include, but are not limited to, those listed and described in Table 2.

TABLE 2Field QualifiersField QualifierQualifier DescriptionBoundA field that with the bound qualifier must be bound toa data store. The fact that a field carries the boundqualifier does not imply that the field is maintained ina persistent and/or transactional data store. A field thatdoes not carry the bound qualifier is like a functionparameter passed on the stack in that it doesn't retainits value from one analytic object invocation to thenext. Only bound fields are available for viewing inthe Monitor and Dashboard GUIs.KeyThe collection of fields that carry the key qualifieruniquely identify the analytic object in the datastore. A field that carries the key qualifier mustalso carry the bound qualifier.AggregateA field that carries the aggregate qualifier may haveaggregate actions performed on it. Aggregate fieldscontain additional information beyond the presenteddata in order to maintain enough state information tocalculate the next aggregation. (For example, averagerequires a count be kept.) A field that carries theaggregate qualifier must be a numeric or durationfield and also carry the bound qualifier. Services donot have direct write access to aggregate fields, actionsmust be used to set the value.

According to an embodiment, the analytic model defines intelligence with rules, which are conditional expressions that are a function of field values. An analytic model may contain many rules and each rule may be associated with one or more actions. When an analytic object is invoked, it evaluates all of its rules and executes all of the actions associated with the rules conditions that evaluate to true.

In accordance with an embodiment of the present invention, each rule expression is assigned a prioritization value which defines the evaluation sequence for the rules and an overall execution sequence for actions. According to another embodiment, rules are put into groups and a user to may select rule priorities which in turn control the sequence in which the rules are evaluated. Rules with a higher prioritization are evaluated before rules with a lower prioritization and the associated actions are performed before the next sets of conditions are evaluated.

Actions associated with separate rules with the same prioritization are assumed to be independent of one another such that action execution sequence is not relevant as long as all the necessary actions execute in some order. If multiple actions are associated with the same rule, those actions will be executed in the sequence defined by the analytic model.

According to an embodiment of the invention, an analytic model may be used only to process rules and return results. In such a rules-only use case, there may be no monitoring or data persistence of any type.

According to an embodiment, the meta-analytic model supports the definition of timers. Timers have an associated timer type and duration. A timer type distinguishes timer definitions from one another. The timer duration specifies the period of time that must elapse before an alarm event occurs. An alarm event may be associated with one or more actions such that when the alarm event occurs, all the actions associated with the alarm event execute in the defined sequence. Note that an alarm event does not trigger a rule evaluation/action cycle because alarm events are “hard-wired” to actions. An analytic model may have many associated timer definitions. An analytic object may have many active timers. According to an embodiment of the present invention, an analytic object may have at most one active timer of a given type.

Active timers persist when the server is shut down. According to an embodiment of the present invention, when the server comes back up or restarts, all active timers, regardless the timer is past due during the service down time, or still active after the server down time, are all de-registered, then re-registered. The duration is a continuous running or elapsing of time. If the duration is interrupted by a server shut down, previous duration is no longer valid. An invalid duration makes the corresponding timers invalid.

According to an embodiment, when a server has re-started and is back up (i.e., online and on the network), all previous active timers are re-registered to cancel any invalid timers, and then all previous active timers are re-registered to allow monitored events to come through.

When a user un-deploys a monitor service through package, a warning is raised if there is any active action timer related to the monitor service running, and if the user chooses to un-deploy the monitor service, the related active action timers are terminated, according to an embodiment of the present invention.

When a user pauses a monitor service, a warning should be raised if there is any active action timer related to this monitor service running, if user still choose to pause the package, all active action timers should be persistent and terminated. When the monitor service is resumed, all previously persistent active action timers should be re-registered.

According to an embodiment, actions are activities performed by an analytic object when it detects a specified state. Actions may be associated with rules and with timer events. According to an embodiment of the present invention, the analytic meta-model supports the definition of the timer manipulation actions described in table 3.

Timer manipulation actions apply only to timer instances associated with the calling analytic object. Each of the timer manipulation actions is associated with a specific timer type. An analytic model may define many timer types, but since an analytic object can have at most one active timer of a given type, the timer type uniquely identifies a timer instance in an analytic object context.

The meta-model supports the definition of a purge action. A purge action removes the calling analytic object from the data store.

The meta-model supports the definition of an alert action that sends an alert message to a specified channel. The alert action definition includes the definition of an alert message that contains any or all of the fields in the analytic model as well as additional static information.

The meta-model supports the definition of an update action. An update action computes a value and assigns that value to a field. An update action definition specifies the expression that computes an update value and the target field to which that value should be assigned.

The meta-model supports the definition of an aggregation action. The aggregation action definition associates an aggregating operator with a field and optionally a time window.

According to an embodiment, an aggregating operator effectively operates on a collection of field values to produce a new field value (an aggregate value). These collections are typically obtained a single event at a time and a new calculation is made each time a new value is introduced. The goal is to calculate the aggregation with an O(N) algorithm with N being the event density.

In an analytics environment an analyst may want to apply an aggregating operator to a collection of field values that were generated over a period of time (a time window) to obtain a sum, average, rate, or other aggregate value for the data obtained within the window.

An aggregating operator associated with a fixed window “starts over” when the window duration expires whereas a sliding window moves smoothly over a collection of data adding new values as the arrive and dropping old values as the window moves past them. The rate operator is exceptional in that it uses a sliding window approximation.

While aggregations can be performed over a time window they don't require a time window to be useful. For example, one may want to sum various values in events tied together by some transaction or batch identifier. For the sake of a unified perspective, one could think of the time window as infinite in this case.

3.0 Structural and Operational Embodiments

This section describes a method and system for monitoring, aggregating, and correlating business events in real time and acting on the results with near zero latency according to embodiments of the invention as illustrated inFIGS. 1-7.

FIG. 1illustrates business event stream processing100, according to an embodiment of the invention.115,120and110all are part of an analytic model. The States of110is the same as fields inFIG. 2as described below. Event105is passed from a monitor service to rule service115via protocol113. Protocol113can be any communication protocol. Rule service115applies rules to the data contained within event105. After rules are applied to event105data, indicators identifying actions to be performed are passed to action engine120via protocol117. Protocol117may be the same or different as protocol113and can be any communications protocol. Actions are performed by action engine120. According to an embodiment of the invention, actions performed by action engine120can include one or more of updating data, business data/event aggregation, sending alert emails, executing Java scripts, running SQL queries, timer control, and purging of business data. After actions are performed, any updated data is sent back to monitor service110via feedback loop170. After monitor service110determines if business data has changed as a result of actions performed by action engine120, the changed data180is sent to rules engine115, where the process repeats and invokes a new set of rules to be applied. New business events105can be subsequently sent to rules engine115as they arise (i.e., new events trigger the business event stream processing).

Other configurations of the business event processing components depicted inFIG. 1will be apparent to persons skilled in the relevant art(s).

According to an embodiment, operation of the business event processing components depicted inFIG. 1is depicted inFIG. 2, which shall now be described.FIG. 2illustrates the interaction200between fields210in the monitor service and fields in the analytic model222, according to an embodiment of the invention.

Monitor service210can call multiple analytic models, such as analytic model222. Keys and other fields are passed into analytic model222via call(s)213with monitor service fields210.

Rules are applied in rules engine215to data passed into analytic model222. Rules in rules engine215are built directly into analytic model222to recognize threshold boundaries, itemize key performance indicator ranges, and detect conditions requiring additional actions such as sending alerts225.

Analytic model222defines intelligence with rules in rules engine215. According to an embodiment of the invention, rules in rules engine215are conditional expressions that are a function of field values passed into analytic model222via calls213from monitor service210.

Once logical analytic model222has been created, model222must be bound to a monitor database245before it can be useful. According to an embodiment, of the present invention, monitor database245can be a physical data store used to store persistent data. According to an embodiment of the invention, an analytic model editor allows users to associate fields in analytic model222with columns in the monitor database245. Analytic models and their associated bindings are accessible through a monitor service.

An analytic model, such as analytic model222, may contain many rules within rules engine215and each rule may be associated with one or more actions220. When analytic object224is invoked, it evaluates all of its rules in rules engine215and executes all of the actions220associated with the rules conditions that evaluate to true.

According to an embodiment of the invention, each rule expression in rule set in rules engine215is assigned a prioritization value which defines the evaluation sequence for the rules in rules engine215and an overall execution sequence for actions220. Rules in rule set within rules engine215with a higher prioritization are evaluated before rules with a lower prioritization and the associated actions220are performed before the next set of rules in rules engine215are evaluated after a repeat application265of the rules.

Actions220associated with separate rules in rule set within rules engine215with the same prioritization are assumed to be independent of one another such that action execution sequence is not relevant as long as all the necessary actions220execute in some order. If multiple actions220are associated with the same rule in rule set within rules engine215, those actions will be executed in the sequence defined by analytic model222.

According to an embodiment of the invention, an alarm event or alert225may be associated with one or more actions220such that when alert225occurs, all actions220associated with alert225execute in a defined sequence. For example, alert225does not trigger a rule evaluation/action cycle265because alert events225are “hard-wired” specific actions within action set220.

According to an embodiment of the invention, action group220contains an ordered collection of actions. Action group220preserves action execution sequence and is re-usable by many rules in rule set within rules engine215. For example, if two rules in rule set within rules engine215select the same action group220; then action group220would only be executed once. This allows rules to be created in an independent fashion without building complicated logic.

Actions within action group220are the activities performed by analytic object224when it detects a specified state. Actions220may be associated with rules within rules engine215and with timer events. Analytic model222may have many associated timer definitions, according to an embodiment of the invention. Analytic object224may have many active timers but at most one active timer of a given type.

Actions within action group220may include structure query language (SQL) actions. SQL actions define a SQL command to operate on a database. SQL actions support any SQL compound statement and may place into the statement the value of any defined fields217in analytic model222.

Actions within action group220may also include Java Script actions. A Java Script action defines a script that can perform custom actions required by users. Java scripts may access analytic object224fields217via a provided class and save new data to fields217which will be stored in analytic object224. Access to additionally stored data270useful for aggregation by aggregating operator267will also be available to the Java scripts.

According to an embodiment of the invention, aggregation action associates an aggregating operator267with a field and optionally a time window. Aggregating operator267operates on a collection of field values provided to aggregating action via feedback loop270to produce a new field value (an aggregate value). These collections are typically obtained a single event at a time and a new calculation is made each time a new value is introduced. The aggregation is calculated with an O(N) algorithm, wherein N is the event density, and wherein aggregation is kept up to date regardless of the number of events coming into the system, in accordance with an embodiment of the invention. According to an embodiment, each calculation is O(1), such that for each event that triggers an aggregation, the time required to aggregate does not depend on the event density.

According to an embodiment of the invention, aggregating operator267may be applied by a user to a collection of field values provided via feedback loop270that were generated over a period of time (a time window) to obtain a sum, average, rate, or other aggregate value for the feedback loop data270obtained within the window.

According to an embodiment of the invention, aggregating operator267is associated with a fixed window and “starts over” when the window duration expires. For example, a sliding window moves smoothly over a collection of data provided via feedback loop270, adding new values as they arrive and dropping old values as the window moves past them. According to another embodiment, a running, self-correcting approximation for sliding windows is used, which maintains O(1) aggregation calculation and approximates the dropping of old values. While aggregations can be performed by aggregating operator267over a time window, they do not require a time window to be useful. For example, in an embodiment of the invention, a user may sum various values in events tied together by some transaction or batch identifier. The time window can be infinite, according to this embodiment.

According to an embodiment of the invention, an analytic model such as222may be used only to process rules in rules engine215and return results247. For example, there may be no monitoring by monitor service210or persistence of any type, with no values stored in monitor database245.

Analytic model binding specifies the physical data store245associated with analytic model222. Only the fields carrying the bound qualifier in bound analytic model222are stored in the defined monitor database245at runtime, and the fields that do not carry the bound qualifier are not stored in defined monitor database245. During binding, the connection information needed to connect to physical data store245is defined. For example, this could be a database connection string or a universal resource locator (URL). The physical locations of bound fields within physical data store245are also defined during binding. For example, this could include associating a column of a database table with a field from fields217in analytic model222. This binding provides access to any JDBC compliant database. According to an embodiment of the invention, columns in the user defined database table in database245are associated with fields217in analytic model222.

FIG. 3illustrates the interaction via flow relationship300of multiple analytic models according to an embodiment of the invention.FIG. 3depicts how multiple analytic models, such as analytic models322,312, and314, reference each other directly to form an analytic network316, according to an embodiment of the invention.

Analytic models such as322,312, and314, are of limited use in isolation; they must be brought together into flow relationship300to be truly useful. According to an embodiment of the invention, a service editor supports the definition of control flows350that join bound analytic models such as322,312, and314together in a procedural manner. Since a single analytic model such as322can be bound to only one data store345, control flows350are essential if the analysis requires rules that depend on data from several data stores.

Analytic control flows350are scoped by the service operation in which they are defined. According to an embodiment of the invention, control flows350are not re-usable by other operations or outside the service. Bound analytic models such as322,312, and314, do not interact with each other directly; instead, the interaction is controlled by the service operation. The service operation interacts with a set of bound analytic models as322,312, and314in a specified order; such that any field in a previous bound analytic model is available as input to the next. Fields may supply data looked up in remote database345, be a calculated aggregation, or a state determined by rules.

According to an embodiment of the invention, keys and other fields313are passed into analytic models322and314within analytic network316by calls from monitor service310. Keys and fields313are passed into analytic models322and314from monitor service305by calls from sources such as queue monitor305, published event source305, and monitored source305.

Analytic models322,314, and312reference each other directly by passing field sets via control flows350to each other, according to an embodiment of the invention. For example, analytic model322passes field set350to a subsequent analytic model312.

With continued reference toFIG. 2, applying rules within rules engine215to data, analytic model312performs actions. In accordance with an embodiment of the invention, analytic model312performs actions such as alert generation325.

FIG. 4illustrates interactions400between multiple analytic models, according to an embodiment of the invention. According to an embodiment of the invention, monitor service input fields, such as monitor service input/output411, interact with multiple analytic models, such as analytic models422,412, and414. Monitor service input/output411includes input fields405to define a specific analytic object instance.

Input fields405are passed into analytic models422and412via service calls413from a monitor service. Rules and actions424are part of analytic model422and are comprised of rules415and actions420. Actions420may include activities425to be performed pursuant to rules415.

Within analytic model422, multiple rules415trigger actions420that further update analytic model422and perform other activities425. In an embodiment of the invention, other activities425may include alert generation. Alerts may be in the form of emails, according to an embodiment of the invention. Any field set450from one analytic object such as analytic model422is then available to subsequent analytic objects such as analytic models412and414, as determined by the monitor service.

An analytic model such as analytic model422is the definition, and an analytic object is an instance of an analytic model. For example, analytic model422can be likened to a database table and an analytic object can be thought of as a row the database table. When multiple analytic models, such as412and422, are updated by a single service call413, they are automatically correlated, maintaining the logical relationship between the analytic objects. Monitor service410passes field values417to analytic model422, analytic model422looks up the object based on field values417and then, a specific analytic object is invoked. Each analytic object instance may be correlated to many instances of several other analytic models.

According to an embodiment of the invention a monitor graphical user interface (GUI) may allow a user to “drill down” from one bound analytic model, such as422to all the various corresponding bound analytic models, such as412and414, contained in another analytic model. For example, if analytic model422represents service call413and analytic model412represents aggregated data470, a user can use the monitor GUI to drill down from an aggregation to view all the events that generated aggregation467. The Monitor GUI is a web application that provides an interactive, tabular view of all the various bound analytic models, such as422,412, and414. For example the monitor GUI allows a user to drill down into analytic model422in various ways such as viewing the attachments associated with model422and displaying a list of correlated analytic objects belonging to a different analytic model such as analytic model412.

According to an embodiment of the invention, the monitor GUI configures colors and icons to analytic objects to aid in visualization. A user may choose a field in a bound analytic model such as422and assign colors and icons to various values of fields410. All data rows with that value are displayed in the chosen color and the icon appears in the chosen field column next to the value itself. This configuration data is stored by user id in a persistent monitor database (such as245depicted inFIG. 2or345depicted inFIG. 3). The monitor GUI also provides the interface for all operational controls such as manual purge, and the modification of various system configuration variables.

Service output fields447may be returned as a result of any field set410from any analytic model, such as414.

According to an embodiment, field set such as field set410is passed from one analytic model to another. For example, the monitor service coordinates providing output450from analytic model422as input to analytic model412. Similarly, the monitor service may coordinate tying output450from analytic model412to input for analytic model414.

According to an embodiment of the present invention, analytic models422,412, and414reference each other directly, to form analytic network416.

FIG. 5is a flowchart500illustrating steps by which near real-time business activity monitoring is performed, in accordance with an embodiment of the present invention.

More particularly, flowchart500illustrates the steps by which analytic model receives keys and other fields, applies rules to the data, and performs actions. Flowchart500is described with reference to the embodiment ofFIG. 2. However, flowchart500is not limited to that example embodiment. Note that the steps in the flowchart do not necessarily have to occur in the order shown.

The method begins at step505where keys and other field values are passed into the analytic model222.

In step510, historical values are found by analytic model222based on the keys and other field values, and then values are passed to analytic object224via calls513.

In step515, rules are applied to data values passed via calls513. Analytic model222contains many rules that are applied in step515, wherein each rule may be associated with one or more actions to be performed in step520. When analytic object224is invoked, it evaluates all of its rules in step515and executes all of the actions in step520that are associated with the rule conditions that evaluate to true. In step515, rules from a rule set within rules engine215with a higher prioritization are evaluated before rules with a lower prioritization and the associated actions are performed in step520before the next set of rules are evaluated after an application of the next set of rules in a subsequent performance of step515via conditional step560(described below).

In step520, actions are performed pursuant to rules applied in step515. Analytic data fields517are also updated in this step. According to an embodiment of the invention, if multiple actions are associated with the same rule in applied in step515, those actions will be executed in the sequence defined by analytic model222.

In step525, other actions are performed, including alert generation. In this step, alerts may be generated in the form of emails, according to an embodiment of the invention.

In step560, an evaluation is made regarding whether more rules are to be applied, based on the data updated in step520and actions performed in step525.

If it is determined that more rules need to be applied, then control returns to step515. Accordingly, the process described above involving steps515,520, and525is repeated until there are no more rules to apply. The reiterations of steps515,520, and525stop when there are no additional rules remaining to be applied. The same rules are not repeatedly applied, rather rules are applied in the order of their priority, wherein a set of lower-priority rules being applied after higher priority rules have been applied until there no unapplied rules.

If it is determined in step560that there are no more rules to apply, then step545is performed. In step545, new values are stored in the monitor database.

If it is determined in step560that more rules are to be applied based on updated data performed in step520, and steps515-560are repeated. This process is repeated until there are no more rules to apply.

If it is determined in step560that no other rules are to be applied, new values are stored in the monitor database in step545, and the process ends in step547.

FIG. 6is a flowchart600illustrating steps by which near real-time business activity monitoring is performed, in accordance with an embodiment of the present invention. AlthoughFIG. 6depicts two analytic models being chained together, more than two analytic models can be chained together, in accordance with an embodiment of the present invention.

More particularly, flowchart600illustrates the steps by which an analytic model receives keys and other fields, applies rules to the data, and performs actions and then inputs values into another analytic model. Flowchart600is described with reference to the embodiment ofFIG. 2. However, flowchart600is not limited to that example embodiment. Note that the steps in the flowchart do not necessarily have to occur in the order shown.

The method begins at step605where keys and other field values are passed into the analytic model222.

In step610, historical values are found by analytic model222based on the keys and other field values, and then values are passed to analytic object224via calls613.

In step615, rules are applied to data values that were passed to analytic model224via calls613in step610. Analytic model222contains many rules that are applied in step615, wherein each rule may be associated with one or more actions to be performed in step620. When analytic object224is invoked, it evaluates all of its rules in step615and executes all of the actions in step620that are associated with the rule conditions that evaluate to true. In step615, rules in rule set within rules engine215with a higher prioritization are evaluated before rules with a lower prioritization and the associated actions are performed in step620before the next set of rules are evaluated after a repeat application of the rules in step675.

In step620, actions are performed pursuant to rules applied in step615. Data fields617are also updated in this step. According to an embodiment of the invention, if multiple actions are associated with the same rule in applied in step615, those actions will be executed in the sequence defined by analytic model222.

In step625, other actions are performed, including alert generation. In this step, alerts may be generated in the form of emails, according to an embodiment of the invention.

In step660, an evaluation is made regarding whether more rules are to be applied, based on the data updated in step620and actions performed in step625.

If it is determined that more rules need to be applied, then control returns to step615. Accordingly, the process described above involving steps615,620, and625is repeated until there are no more rules to apply.

If it is determined in step660that there are no more rules to apply, then step645is performed. In step645, new values are stored in the monitor database in step645.

In step653, a determination is made regarding whether the values stored in step645are to be input into another analytic model.

If it is determined that values stored in step645need to be input into another analytic model, then control is passed to step655via call650. Accordingly, the process described below involving steps657,675,680, and685is repeated until there are no more rules to apply.

If it is determined in step660that values stored in step645do not need to be input into another analytic model, then control is passed to step647, data is returned, and the process ends.

In step657, historical values are found by the second analytic model based on the keys and other field values, and the values are passed to analytic object224.

In step675, rules are applied to data values663. The second analytic model contains rules that are applied in step675, wherein each rule may be associated with one or more actions to be performed in step680.

When analytic object within the second analytic model is invoked, it evaluates all of its rules in step675and executes all of the actions in step680that are associated with the rule conditions that evaluate to true. In step675, rules in the second analytic model's rule set with a higher prioritization are evaluated before rules with a lower prioritization and the associated actions are performed in step680before the next set of rules are evaluated after a repeat application of the rules in step675.

In step680, actions are performed pursuant to rules applied in step675. Data677is also updated in this step. According to an embodiment of the invention, if multiple actions are associated with the same rule in applied in step675, those actions will be executed in the sequence defined by the second analytic model.

In step685, other actions are performed, including alert generation. In this step, alerts may be generated in the form of emails, according to an embodiment of the invention.

In step690, an evaluation is made regarding whether more rules are to be applied, based on the data updated in step680and actions performed in step685.

If it is determined that more rules need to be applied, then control returns to step675. Accordingly, the process described above involving steps675,680, and685is repeated until there are no more rules to apply.

If it is determined in step690that there are no more rules to apply, then the new values are returned in step647, and the process ends.

4. Example Computer Implementation

In an embodiment of the present invention, the system and components of the present invention described herein are implemented using well known computers, such as a computer702shown inFIG. 7. The computer702can be any commercially available and well known computer capable of performing the functions described herein, such as computers available from International Business Machines, Apple, Sun, HP, Dell, Compaq, Digital, Cray, etc.

The computer702includes one or more processors (also called central processing units, or CPUs), such as a processor706. The processor706is connected to a communication bus704.

The computer702also includes a main or primary memory708, such as random access memory (RAM). The primary memory708has stored therein control logic728A (computer software), and data.

The computer702also includes one or more secondary storage devices710. The secondary storage devices710include, for example, a hard disk drive712and/or a removable storage device or drive714. The removable storage drive714represents a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup, etc.

The removable storage drive714interacts with a removable storage unit716. The removable storage unit716includes a computer useable or readable storage medium724having stored therein computer software728B (control logic) and/or data. Removable storage unit716represents a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, memory stick, or any other computer data storage device. The removable storage drive714reads from and/or writes to the removable storage unit716in a well known manner.

The computer702further includes a communication or network interface718. The network interface718enables the computer702to communicate with remote devices. For example, the network interface718allows the computer702to communicate over communication networks or mediums724B (representing a form of a computer useable or readable medium), such as LANs, WANs, the Internet, etc. The network interface718may interface with remote sites or networks via wired or wireless connections.

Control logic728C may be transmitted to and from the computer702via the communication medium724B. More particularly, the computer702may receive and transmit carrier waves (electromagnetic signals) modulated with control logic730via the communication medium724B.

Any apparatus or manufacture comprising a computer useable or readable medium having control logic (software) stored therein is referred to herein as a computer program product or program storage device. This includes, but is not limited to, the computer702, the main memory708, the hard disk712, and the removable storage unit716. Such computer program products, having control logic stored therein that, when executed by one or more data processing devices, cause such data processing devices to operate as described herein, represent embodiments of the invention.

The invention can work with software, hardware, and/or operating system implementations other than those described herein. Any software, hardware, and operating system implementations suitable for performing the functions described herein can be used.