AU2010212459B2 - Method of processing events for real-time analysis of key processes of an enterprise - Google Patents

Abstract

The present invention relates to methods of analyzing event data for decision making purposes of an enterprise. The present invention has particular but not exclusive application for enterprises such as businesses and organizations. In one aspect the present invention broadly relates in a method of processing events for real-time analysis of key processes of an enterprise. The method includes capturing data from each event and formatting the event data to a common format including the following information: date and time about the event, event source, event agent that collects the information, and optional fields that are particular to the type of event. The method further includes processing the formatted event data by applying rules to the event data; and the presentation of processed data to provide a meaningful operational analysis of the enterprise. Synthetic Ev1nts component Raw EentsRules Engine Synthetic Events Copnn Figure 1

Description

1 2010212459 20 Aug 2010

METHOD OF PROCESSING EVENTS FOR REAL-TIME ANALYSIS OF KEY

PROCESSES OF AN ENTERPRISE

FIELD OF INVENTION

The present invention relates to methods of analyzing event data for decision making purposes of an enterprise. The present invention has particular but not exclusive application for enterprises such as businesses and organizations.

BACKGROUND OF THE INVENTION

There is a need for businesses to make decisions in light of current information about their daily operations. The daily operations of the business form a series of events. An event can be generated by a variety of sources including computer applications, humans, other devices, sensors, IT systems, monitoring systems and external data feeds. The events are a source of valuable operational data. Because of the large number of events and large volume of related data, there are no methods or systems developed that can handle all the events in a business. Furthermore many business computing environments have evolved over time into a complex set of islands of automation designed to address specific business needs.

Businesses currently take a time-slice sample of events relating to a key process to provide perspective to the making of their decisions. The time slice sample of events provides limited relevant information because the data is not a true reflection of what is happening and may even miss a significant event which significantly impacts on the business.

Other businesses collect data often over a set period of time, then separately and at a later time analyze the data. While a larger sample of data is collected -2- 2010212459 23 Sep 2016 making the analysis more meaningful, the relevance of the data however is reduced as there is a time lapse between the collection of data, it’s analysis and presentation, and use. A delayed response increases the negative impact of the event on the business while increasing the amount of effort to resolve the issue. 5

OBJECT OF THE INVENTION

It is an object of the present invention to provide an alternative method of processing events for analysis of key processes of an enterprise overcoming one or more of the above mentioned disadvantages. 0

SUMMARY OF THE INVENTION

In one aspect the present invention broadly resides in a method of processing event data in an event processing network for real-time analysis of key processes of an enterprise, wherein the event processing network is a hierarchy including event 5 agents for capturing event data, parent nodes for receiving event data from one or more event agents, and a master node at the top of the event processing network hierarchy for collecting all event data from the event agents and their parent nodes, the method including: capturing event data from each event by collecting data from an event data source using an event agent, wherein: the event agent includes: a 20 processor including at least one of a computer and server; and at least one of a sensor and an input device including at least one of a card reader and a keypad; an agent profile is used to control the flow of data from the event data source to the event agent, in which the agent profile includes a specification of a network location of the event data source; and the event agent has a configured property which 25 defines the event agent’s relationship with one or more parent nodes in the event -3 - 2010212459 23 Sep 2016 processing network hierarchy; the event agent formatting the event data to a common format including the following information: date and time about the event, the event source, the event agent that collects the information, and optional fields that are particular to the type of event; the event agent forwarding the event data to 5 the one or more parent nodes defined in the configured property, on a predetermined schedule, wherein each of the parent nodes in the event processing network is able to apply rule based processing to incoming event data from the event agents; the parent nodes processing the formatted event data by applying rules to the formatted event data using a rules engine, wherein the rules are preset so that they can 0 operate directly on the formatted event data, and wherein the rules include at least one ‘for each one’ rule that operates on the formatted data by identifying for each one of X, then do Y; and the master node collecting all event data from the event agents and their parent nodes within the event processing network, including all processed event data, wherein the master node deploys an integration interface to 5 allow for processed event data sourced within the event processing network to be used by other upstream external applications and by which external applications can invoke various functions within the event processing network infrastructure.

