Reporting results of processing of continuous event streams

BACKGROUND OF THE DISCLOSURE

1. Technical Field

The present disclosure relates generally to processing of continuous event streams, and more specifically to reporting results of processing of continuous event streams.

2. Related Art

In traditional database systems, data is stored in one or more databases usually in the form of tables. The stored data is then queried and manipulated using a data management language such as SQL (structured query language). For example, a SQL query may be defined and executed to identify relevant data from the data stored in the database. A SQL query is thus executed on a finite set of data stored in the database. Further, when a SQL query is executed, it is executed once on the finite data set and produces a finite static result. Databases are thus best equipped to run queries over finite stored data sets.

A number of modern applications and systems however generate data in the form of continuous data or event streams instead of a finite data set. Examples of such applications include but are not limited to sensor data applications, financial tickers, network performance measuring tools (e.g. network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like. For example, a temperature sensor may be configured to send out temperature readings.

Processing of continuous event streams necessarily entails specifying a moving time window along with selection criteria in a query. The selection criteria is applied against data values corresponding to time instances in a specific duration determined by the moving time window to form the results corresponding to that duration. The results are formed at continuous discrete instances as the specific duration is changed according to the moving time window specified in the query.

For example, the moving time window may be specified as (3 minutes width and 2 minutes slide starting at t=3), implying that the results may need to be formed for the events corresponding to the respective durations 0-3, 2-5, 4-7, 6-9, etc. Continuous Query Language (CQL) is an example of a language used for specifying queries for continuous event streams.

It is often desirable that the results of processing of continuous event streams be reported to one or more users. Reporting generally implies making available the corresponding information of interest, based on the results.

Aspects of the present disclosure provide for reporting results of processing of continuous event streams.

BRIEF DESCRIPTION OF THE DRAWINGS

Example embodiments of the present disclosure will be described with reference to the accompanying drawings briefly described below.

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating an example environment in which several aspects of the present invention can be implemented.

<figref idref="DRAWINGS">FIG. 2</figref> is a flow chart illustrating the manner in which results of processing of continuous event streams is reported according to an aspect of the present disclosure.

<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram illustrating the details of an alert server in an embodiment.

<figref idref="DRAWINGS">FIGS. 4A-4B</figref> together illustrates the manner in which a user is enabled to specify the details of an alert definition in one embodiment.

<figref idref="DRAWINGS">FIG. 5</figref> depicts the manner in which user alerts based on results of processing of continuous event streams is generated in one embodiment.

<figref idref="DRAWINGS">FIG. 6</figref> is a block diagram illustrating the details of a digital processing system in which various aspects of the present disclosure are operative by execution of appropriate executable modules.

In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.

DETAILED DESCRIPTION OF THE EMBODIMENTS OF THE DISCLOSURE

1. Overview

An aspect of the present disclosure facilitates reporting results of processing of continuous event streams. In one embodiment, a matching condition indicating a pattern of interest as a part of an alert definition in relation to a set of continuous event streams is received, with the occurrences of the pattern of interest being desirable to be reported as corresponding alert instances. Also, a suppression condition associated with the pattern of interest is received, with the suppression condition indicating the specific occurrences of the pattern of interest that are not to be reported as corresponding alert instances. Accordingly, a sequence of occurrences of the pattern of interest is determined in the set of continuous event streams. For each occurrence in the sequence of occurrences, an alert instance corresponding to the occurrence is generated only if the suppression condition is not satisfied for the occurrence.

In one embodiment, the determination of the sequence of occurrences (noted above) is performed by obtaining a sequence of results of execution of a continuous query on the set of continuous event streams. The continuous query may be specified according to CQL (continuous query language). The continuous query indicates a selection criteria corresponding to the matching condition (specified in the alert definition) and a moving time window. Each of the sequence of results is obtained based on data values of the set of continuous event streams in a corresponding duration determined by the moving time window. The sequence of results is identified as corresponding to the sequence of occurrences of the pattern of interest in the set of continuous event streams. Accordingly, the alert instances corresponding to each result is generated only if the suppression condition is not satisfied for the result. On the other hand, the alert instance corresponding to a result is skipped if the suppression condition is satisfied for the result.

According to another aspect of the present disclosure, the suppression condition (in the alert definition) specifies a timing pattern for prior alert instances and a suppression duration. Accordingly, the alert instance for an occurrence (of the pattern of interest) is skipped if the timing of the alert instances prior to the occurrence satisfies the timing pattern and the timing of the occurrence is within the suppression duration.

In one embodiment, the timing pattern is specified in the form of a threshold number (e.g., in the form of absolute number, average, etc.) of prior alert instances in a prior duration, wherein subsequent alert instances are suppressed for the suppression duration upon generation of the threshold number of prior alert instances in the prior duration thereby avoiding repetition of the alert instances beyond the threshold number in a duration of a sum of the prior duration and the suppression duration.

According to one more aspect of the present disclosure, the alert definition indicates that alert instances are to be sent to a first user and a second user, while the suppression condition is specified associated with the second user but not the first user. Accordingly, for each occurrence (of the pattern of interest) determined within the suppression duration, the corresponding alert instance is sent to the first user, but is skipped for the second user.

According to yet another aspect of the present disclosure, the alert definition indicates that alert instances are to be sent to a third user also. Accordingly, generating sends the alert instance to the third user at a first time instance. A second suppression duration is received at a second time instance after the first time instance. Accordingly, for each occurrence (of the pattern of interest) determined within the second suppression duration after the second time instance, the corresponding alert instance is sent to the first user but skipped for the third user.

Several aspects of the present disclosure are described below with reference to examples for illustration. However, one skilled in the relevant art will recognize that the disclosure can be practiced without one or more of the specific details or with other methods, components, materials and so forth. In other instances, well-known structures, materials, or operations are not shown in detail to avoid obscuring the features of the disclosure. Furthermore, the features/aspects described can be practiced in various combinations, though only some of the combinations are described herein for conciseness.

2. Example Environment

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram illustrating an example environment in which several aspects of the present invention can be implemented. The block diagram is shown with network <b>110</b>, data store <b>130</b>, alert server <b>150</b>, event sources <b>160</b>A-<b>160</b>B (generating continuous event streams <b>165</b>A and <b>165</b>B respectively), and client systems <b>180</b>A-<b>180</b>X.

Merely for illustration, only representative number/type of systems is shown in the Figure. Many environments may contain many more clusters and/or systems, both in number and type, depending on the purpose for which the environment is designed. Each system of <figref idref="DRAWINGS">FIG. 1</figref> is described below in further detail.

Network <b>110</b> provides connectivity between alert server <b>150</b> and client systems <b>180</b>A-<b>180</b>X. Network <b>110</b> may be implemented using protocols such as Transmission Control Protocol (TCP) and/or Internet Protocol (IP) well known in the relevant arts. In general, in TCP/IP environments, an IP packet is used as a basic unit of transport, with the source address being set to the IP address assigned to the source system from which the packet originates and the destination address set to the IP address of the destination system to which the packet is to be eventually delivered.

A (IP) packet (or hereafter a “network packet”) is said to be directed to a destination system when the destination IP address of the packet is set to the (IP) address of the destination system, such that the packet is eventually delivered to the destination system by network <b>110</b>. When the packet contains content such as port numbers, which specifies the destination application, the packet may be said to be directed to such application as well. The destination system may be required to keep the corresponding port numbers available/open, and process the packets with the corresponding destination ports. Network <b>110</b> may be implemented using any combination of wire-based or wireless mediums.

Data store <b>130</b> represents a non-volatile storage facilitating storage and retrieval of a collection of data (for example, intermediate results forming the basis of sending the alert instances) by alert server <b>150</b>. Data store <b>130</b> may be implemented using relational database technologies and therefore provide storage and retrieval of data using structured queries such as SQL (Structured Query Language). Alternatively, data store <b>130</b> may be implemented as a file store providing storage and retrieval of data in the form of one or more files organized as one or more directories, as is well known in the relevant arts.

Each of event sources <b>160</b>A-<b>160</b>B represents a set of systems/devices, which together generate data values continuously as a respective event/data stream. Each event/data stream may be generated by one of more devices/systems contained in the corresponding source. As an illustration, in a manufacturing environment, event source <b>160</b>A may include a thermometer that detects the temperature of an apparatus (not shown) every 5 minutes. The temperature readings of the thermometer may be sent to alert server <b>150</b> via path <b>165</b>A as corresponding data/event stream. It may be appreciated that sources <b>160</b>A-<b>160</b>B may send the stream of data values to alert server <b>150</b> using an appropriate network (not shown).

Alert server <b>150</b> represents a system such as a web/application server that processes continuous queries in relation to the continuous event streams <b>165</b>A-<b>165</b>B and thereafter reports the results of processing to one or more users/recipients (for example, using client systems <b>180</b>A-<b>180</b>X). In one embodiment, alert server <b>150</b> generates (creates and sends) user alerts based on the results of processing of such continuous event streams (<b>165</b>A-<b>165</b>B). An alert refers to notification of some pattern (either expected or anomalous) that a recipient may wish to know about.

As such, alert server <b>150</b> receives (from one of client systems <b>180</b>A-<b>180</b>X) or is configured with alert definitions in relation to continuous event streams (such as <b>165</b>A and <b>165</b>B). In general, an alert type/definition specifies a condition in relation to one or more continuous event streams, upon the satisfaction of which an alert (instance) is to be generated (by alert server <b>150</b>). For example, in the manufacturing environment noted above, the condition may be “when the average temperature of the apparatus (as provided by the thermometer) in a duration is higher than a threshold”.

Alert server <b>150</b> accordingly processes the data values (temperatures) received in the specified continuous event stream (<b>165</b>A), identifies the one or more occurrences of the user specified condition (average temperature higher than a threshold) based on the results (average temperature) of processing, and accordingly generates alert instances corresponding to the identified occurrences. The generation of alerts entails sending of the alerts to one or more recipients (for example, using client systems <b>180</b>A-<b>180</b>X) as specified in the alert definition. It should be noted that alert server <b>150</b> may generate (and also send) multiple alerts instances (each instance containing corresponding data) of the same alert type/definition at different time instances corresponding to the instances at which the condition specified in the alert definition is satisfied.

Each of client systems <b>110</b>A-<b>110</b>X represents a system such as a personal computer, workstation, mobile station, mobile phones, computing tablets, etc., used by users to generate (client) requests for reporting the results of processing of continuous event streams (such as <b>165</b>A and <b>165</b>B). In one embodiment, the client requests include alert definitions according to which alerts server <b>150</b> is required to generate alerts reporting the results of processing of continuous event streams. The client requests specifying the alert definitions may be generated using appropriate user interfaces. The alert definitions may indicate the specific client systems (<b>180</b>A-<b>180</b>X) to which the alerts are to be sent.

In a prior approach, all alert instances may be sent to all recipients as specified in the alert definitions. However, it may be desirable to limit the number of alert instances sent to specific recipients. For example, the number of alert instances sent to a manager may need to be limited, while all the alert instances may need to be sent to a system administrator. In general, it may be desirable that users be provided more control with respect to alert instances.

Alert server <b>150</b>, extended according to several aspects of the present disclosure, facilitates reporting results of processing of continuous event streams while addressing at least some of the above noted drawbacks/requirements, as described below with examples.

3. Reporting Results of Processing

<figref idref="DRAWINGS">FIG. 2</figref> is a flow chart illustrating the manner in which results of processing of continuous event streams is reported according to an aspect of the present disclosure. The flowchart is described with respect to the blocks of <figref idref="DRAWINGS">FIG. 1</figref>, and with respect to alert server <b>150</b> in particular, merely for illustration. However, the features can be implemented in other systems and environments also without departing from the scope and spirit of various aspects of the present invention, as will be apparent to one skilled in the relevant arts by reading the disclosure provided herein.

In addition, some of the steps may be performed in a different sequence than that depicted below, as suited to the specific environment, as will be apparent to one skilled in the relevant arts. Many of such implementations are contemplated to be covered by several aspects of the present disclosure. The flow chart begins in step <b>201</b>, in which control immediately passes to step <b>210</b>.

In step <b>210</b>, alert server <b>150</b> receives a matching condition indicating a pattern of interest in relation to one or more continuous event streams. In other words, the matching condition represents a situation, the occurrences of which may be desirable to be reported as corresponding alerts. The matching condition may be received as part of an alert definition/client request from one of client systems <b>180</b>A-<b>180</b>X.

In step <b>230</b>, alert server <b>150</b> receives a suppression condition associated with the pattern of interest. A suppression condition specifies the situations, the occurrences of which are not to be reported as alerts. The suppression condition may be received along with the matching condition (as part of the alert definition) or later during operation.

In step <b>250</b>, alert server <b>150</b> executes a continuous query on the specified set of event streams, to identify a sequence of occurrences of the pattern of interest. The selection criteria of the continuous query correspond to the received matching condition such that the results of execution of the query correspond to the occurrences of the pattern of interest in the event streams.

It may be readily appreciated that each occurrence may correspond to single duration as determined by the moving time window. The manner in which each occurrence is processed, is described below. The query may be formed according to languages such as Continuous Query Language (CQL), as is well known in the relevant arts.

In step <b>270</b>, alert server <b>150</b> checks whether the suppression condition is satisfied for a next occurrence in the sequence. In a scenario that the suppression condition is satisfied, the alert is skipped and alert server <b>150</b> processes the next occurrence in the sequence (waiting for such occurrence, if required). Control passes to step <b>280</b> if the suppression condition is not satisfied for the next occurrence.

In step <b>280</b>, alert server <b>150</b> generates an alert corresponding to the next occurrence. As noted above, the generation of an alert entails creating the alert (based on the results of processing of the continuous query) and sending (or otherwise making available) the alert to one or more users/recipients (for example, using client systems <b>180</b>A-<b>180</b>X). Control then passes to step <b>270</b>, and the corresponding steps of the flowchart may be repeated. The flowchart of <figref idref="DRAWINGS">FIG. 2</figref> is depicted as being an infinite loop in view of the event streams having the property of being continuous.

Furthermore, as may be appreciated, the operation of step <b>250</b> continues in parallel to steps <b>270</b>/<b>280</b> such that the occurrence of the pattern of interest continues to be identified by step <b>250</b>, while the occurrences are processed in accordance with steps <b>270</b>/<b>280</b>.

By facilitating the users to specify desired combinations of matching and suppression conditions, the users are provided more control over receipt of user alerts based on results of processing of continuous event streams.

The description is continued with respect to an example implementation of alert server <b>150</b> in one embodiment.

4. Alert Server

<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram illustrating the details of alert server <b>150</b> in an embodiment. The block diagram is shown with request manager <b>310</b>, configuration data <b>320</b>, query processor <b>330</b>, queue <b>340</b>, and alert generator <b>350</b>. Each block is described in detail below.

Request manager <b>310</b> receives client requests specifying alert definitions from one of client systems <b>180</b>A-<b>180</b>X (via path <b>115</b>). Each alert definition may specify the details of the matching condition (pattern of interest), the associated suppression condition (if any), the set of continuous event streams (assumed to be only <b>165</b>A, for illustration), and a set of users/recipients to whom the alerts are to be sent. As noted above, the suppression condition may be received as a separate client request later. Request manager <b>310</b> then maintains/stores the received information as part of configuration data <b>320</b>.

Configuration data <b>320</b> indicates the alert definitions to be processed by alert server <b>150</b>. Configuration data <b>420</b> may also specify the manner in which the alerts are to be generated, for example, the location/client systems of the recipients, the format of the alert, etc. The configuration data may be maintained in any convenient format (such as Extensible Markup Language (XML))/data structure and may be stored to/retrieved from a non-volatile memory such as data store <b>130</b> during operation of alert server <b>150</b>.

In response to receiving an alert definition, request manager <b>310</b> also forms a continuous query, with the query specifying a moving time window and selection criteria. The description is continued assuming that the queries are specified using Continuous Query Language (CQL) described in detail in an article entitled “The CQL Continuous Query Language: Semantic Foundations and Query Execution” by Arvind Arasu, Shivnath Babu and Jennifer Widom, in “The VLDB Journal—The International Journal on Very Large Data Bases”, Volume 15, Issue 2 (June 2006), pages 121-142 published in 2006 (ISSN number 1066-8888).

Request manager <b>310</b> may form the combination of selection criteria and moving time window to ensure that the results of execution of the continuous query are the sequence of occurrences of the pattern of interest in the continuous event streams. In other words, each occurrence of the pattern of interest corresponds to a result of execution of the continuous query during a corresponding duration determined by the moving time window.

Request manager <b>310</b> then creates and/or notifies an instance of query processor <b>330</b> to process the formed continuous query based on the stream of data values (receive via <b>165</b>A). It may be appreciated that request manager <b>310</b> may initialize multiple instances of query processor <b>330</b> and queue <b>340</b> (as shown in <figref idref="DRAWINGS">FIG. 3</figref>) to process different queries (corresponding to different alert definitions). For illustrations, the operation of a single instance of query processor <b>330</b> and queue <b>240</b> is described in detail below.

Query processor <b>330</b> receives a query from request manager <b>310</b> and generates the various results (for respective time instances) based on the selection criteria and moving time window specified in the query. Query processor <b>330</b> then stores the results in queue <b>340</b>. In an embodiment, query processor <b>330</b> generates a query plan specifying a set of operators (where each operator represents a program logic designed to execute one operation of the query) corresponding to the received query. Query processor <b>330</b> also appropriately schedules the execution of the set of operators for generating an output of the query. Query processor <b>330</b> may be implemented based on the concepts described in a paper entitled, “STREAM: The Stanford Data Stream Management System” by Arvind Arasu et al, and available from Department of Computer Science, Stanford University.

In general, query processor <b>330</b> on receiving data values from a source (such as source <b>160</b>A) in the form of a continuous event stream (such as <b>165</b>A) may determine whether each data value received on the event stream is to be included in or excluded from a current duration/window (as determined by the moving time window at that time instance). Query processor <b>330</b> then processes the determined data values based on the selection criteria in the query. Though the query processor is shown as processing values from a single event stream, it may be appreciated that query processor <b>330</b> may be suitably modified to process data values from multiple continuous event streams, as desired in specific environments.

Queue <b>340</b> represents a memory where data values (and corresponding time instances) forming corresponding results of execution of the query are stored. As noted above, each result/data value in queue <b>340</b> corresponds to an occurrence of the pattern of interest specified in an alert definition/client request. In other words, the data values in queue <b>340</b> represents the sequence of occurrences of the pattern of interest in the user specified set of continuous event streams. The values in queue <b>340</b> may be stored to/retrieved from a non-volatile memory such as data store <b>130</b> during execution of the query.

It may be appreciated that in the case of multiple instances, each instance of query processor <b>330</b> receives data values on multiple streams, processes the received data values based on single/multiple time windows and the selection criteria specified in the query, with the final data values in queue <b>340</b> representing the result of execution of the query at a corresponding time instance.

Alert generator <b>350</b> inspects queue <b>340</b> and generates corresponding alerts based on the results/data values (sequence of occurrences of the pattern of interest) stored in queue <b>340</b>. In particular, alert generator <b>350</b> check for each result/occurrence, whether the suppression condition (maintained in configuration data <b>320</b>) is satisfied for the result/occurrence. In the scenario that the suppression condition is satisfied, alert generator <b>350</b> skips the alert corresponding to the occurrence, and proceeds to process the next occurrence in the sequence/queue <b>340</b>.

When the suppression condition is not satisfied, alert generator <b>350</b> creates and sends an alert instance corresponding to the occurrence to the set of users/recipients specified by the corresponding alert definition (in configuration data <b>320</b>). The alert instances may be sent to one of client systems <b>180</b>A-<b>180</b>X (via path <b>115</b>) as indicated by configuration data <b>320</b>. The alert instances may be sent according to any convenient format (pre-configured or user specified in the alert definition) such as email, SMS, etc. as will be apparent to one skilled in the relevant arts.

It may be appreciated that the generation of user alerts based on results of processing of continuous event streams is based on the information specified in the alert definition. The manner in which a user (such as an administrator or designer) is provided a user interface to specify the details of an alert definition/client request is described in detail below.

5. Sample User Interface for Specifying Alert Definition

<figref idref="DRAWINGS">FIGS. 4A-4B</figref> together illustrates the manner in which a user is enabled to specify the details of an alert definition in one embodiment. Each of the Figures is described in detail below.

Display area <b>400</b> of <figref idref="DRAWINGS">FIG. 4A</figref> (and display area <b>480</b> of <figref idref="DRAWINGS">FIG. 4B</figref>) depicts a portion of a user interface provided on a display unit (not shown in <figref idref="DRAWINGS">FIG. 1</figref>) associated with one of client systems <b>180</b>A-<b>180</b>X (assumed to be <b>180</b>A for illustration). In one embodiment, each of display areas <b>400</b> and <b>480</b> corresponds to a webpage accessed by the users using a browser in response to sending a request (including an identifier of the webpage, as indicated by the text in display area <b>405</b> for the web page shown in display area <b>400</b>) from client system <b>180</b>A to alert server <b>150</b> (in particular, request manager <b>310</b>). Each web page is received from request manager <b>310</b> prior to being displayed (using the browser) on the display unit.

Display area <b>410</b> indicates that the web page displayed is provided by a BAM (Business Activity Monitoring) composer application. As is well known, a BAM application facilitates the aggregation, analysis, and presentation of real-time information about activities inside a business organization and involving the customers and partners of the business organization. In other words, each enterprise application executing in a business organization may be viewed as a event source (<b>160</b>A/<b>160</b>B) that generates a continuous event stream of the activities performed (automatically/in response to user inputs) by the enterprise application. Oracle Business Activity Monitoring(BAM) version 12c (available from Oracle Corporation) is an example BAM application, which can be extended in accordance with the features described herein.

Display area <b>415</b> indicates that a user (an administrator or designer) is currently specifying the definition of an alert in relation to one or more continuous event streams, with display area <b>420</b> indicating that the name of the alert as being “DataAlert”.

Display area <b>430</b> specifies the matching condition/pattern of interest to be used for generation of the alerts. Display area <b>430</b> is shown providing a pre-defined template (a fixed combination of words and fields), with the portions shown in dotted boundaries (fields) being editable by the user. Thus, display area <b>430</b> is shown containing two fields, a first field (<b>435</b>) for specifying the matching condition/pattern of interest along with the specific continuous event streams and a second field for specifying the application supporting the specific continuous event streams (the value “weblogic” indicating that the streams are supported by the BAM application). The user may click/select the desired field and specify the desired condition/other information appropriate for the selected field. The manner in which a user edits a field is described in detail below.

Referring to <figref idref="DRAWINGS">FIG. 4B</figref>, display area <b>480</b> depicts a portion of a user interface (such as a web page) displayed in response to the user selecting field <b>435</b> in display area <b>430</b> of <figref idref="DRAWINGS">FIG. 4A</figref>. Display area <b>490</b> enables the user to select the desired continuous event stream/data object (“DO1”) in relation to which the alert is defined, while display area <b>495</b> enables the user to specify the desired pattern of interest as “region is equal to ‘South’” where region is an attribute of the continuous event stream DO1. The user may select the “OK” button to save/store the specified information.

Referring again to <figref idref="DRAWINGS">FIG. 4A</figref>, field <b>435</b> is shown specifying the pattern of interest “region EQ South” (EQ being the “equal to” operator) in response to the user specifying the information as shown in display area <b>480</b> of <figref idref="DRAWINGS">FIG. 4B</figref>. The description is continued assuming that user interfaces (not shown) similar to display area <b>480</b> are provided to the user for specifying the details of the other fields (shown in dotted boundaries) in display area <b>400</b>.

Each of display areas/lines <b>441</b> and <b>442</b> specifies the specific actions to be performed when an occurrence of the matching condition is determined Again, templates are shown provided to the user, with corresponding fields being editable. Lines <b>441</b> and <b>442</b> accordingly indicate that email communications are to be sent to “pavan@acmecorp.com” and “admin@acmecorp.com” for each occurrence of the pattern of interest in the continuous event stream DO1. It may be appreciated that the email addresses noted here may correspond to the user designing the alert definition or to other users who may wish to receive such alerts.

Furthermore, for each of the lines/actions specified for the alert, a checkbox (with the text “Suppress this action”) is also shown provided. The user may click/select the checkbox to indicate that a suppression condition is to be specified for the action. It may be observed that only the checkbox in line <b>441</b> is shown selected, to indicate that the suppression condition is associated with the action in line <b>441</b> (and not line <b>442</b>).

Display area <b>450</b> facilitates a user to specify a suppression condition associated with any of the actions (such as lines <b>441</b> and <b>442</b>) specified for the alert. Display area <b>450</b> is shown as specifying the suppression condition for action/line <b>441</b>. Though not shown, display area <b>450</b> may be suitably updated in response to the user selecting (the checkbox in) the other actions/lines (such as <b>442</b>).

Display area <b>460</b> provides a template for suppressing a repetitive alert, with the user specifying that in the scenario that the alert “DataAlert” is repeated 3 times within a time span of 60 minutes, all subsequent alert instances (of the “DataAlert”) in the next 12 hours is to be suppressed. In other words, the user wishes to receive an alert when an occurrence of the pattern of interest is determined (by alert server <b>150</b>), but would like to suppress the alert if the number of instances of the alert is too frequent.

Display area <b>480</b> indicates that the action to be taken by the user during the time window (12 hours) that the alerts are not received. The designer/administrator may select the “Text” checkbox and specify a text to be sent to the user during the time window. Alternatively, the other checkbox may be selected to indicate that the user will decide dynamically and will log his/her course of action.

After specifying the desired matching condition (in <b>430</b>), the suppression condition (in <b>450</b>), the set of continuous event streams (here, DO1) and the set of users/recipients to whom alerts are to be sent (in lines <b>441</b>-<b>442</b>), the user may click/select “Save” button <b>490</b> to submit the corresponding alert definition/client request to alert server <b>150</b>.

It may be appreciated that the alert definition specified using <figref idref="DRAWINGS">FIG. 4</figref> a timing pattern for prior alert instances (3 alert instances in 60 minutes) and a suppression duration (12 hours). Accordingly, alert server <b>150</b> skips the alert instance for an occurrence if the timing of alert instances prior to the occurrence satisfies the timing pattern and the timing of the occurrence is within the suppression duration.

Furthermore, it may be observed that the alert instances are indicated to be sent to multiple users, while the suppression condition is associated with only a specific one of the users. Thus, during the suppression duration, the corresponding alert instance is sent to all the other users, but is skipped for the specific user.

In general, a user/designer may specify a timing pattern in the form of a threshold number (<b>3</b> in <figref idref="DRAWINGS">FIG. 4</figref>) of prior alert instances, in a prior duration (60 minutes), wherein subsequent alert instances are suppressed for the suppression duration (12 hours) upon generation of the threshold number of prior alert instances in the prior duration thereby avoiding repetition of the alert instances beyond the threshold number in a duration (13 hours) of a sum of the prior duration and the suppression duration.

Thus, a user may specify a desired alert definition using the user interface of <figref idref="DRAWINGS">FIG. 4</figref>, and submit the alert definition to alert server <b>150</b>. The manner in which the various blocks of alert server <b>150</b> (as shown in <figref idref="DRAWINGS">FIG. 3</figref>) operate to send alerts (and also to skip alerts) for the alert definition shown in <figref idref="DRAWINGS">FIG. 4</figref> is described below with examples.

6. Example Operation

<figref idref="DRAWINGS">FIG. 5</figref> depicts the manner in which user alerts based on results of processing of continuous event streams is generated in one embodiment. In particular, the generation of user alerts for the alert definition/client request submitted using the interface of <figref idref="DRAWINGS">FIG. 4</figref> is described in detail below.

In response to the user submitting the client request (by selecting button <b>490</b>), request manager <b>310</b> in alert server <b>150</b> stores the user specified information of <figref idref="DRAWINGS">FIG. 4</figref> in configuration data <b>320</b>, and thereafter generates a CQL query with a selection criteria and a moving time window. An example CQL query that may be generated for identifying the occurrences of the alerts as defined in <figref idref="DRAWINGS">FIG. 4</figref> is shown below:

SELECT*

FROM DO1 [RANGE 15 minutes SLIDE 15 minutes]

WHERE DO1.Region=“South”;

wherein the words “SELECT”, “FROM”, “RANGE”, “SLIDE”, “WHERE” and “minutes” and the symbols “*”, “[”, “]” and “;” represent constructs having a pre-defined meaning in CQL.

As is well known, the “FROM” clause indicates the names (here, DO1) of the continuous event stream, the “SELECT” clause indicates the names of the specific attributes to be retrieved from the continuous event stream DO1 (with * indicating that all the attributes are to be retrieved), and the “WHERE” clause specifies the selection criteria that has to be satisfied by the data values in the continuous event stream. The “RANGE” clause indicates the width of the moving time window (here 15 minutes), while the “SLIDE” clause indicates the time intervals at which the outputs are to be generated (in other words, the duration by which the time window is to be moved after generating an output, here 15 minutes).

Thus, the above CQL query indicates that all the activities received on continuous event stream DO1 that have the attribute “Region” equal to “South” in a time window of 15 minutes is to be output as a result of processing/execution of the query. The time window is then to be moved by 15 minutes, and the result to be generated for the moving window iteratively. Thus, assuming the query is initially executed at 10:15 (according to 24:00 hour format), the result of processing is the set of matching activities (having “Region” equal to “South”) in the duration 10:00-10-15. The result is also generated at 10:30, 10:45, 11:00, etc. to output the matching activities in the respective durations of 10:15-10:30, 10:30-10:45, 10:45-11:00, etc.

It may be observed that the combination of selection criteria and moving time window is formed to ensure that the results of execution of the CQL query noted above are the sequence of occurrences of the pattern of interest (region EQ South) in the continuous event stream (DO1). Request manager <b>310</b> then initializes an instance of query processor <b>330</b> to process a CQL query formed for the user specified pattern of interest. The manner in which query processor <b>330</b> executes the above noted CQL query is described in detail below.

For illustration, the processing of the data values received in the continuous event stream (DO1) in shown in the form of table <b>500</b>. However, the processing may be performed using data structures such as trees, lists, etc. and/or using other formats, as will be apparent to one skilled in the relevant arts by reading the disclosure herein.

Table <b>500</b> depicts the manner in which the alerts are generated based on results of processing of continuous event streams. Column <b>521</b> (“Time (t)”) indicates time instances at which corresponding data values are received in the continuous event stream DO1, while columns <b>522</b> (“Activity”) and <b>523</b> (“Region”) indicate portions of the data values received. For convenience, only the portions relevant to the query are shown (values in column <b>523</b>), while the portions that are not relevant are represented by the text “˜” (values in column <b>522</b>).

Column <b>524</b> (“In window (w)”) indicates the specific current duration/window in which the received data values are processed. It should be noted that all the time instances are specified according to the “24:00” format for convenience. Column <b>525</b> (“In Queue”) indicates whether the data values are included as the result of processing of the query/occurrence of the pattern of interest. Columns <b>526</b> (“User 1 Alert”) and <b>527</b> (“User 2 Alert”) indicates whether alerts are generated for the respective users “pavan” and “admin” shown in lines <b>441</b> and <b>442</b> of <figref idref="DRAWINGS">FIG. 4</figref>. The value “Send” in columns <b>526</b>/<b>527</b> indicates that the alert is generated and sent to that user, while the value “Skip” indicates that the alert is skipped (for the corresponding occurrence/result of processing) for that user.

Each of rows <b>541</b>-<b>554</b> indicates the details of a corresponding data value received on continuous event stream DO1 and the manner of processing the data value (generating or skipping the alert). It may be observed in rows <b>541</b> and <b>542</b>, that though both the data values are included in the same window (12 June 15:30-15:45), only the data value in row <b>541</b> is output as a result of processing of the query to the queue in view of the region being equal to “South” (as specified by the “WHERE” clause in the above noted CQL query). As noted above, the results of processing are added to the queue at the end time of corresponding window (w), for example, at 15:45 for the window 15:30-15:45 indicated in row <b>541</b>. In response to the occurrence in row <b>541</b>, an alert instance is generated (and sent) for both users User 1 and User 2. It may be appreciated that that suppression condition is not satisfied for row <b>541</b>, as the timing pattern specified in the suppression condition is not present for the prior alert instances.

Similarly, alerts are also generated for the occurrence in row <b>543</b>, while no alerts are generated for the data value in row <b>544</b> in view of no result in the queue. For conciseness, only the processing of the various data values matching the selection criteria (and which accordingly would be included in the queue/results of processing) are noted in the subsequent rows. It may be appreciated that other data values having the region attribute not equal to “South” would be ignored by query processor <b>330</b>, similar to rows <b>542</b> and <b>544</b>.

With respect to rows <b>545</b>-<b>549</b>, it may be observed that the data values are received in a short duration (between 10:10 and 10:50 on June 16). Accordingly, alerts are shown generated for each of the windows 10:00-10:15 (row <b>545</b>), 10:15-10:30 (reporting both the data values in rows <b>546</b> and <b>547</b>) and 10:30-10:45 (row <b>548</b>). Accordingly, in response to the occurrence in row <b>549</b>, alert generator <b>350</b> determines that the timing pattern (3 alert instances in the 60 minutes) specified in the suppression condition (of display area <b>450</b>) is present, and accordingly skips the alerts to User 1 for the next 12 hours (suppression duration).

Thus, for the data values in rows <b>549</b>-<b>552</b>, alert generator <b>350</b> skips the alerts for User 1 for each of the occurrences of the pattern of interest in the continuous event stream DO1. In row <b>553</b>, alert generator <b>350</b> generates the alert for User1 in view of the expiry of the suppression duration (12 hours) from the timing (10:45) of the last alert (in row <b>548</b>). It may be observed that during the suppression duration (from 10:45 to 22:45 on 16 June), alert generator <b>350</b> generates alerts for User 2, as indicated in rows <b>549</b>-<b>551</b>.

An aspect of the present disclosure facilitates a user to send a second suppression duration after receiving one or more alerts from alert server <b>150</b>, indicating that the subsequent alert instances within the second suppression duration are to be skipped for the user. The description is continued assuming that such as second suppression duration of 8 hours is received from User 2 at 16 June 16:00 (after receiving the alert in row <b>551</b>).

Accordingly, in rows <b>552</b>-<b>553</b>, alert generator <b>350</b> skips the alerts for User 2 for each of the occurrences of the pattern of interest in the continuous event stream DO1. In row <b>554</b>, alert generator <b>350</b> generates alerts for both users User 1 and User 2 since the suppression condition specified in the alert definition (shown in <figref idref="DRAWINGS">FIG. 4</figref>) is not satisfied for User 1 and due to the expiry of the second suppression duration for User 2.

It should be appreciated that the features described above can be implemented in various embodiments as a desired combination of one or more of hardware, executable modules, and firmware. The description is continued with respect to an embodiment in which various features are operative when executable modules are executed.

7. Digital Processing System

<figref idref="DRAWINGS">FIG. 6</figref> is a block diagram illustrating the details of digital processing system <b>600</b> in which various aspects of the present disclosure are operative by execution of appropriate executable modules. Digital processing system <b>600</b> may contain one or more processors such as a central processing unit (CPU) <b>610</b>, random access memory (RAM) <b>620</b>, secondary memory <b>630</b>, graphics controller <b>660</b>, display unit <b>670</b>, network interface <b>680</b>, and input interface <b>690</b>. All the components except display unit <b>670</b> may communicate with each other over communication path <b>650</b>, which may contain several buses as is well known in the relevant arts. The blocks of <figref idref="DRAWINGS">FIG. 6</figref> are described below in further detail.

CPU <b>610</b> may execute instructions stored in RAM <b>620</b> to provide several features of the present disclosure. CPU <b>610</b> may contain multiple processing units, with each processing unit potentially being designed for a specific task. Alternatively, CPU <b>610</b> may contain only a single general-purpose processing unit. RAM <b>620</b> may receive instructions from secondary memory <b>630</b> using communication path <b>650</b>. RAM <b>620</b> is shown currently containing software instructions constituting shared environment <b>625</b> and user programs <b>626</b>. Shared environment <b>625</b> includes operating systems, device drivers, virtual machines, etc., which provide a (common) run time environment for execution of user programs <b>626</b>.

Graphics controller <b>660</b> generates display signals (e.g., in RGB format) to display unit <b>670</b> based on data/instructions received from CPU <b>610</b>. Display unit <b>670</b> contains a display screen to display the images defined by the display signals (for example, the portions of the user interface of <figref idref="DRAWINGS">FIG. 4</figref>). Input interface <b>690</b> may correspond to a keyboard and a pointing device (e.g., touch-pad, mouse) and may be used to provide inputs (for example, the details of the user request provided using the user interface of <figref idref="DRAWINGS">FIG. 4</figref>). Network interface <b>680</b> provides connectivity to a network and may be used to communicate with other systems (such as the systems of <figref idref="DRAWINGS">FIG. 1</figref>) connected to the network.

Secondary memory <b>630</b> may contain hard drive <b>635</b>, flash memory <b>636</b>, and removable storage drive <b>637</b>. Secondary memory <b>630</b> may store the data (for example, data values received in a continuous event stream such as the values shown in <figref idref="DRAWINGS">FIG. 5</figref>) and software instructions (for implementing the steps of <figref idref="DRAWINGS">FIG. 2</figref>, described above), which enable digital processing system <b>600</b> to provide several features in accordance with the present disclosure. The code/instructions and ASCII data stored in secondary memory <b>630</b> may either be copied to RAM <b>620</b> prior to execution by CPU <b>610</b> for higher execution speeds, or may be directly executed by CPU <b>610</b>.

Some or all of the data and instructions may be provided on removable storage unit <b>640</b>, and the data and instructions may be read and provided by removable storage drive <b>637</b> to CPU <b>610</b>. Removable storage unit <b>640</b> may be implemented using medium and storage format compatible with removable storage drive <b>637</b> such that removable storage drive <b>637</b> can read the data and instructions. Thus, removable storage unit <b>640</b> includes a computer readable (storage) medium having stored therein computer software and/or data. However, the computer (or machine, in general) readable medium can be in other forms (e.g., non-removable, random access, etc.).

In this document, the term “computer program product” is used to generally refer to removable storage unit <b>640</b> or hard disk installed in hard drive <b>635</b>. These computer program products are means for providing software to digital processing system <b>600</b>. CPU <b>610</b> may retrieve the software instructions, and execute the instructions to provide various features of the present disclosure described above.

The term “storage media/medium” as used herein refers to any non-transitory media that store data and/or instructions that cause a machine to operate in a specific fashion. Such storage media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical disks, magnetic disks, or solid-state drives, such as storage memory <b>630</b>. Volatile media includes dynamic memory, such as RAM <b>620</b>. Common forms of storage media include, for example, a floppy disk, a flexible disk, hard disk, solid-state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge.

Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus <b>650</b>. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

Reference throughout this specification to “one embodiment”, “an embodiment”, or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, appearances of the phrases “in one embodiment”, “in an embodiment” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

Furthermore, the described features, structures, or characteristics of the disclosure may be combined in any suitable manner in one or more embodiments. In the above description, numerous specific details are provided such as examples of programming, software modules, user selections, network transactions, database queries, database structures, hardware modules, hardware circuits, hardware chips, etc., to provide a thorough understanding of embodiments of the disclosure.

8. Conclusion

While various embodiments of the present disclosure have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

It should be understood that the figures and/or screen shots illustrated in the attachments highlighting the functionality and advantages of the present disclosure are presented for example purposes only. The present disclosure is sufficiently flexible and configurable, such that it may be utilized in ways other than that shown in the accompanying figures.

Further, the purpose of the following Abstract is to enable the Patent Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is not intended to be limiting as to the scope of the present disclosure in any way.