The enterprise includes any business or organization that has commercial outcomes. 20 Any suitable industry standard or proprietary transport protocol is preferably used by the event agent to connect to the event data source. The agent profile in one embodiment further includes the periodicity of event data that should be captured, authentication and encryption code profile. An event schema is preferably used to transform the native event data into a normalized event data type for forward 25 processing. The event schema is preferably configured at the time of storing the -4- 2010212459 23 Sep 2016 events so as to make the format of events consistent and the event data readily useable.

The rule based processing is preferably used to analyze incoming event data stream content in real time. The rules can include a range of different types of 5 operations such as maintaining and incrementing counts, deriving summary or aggregate events from raw event data, and triggering conditional rules based on event data stream content. The rules are preferably implemented at any parent node within the event processing network.

Preferably the master node can also apply rules to incoming event data 0 streams in a similar fashion to those applied at other parent nodes within the event processing network. There may be additional rule capabilities at the master node and include the configuration and implementation of event data storage mechanisms such as for long term archiving.

Optional fields that are particular to the type of event are preferably values 5 that are meaningful with respect to the event. For example, a digital fingerprint or checksum for registration of a software product or a security access profile when a card is swiped through a reader to gain access to a restricted area. The optional fields preferably include data that describes the route that the event has taken from collection to processing. 20 The rules may be any rules that have meaning to the enterprise and are preferably able to be applied to a selection or all of the event data.

As mentioned above, there is a ‘for each one’ rule that operates on the formatted data by identifying for each one of X, then do Y. The advantage of this rule in the event processing network is that it is applied to data that is already 25 formatted with a common format and there is no need to follow a convoluted -5- 2010212459 23 Sep 2016 operational pathway where it is necessary to determine how many event data types there are, assess all the data types for X and for every instance of X do Y.

After the event data has been processed it can then be presented in any suitable manner such as visually on a screen, published on paper or sent to external 5 applications for further processing or presentation.

The integration interface preferably provides the ability to invoke additional external processes such as incident management and response workflows based on detected event data within the network or to handle configuration changes issued by external administration applications. A data visualization and analysis component is 0 preferably deployed on top of the integration interface at the master node to allow for the display and query of event data from within the network through graphical user interfaces.

Preferably the method can be implemented as an overlay to existing systems in the business to enable processing of events from multiple sources thereby 5 providing a new overview of operations.

Multiple views can preferably be developed using event processing rules to provide business-relevant information to the right people when it is of the most value empowering users to make fast and accurate decisions. For example, events can be collected from the front office, monitoring layer, and back office to provide a view of 20 transactions related to a customers, processes, KPIs or any metric that’s is important to the enterprise. The method can preferably be used to monitor business processes and technology across the enterprise computing environment and feed applications and humans via the response framework. The method can thus unify events from different sources across the enterprise to utilize event data without 25 making changes to applications or deploying large, complicated technology stacks. 2010212459 20 Aug 2010 6 BRIEF DESCRIPTION OF THE DRAWINGS In order that the present invention can be more readily understood reference will now be made to the accompanying drawings which illustrate a preferred embodiment of the invention and wherein:

Figure 1 is a diagrammatic representation of the event processing network; Figure 2 is a further diagrammatic view of the event processing network;

Figure 3 is a diagrammatic view of the rules engine of the preferred embodiment;

Figure 4 is a diagrammatic view of the “for each” and other rules engine interaction;

Figure 5 is a diagrammatic view of the “for each” and context creation over time;

Figure 6 is a diagrammatic view of the tracking of software installation of the example. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT In an event processing network, event data is collected, formatted to a common format and analyzed by the use of preset rules. The preset rules have been generally referred to in the specification as the rules engine. The preferred embodiment of the event processing network has a rules engine with the following features.

The rules engine has two types of rules, first order rules and second order rules. The first order rules are free standing and are self contained. The second order rules are embedded within the first order rules. The second order rules spawn 7 2010212459 20 Aug 2010 a rule iteration for every combination of events or event properties attached to an event, including time.

The first order rules may be applied to a selection of events from an event stream, or to all events in an event stream. The first order rules may trigger storage of an event state either as raw data, incremental count, or aggregate.

The first order rules may trigger non-storage actions such as the generation of synthetic events, invocation of another rule or setting of an arbitrarily sized time or sequence based window (including infinite sized windows). A window (a set of boundaries within which a rule applies) can be established on the basis of any event criteria (as distinct from traditional time or sequence based windows).

The first order rules are able to be applied to an incoming event to generate a comparison between that event and a stored event state or summary. The first order rules can then be invoked to react on the basis of degree of similarity or difference between event states or event summaries.

The first order rules and the second order rules can trigger the storage of not only the raw event data, but additional information regarding the context of the event within the event processing network.

The first order rules and the second order rules are invoked a maximum of once per event on an event stream.

The first order rules and the second order rules can generate new synthetic events as a response to either incoming events on an event stream, in response to a time or sequence window condition.

The first order rules and the second order rules can either utilize a reference clock for time synchronization or timestamps derived from the events on an event stream. 2010212459 20 Aug 2010 8

The first order rules and the second order rules can be both active and generate events, and / or the first order rules and the second order rules can be passive and react only to queries. This latter mechanism allows for the implementation of a means for current event state or event summary navigation in an event data store.

The first order rules and the second order rules support the concept of ‘events which are expected to happen’. An ‘event due list’ can be implemented as a rule or allowing the definition of an acceptable time or sequence window within which it is expected that events will occur. The first order rules and the second order rules are able to automatically detect if they are valid based on the time or sequence window. The failure of events to occur within this window results in the first order rules emitting a synthetic error event.

The first order rules or the second order rules can be applied to an incoming event stream to generate a synthetic summary of the events and their properties according to a given schedule. For example, a summary may be produced for each 60 seconds, 3600 seconds or 86400 seconds. After a summary is made, the first order rules and the second order rules can either be reset to again trigger after the next summary interval or persist for cumulative summarization in the next time interval.

Summary events generated by the first order rules or the second order rules can be persisted for historical analysis over an extended time span. This feature allows for event state to be maintained across temporal boundaries, as opposed to only available at the time of event streams entering the rules engine. 2010212459 20 Aug 2010 9

The events sourced from the event processing network can be enriched with specific metadata, which is then able to be used by rules and the second order rules as a selection mechanism for events from a stream.

The first order rules and the second order rules can subscribe to changes in current event state, as well as be invoked as a query for current event state. This feature allows the first order rules to request ‘current event state and any future changes to the event state’ on the basis of the first order rules.

The first order rules and the second order rules can subscribe to changes in current event summaries, as well as be invoked as a query for the current event summary. This feature allows a first order rule to request ‘current event summary and any future changes to the event summary’ on the basis of thefirst order rules.

External user applications can invoke queries regarding the current event state and future changes to event state, on the basis of a first order rule. External user applications can invoke queries regarding the current event summary and future changes to event summaries, on the basis of a first order rule.

The first order rules, the second order rules and their state are persistent, guaranteeing transactional integrity independently of system status (eg persist across system restarts, shutdowns).

The first order rules and the second order rules can be added dynamically to the event processing network, and/or modified with no system downtime. All prior versions of the first order rules or the second order rules are retained within the rules engine, and a currency indicator is used to nominate the version of the rule which is active. Where historical event data is the focus of analysis, an option is provided to use either the current first order rules / the second order rules or the versions of the 10 2010212459 20 Aug 2010 first order rules / the second order rules which were current at the point where source events were collected and initially analysed within the system.

In addition to the first order rules and the second order rules, there are two functions ‘for each’ and ‘time-slice’.

To enable the production of a correlated view of events across systems, the first order rules are complemented by a specialized operator ‘for each’. This ‘for each’ construct specifies some properties of the inbound events that identify the key of the entity being tracked. A rule can allocate a unique key for any or all events which have a particular value. Another rule can maintain account of all keys simultaneously and hence track the last known state of those keys. In this way a first order rule can be easily written to store separate event state for each key and therefore for each entity being tracked through events. A rule focused on event state has all the other functions of a rule: it can check state stored for it (maybe comparing with the inbound event); use ‘event due list’ operators and generate synthetic events. If required the entire state and its associated state can be deleted when certain conditions are met. This may be a time condition such as a ‘due list’ or can be some other condition, allowing the stored state to persist as long as is needed. A time-slice construct may be added within a ‘for each’ construct. The time-slice construct allows for aggregate values to be calculated for each time-slice and key and stored for later retrieval. When an event is received, the ‘for each’ function will allocate the event to a rule or based on the key, while the ‘time-slice’ function will allocate the event to a time-slice based on either the current time or the event time and the aggregate value updated accordingly. Depending on the reliability and performance requirements, event values can be written to storage immediately, or 2010212459 20 Aug 2010 11 flushed at intervals. An absolute point in time may be specified for calculating time-slices, to ensure they fall on the required anniversary, .e.g. 24 hour time-slices running from midnight to midnight GMT.

Any ‘for each’ constructs may be used for the same events. For example, if tracking entities which proceed through various stages, one ‘for-each’ could be used to record the current stage of each entity deleting the event state 24 hours after the ‘final’ state has been reached. Another ‘for-each’ could summarize how many events were in each state for every minute and hour.

As well as the first order rules and the second order rules generating synthetic events, the state of the rules and the second order rules may be queried. Through ‘for-each’ the keys can be queried and stored event state of specific keys queried. Additionally, a subscription query would give the enquirer immediate event state and any subsequent changes to that event state. A subscriber may be notified if new keys are added (so that they may query the associated event state) or notified that the event state for a key has been updated or deleted. This allows monitoring applications such as dashboards to receive immediate state and dynamically update their displays when that state changes.

Event summary state may be queried in a similar manner, with the addition of the query specifying the range of time-slices and the size time-slice to query. In this case the result is the aggregated values for the specified time-slice within the specified window. A subscription query may be created to send historical summaries and new summaries as they are created. A ‘for-each’ construct can be used that causes the engine to create and manage a context for each key identified across many events. Within that ‘for-each’ 2010212459 20 Aug 2010 12 construct any procedure may be specified and it will be performed by the engine within the correct context for the given key. A ‘for-each’ construct can be used that causes the engine to create and manage a context for each key identified across many events. Within that ‘for-each’ construct any data from the event can be stored in the context in a persistent way, ensuring that it is available to be used when processing another event in the same context. The context is stored as long as necessary and survives system restarts and crashes. Any procedure specified within the ‘for-each’ construct can utilise or modify that context data. It can examine that context data and when a certain state is reached can take an explicit action.

Any ‘due-list’ procedure specified within the ‘for-each’ construct can utilise the context data to determine when it is due and when it is actually due to execute any procedure within that context.

An external process can query the ‘for-each’ rule to discover all contexts and query the content of the contexts. An external process can register to be notified about added, removed or updated contexts associated with the ‘for-each’ rule.

The application of rules to incoming events can be distributed throughout the event processing network, rather than applied only in a central location. Rules can be segmented for distribution based on their logical sub-rule or smaller components, or on the basis of applicability of the rule to event conditions with regard to event processing network topology.

The location of rule components is independent of their execution in response to events, and rules distributed across the event processing network nodes can be virtually composited together and executed as a single instance. - 13 - 2010212459 14 Jun2016

With reference to figure 1, the rules engine is interposed between incoming events to the event processing network and outputs from the event processing network. Figure 2 shows the event processing network in more detail. The rules engine receives streams of events from event data sources through the network’s 5 agent framework. The rules engine applies specified rules to the incoming event data stream. The results of application of the specified rules can be both new synthetic events which are passed either to the rules engine for subsequent iterations, or to other parts of the network, or to external applications.

With reference to figure 3, events sourced within the network are forwarded to 0 the rules engine for processing. Some event types meet only simple conditions for rule execution such as forwarding to external components for action. Other event types require the generation of or maintenance of a persistent state and are hence written to the network’s persistent state engine. Other events invoke the ‘for-each’ construct, and/or elements, and are consequently processed, resulting in the update 5 of persistent state. Other events invoke the generation of new synthetic data which is in turn stored.

In figure 4, events arrive at the rule and the ‘for-each’ construct determines the key of the event. If context for that key is created or retrieved and the rule within the ‘for-each’ construct operates within that context also having access to the 20 inbound event. The rule may store data, add, modify or remove due list entries and execute procedural steps. As specified by engine persistence policies, the context is stored in a persistent store to ensure it survives system crashes and restarts.

External systems may query the contexts to retrieve the stored data and also register to be notified when there are changes to contexts and their stored data. -14 - 2010212459 14 Jun2016

In Figure 5, the arrival of a sequence of 3 events at a ‘for-each’ rule is depicted. The ‘for-each’ construct uses the field ‘key’ as the key of the rule. Event 1 has a key of ‘12’ and no context exists for that key so a new one is created, the value of ‘a’ is stored. The procedure is executed within this context resulting in no further 5 action as the condition is not met. Event 2 arrives with a key of ‘99’. As no context for this key is stored a new context is created in a similar fashion to Event 1. Event 3 arrives with a key of ‘12’. The existing context is retrieved and the value of b stored. The procedure is executed within this context resulting in the generation of a new synthetic alert event as the condition is now met (the context contains a=high from 0 Event 1 and b=Monday from Event 2).

Example 1: Tracking Software Installation

When software is distributed by a vendor to end users to install after purchase, the sequence of user actions and corresponding system state during the install process 5 can be interpreted as a stream of events. Capturing and analyzing these events with the rules engine in particular can result in a more effective delivery and support process.

Events can be emitted from the software based on progression through 20 various stages eg downloaded, install started, install completed, software registered, software operational, install aborted etc, and include metadata regarding the system context surrounding the event. Such events are of considerable interest to software vendors who see a majority of their support costs borne during the software acquisition and installation cycle. -15 - 2010212459 14 Jun2016

When a customer wishes to evaluate a piece of software prior to purchase, they log on to a website to download a time/feature limited trial copy of software. In order to obtain the software, the customer must provide various types of information to register as a trial user and/or to obtain a license. Once the registration is 5 complete, the customer downloads the trial copy of the software and proceeds to install it. The installation process is multi-stage, and may require the customer to enter specific information from the registration, and the software installation process may initiate a connection to an internet service to determine the legitimacy of the installation, any time/feature enablement or disablement, and register itself with the 0 software publisher for purposes such as incremental updates and upgrades.

The events may be generated throughout this process include website statistics regarding customer access such as time, date, network location, browser used; customer registration details such as time, date, name, email address, geographical location, system type, license; software download details such as time 5 and date started, time and date completed, network location from which the download was delivered; software installation details such as time and date started, time and date of installation increments, overall success or failure, time and data completed, system environment, license, update configuration. A set of first order rules and the second order rules could be implemented 20 over the software installation tracking event stream. The rules include the identification of premium customers in order to provide preferential access to software download services; identification of the demographics of deployed software instances across the entire customer base in order to understand product lifecycles; track duplicate software purchases by the same user for resolution through either 25 accounting or without appropriate licensing; identification of incomplete installations, -16- 2010212459 14 Jun2016 that is where software has been downloaded and installation commenced but not completed, for purposes of providing technical support or informing product management; identification of the volumes of time/feature limited trial software; identification of the conversion rates between time/feature limited trial software and 5 full commercially licensed versions; identification of the demand curve for initial software downloads and subsequent updates and upgrades in order to be informed about providing IT services.

Using the rules engine, and assuming appropriate event capture and transport, it is possible to track the status of software on an individual basis (ie each 0 user’s progress and experience with installation), as well as the status of software more generally (ie aggregate across the broader user population on the basis of status). Using the rules engine, both of these metrics would be derived using the same rule set.

With the application of the rules, the results can be statistically or graphically 5 displayed for use in running the business. The results can be analyzed so that a selection of processed data is examined in detail. With the processed data, alerts can be triggered when certain threshold values are reached. The alerts can set off a series of actions for the vendor to follow up. The processed data can also be used and processed with other external applications in the business. 20 With the present example of a preferred embodiment the results are displayed using a variety of graphical elements such as charts, graphs, warning panels, lists, dials in a web based dashboard environment, and may be exposed as a data collection to more traditional data analysis and reporting infrastructure such as business intelligence platforms. -17 - 2010212459 14 Jun2016

Figure 6 provides a diagrammatic view of the monitoring of the download process. In this example a simple for-each rule across unique license key would store in its context all data pertaining to the product. The following processes could operate on and within that context: 5 · If an installation error event is received and the data stored in the context (from the purchase event) indicates that the customer is a premium customer then generate an event for an external system to trigger a customer service agent to contact the customer. • A start-installation event was received and the due list timer was not cleared 0 as no end-installation event was received within 1 hour - generate an error event which can be processed by the same for-each rule (e.g. premium customer case from above may be invoked). • A customer service agent could query the context for a specific license key to help them provide support to a customer problem - they would have all the 5 available data pertaining to that customer’s installation gathered across all the involved systems. • A customer service agent could ask to be notified about changes to a particular license’s context to monitor what happens to a particular customer -maybe they already had a problem and were asked to try again. The 20 customer agent now knows what is happening as soon as it happens.

In this same example another simple for-each rule across installation phase would store in its context counts of how many licenses were at each stage. The following processes could operate on and within that context. The vendor can have a visual display that indicates changes to the counts at each stage as they happen 25 allowing the vendor to monitor in real time the process of installations across the - 18 - 2010212459 14 Jun2016 entire customer base. The vendor can generate an alert event if the time to install the software takes longer than a threshold value. The alert event would trigger an investigation into the potential problem. Where an investigation results in new actions being taken and events are subsequently emitted from those actions, these 5 events can be tracked and correlated by other system rules with the original event data stream responsible for the problem.

ADVANTAGES

It is an advantage of the preferred embodiment to provide real time 0 operational intelligence on matters that affect a business.

The method is a new approach to handling and analyzing large quantities of data. Rather than use a modified SQL approach, the method provides state management and rules procedural framework for maximum flexibility. That is, the method converts the data to a particular format and then apply rules to process the 5 data. Consequently any type of data can be captured and analyzed.

With the rules engine of the preferred embodiment, a single rule can be implemented to detect and correlate events regardless of origin. The rules engine provides a generic way to merge event data sourced from different origins, but with a common reference point. This allows the application of rules irrespective of the type 20 of data. Furthermore the rules engine implements a novel approach to combining both snapshot and longitudinal event data in a single data representation, subsequently able to be provided as input to business rules. The single data representation allows for storage efficiency, as well as manipulation and query efficiency not available to other systems which implement separate storage systems 25 for each event data type. - 19 - 2010212459 14 Jun2016

The rules engine of the preferred embodiment has inherent optimization in the storage of event states as the aggregate of many different event sources. The single data representation allows for storage efficiency, as well as manipulation and query efficiency not available to other systems which implement separate storage systems 5 for each event data type and origin.

The rules engine has inherent optimization in the storage of event summaries as the aggregate of many different event values. The single data representation allows for storage efficiency, as well as manipulation and query efficiency not available to other systems which implement separate storage systems for non-0 summarized and summarized event data types.

The rules engine of the preferred embodiment implements a functionally powerful description language, but includes fine grained control over events, drawn from its procedural (rather than relational) heritage. Unlike other event data query languages, the absence of a relational layer as a precursor to event data 5 manipulation allows for advantages in terms of system footprint and dependencies, as well as efficiencies in terms of software implementation required.

The rules engine of the preferred embodiment can persist event state or event summary data for an arbitrary (including indefinite) period as defined by a time or sequence window. This feature differentiates the rules engine from other systems 20 which are constrained by the dimensions of time and sequence.

VARIATIONS

It will of course be realised that while the foregoing has been given by way of illustrative example of this invention, all such and other modifications and variations -20 - 2010212459 14 Jun2016 thereto as would be apparent to persons skilled in the art are deemed to fall within the broad scope and ambit of this invention as is herein set forth.

Throughout the description and claims this specification the word “comprise” and variations of that word such as “comprises” and “comprising”, are not intended to 5 exclude other additives, components, integers or steps.

The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that the prior publication (or information derived from it) or known matter forms part of the common general 0 knowledge in the field of endeavour to which this specification relates. 20 25

Claims (23)

1. A method of processing event data in an event processing network for realtime analysis of key processes of an enterprise, wherein the event processing network is a hierarchy including event agents for capturing event data, parent nodes for receiving event data from one or more event agents, and a master node at the top of the event processing network hierarchy for collecting all event data from the event agents and their parent nodes, the method including: capturing event data from each event by collecting data from an event data source using an event agent, wherein: the event agent includes: a processor including at least one of a computer and server; and at least one of a sensor and an input device including at least one of a card reader and a keypad; an agent profile is used to control the flow of data from the event data source to the event agent, in which the agent profile includes a specification of a network location of the event data source; and the event agent has a configured property which defines the event agent’s relationship with one or more parent nodes in the event processing network hierarchy; the event agent formatting the event data to a common format including the following information: date and time about the event, the event source, the event agent that collects the information, and optional fields that are particular to the type of event; the event agent forwarding the event data to the one or more parent nodes defined in the configured property, on a predetermined schedule, wherein each of the parent nodes in the event processing network is able to apply rule based processing to incoming event data from the event agents; the parent nodes processing the formatted event data by applying rules to the formatted event data using a rules engine, wherein the rules are preset so that they can operate directly on the formatted event data, and wherein the rules include at least one ‘for each one’ rule that operates on the formatted data by identifying for each one of X, then do Y; and the master node collecting all event data from the event agents and their parent nodes within the event processing network, including all processed event data, wherein the master node deploys an integration interface to allow for processed event data sourced within the event processing network to be used by other upstream external applications and by which external applications can invoke various functions within the event processing network infrastructure.

2. A method as claimed in claim 1, in which the enterprise includes any business or organization that has commercial outcomes.

3. A method as claimed in claim 1 or claim 2, in which any suitable industry standard or proprietary transport protocol is used by the event agent to connect to the event data source.

4. A method as claimed in any one of claims 1 to 3, in which the agent profile the periodicity of event data that should be captured, authentication and encryption code profile.

5. A method as claimed in any one of claims 1 to 4, in which an event schema is preferably used to transform the native event data into a normalized event data type for forward processing.

6. A method as claimed in claim 5, in which the event schema is configured at the time of storing the events so as to make the format of events consistent and the event data readily useable.

7. A method as claimed in any one of claims 1 to 6, in which the rule based processing is used to analyze incoming event data stream content in real time.

8. A method as claimed in any one of claims 1 to 7, in which the rules can include a range of different types of operations such as maintaining and incrementing counts, deriving summary or aggregate events from raw event data, and triggering conditional rules based on event data stream content.

9. A method as claimed in claim 8, in which the rules are implemented at any parent node within the event processing network.

10. A method as claimed in any one of claims 1 to 9, in which the master node can also apply rules to incoming event data streams in a similar fashion to those applied at other parent nodes within the event processing network.

11. A method as claimed in claim 10, in which there is additional rule capabilities at the master node and include the configuration and implementation of event data storage mechanisms such as for long term archiving.

12. A method as claimed in any one of claims 1 to 11, in which optional fields that are particular to the type of event are values that are meaningful with respect to the event.

13. A method as claimed in claim 12, in which the optional fields that are particular to the type of event are values that are meaningful with respect to the event including a digital fingerprint or checksum for registration of a software product or a security access profile when a card is swiped through a reader to gain access to a restricted area.

14. A method as claimed in claim 12 or claim 13, in which the optional fields include data that describes the route that the event has taken from collection to processing.

15. A method as claimed in any one of claims 1 to 14, in which the rules are any rules that have meaning to the enterprise and are able to be applied to a selection or all of the event data.

16. A method as claimed in any one of claims 1 to 15, in which after the event data has been processed it can then be presented in any suitable manner such as visually on a screen, published on paper or sent to external applications for further processing or presentation.

17. A method as claimed in any one of claims 1 to 16, in which the integration interface provides the ability to invoke additional external processes such as incident management and response workflows based on detected event data within the network or to handle configuration changes issued by external administration applications.

18. A method as claimed in any one of claims 1 to 17, in which a data visualization and analysis component is preferably deployed on top of the integration interface at the master node to allow for the display and query of event data from within the network through graphical user interfaces.

19. A method as claimed in claim 18, which can be implemented as an overlay to existing systems in the business to enable processing of events from multiple sources thereby providing a new overview of operations.

20. A method as claimed in claim 18 or claim 19, in which multiple views can be developed using event processing rules to provide business relevant information to the right people when it is of the most value empowering users to make fast and accurate decisions.

21. A method as claimed in any one of claims 1 to 20, in which events can be collected from the front office, monitoring layer, and back office to provide a view of transactions related to a customers, processes, KPIs or any metric that is important to the enterprise.

22. A method as claimed in any one of claims 1 to 21, which can be used to monitor business processes and technology across the enterprise computing environment and feed applications and humans via the response framework.

23. A method as claimed in any one of claims 1 to 22, which can unify events from different sources across the enterprise to utilize event data without making changes to applications or deploying large, complicated technology stacks.