Abstract:
Systems, methods, and other embodiments associated with complex event pattern building are described. One example method includes receiving, on a server-side, requests associated with user interactions with interactive menus. The method includes responding to the requests with commands that build a set of event-condition-action, data that describes an action to take in response to an occurrence of a complex event pattern. The example method may also include automatically converting the event-condition-action data into a programmatic construct that configures a complex event pattern engine to initiate the specified action in response to detecting an occurrence of the complex event pattern.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims the benefit of U.S. provisional patent application Ser. No. 60/999,888, filed on Oct. 22, 2007; inventor Aravind Yalamanchi, and assigned to the present assignee, which is hereby incorporated by reference in its entirety. 
         [0002]    This application is related to U.S. patent application Ser. No. 10/815,220 entitled “Managing event-condition-action rules in a database system,” filed on Mar. 30, 2004, docket number OID-2003-248-01, and published as US-2005-0222996-A1. 
     
    
     COPYRIGHT NOTICE 
       [0003]    A portion of the disclosure of this patent document contains material subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 
       BACKGROUND 
       [0004]    In data processing environments, complex patterns of events representing exceptions, threats, and opportunities occur across application space and time, Businesses can benefit from identifying these patterns and responding automatically. Complex event processing (CEP) is designed to model event patterns, filter, aggregate, and store event histories, and respond to complex event patterns in real time. Typical complex event processing engines employ a rich type system to model events, and define a language to allow declarative specification of event patterns. Some conventional CEP engines model their type system after relational databases. These systems use SQL-like predicates to describe operations on contents of events. This type of system may be difficult for a typical business user without technical training to approach. Furthermore, CEP engines based on Java® type systems may also be difficult to approach for a business user without technical training. 
         [0005]    For example, some typical CEP engines employ complex language constructs to allow event pattern specification. This may cause languages used to define event patterns to be highly technical. Unlike IT applications that are developed once and deployed, complex event patterns that identify exceptions, threats, and opportunities in business applications may be highly dynamic, and may be created and managed by non-technical business users. Creating a language that is detailed enough to capture a broad array of complex event patterns and making it friendly for a business user is challenging. Additionally, some CEP engine vendors offer a thick client user interface tool that allows building and visualizing event patterns. However, due to the underlying languages utilized for defining event patterns, these tools may still be technical in nature and may not be able to be part of larger applications suites catered for business users. Furthermore, the thick client user interface may make it difficult and/or expensive to operate conventional systems on multiple clients and from mobile devices. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0006]    The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate various example systems, methods, and other example embodiments of various aspects of the invention. It will be appreciated that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one example of the boundaries. One of ordinary skill in the art will appreciate that in some examples one element may be designed as multiple elements or that multiple elements may be designed as one element. In some examples, an element shown as an internal component of another element may be implemented as an external component and vice versa. Furthermore, elements may not be drawn to scale. 
           [0007]      FIG. 1  illustrates an example method associated with complex event pattern building. 
           [0008]      FIG. 2  illustrates an example method associated with complex event pattern building. 
           [0009]      FIG. 3  illustrates an example system associated with complex event pattern building. 
           [0010]      FIG. 4  illustrates an example system associated with complex event pattern building. 
           [0011]      FIG. 5  illustrates an example computing environment in which example systems and methods, and equivalents, may operate. 
           [0012]      FIG. 6  illustrates an example method associated with complex event pattern building. 
       
    
    
     DETAILED DESCRIPTION 
       [0013]    Systems and methods associated with complex event pattern (EP) building are described.  FIG. 7  illustrates an environment in which example systems and methods may operate.  FIG. 7  illustrates a thin client  710 , a middle-tier  720 , and a database  730 . Database  730  includes a set of aliases and abstractions of common constructs  732 . Database  730  also includes a CEP vocabulary  734  that may include metadata and rules. In one example, a first action  1  may include loading a CEP pattern and/or rule from the database  730  into the middle tier  720 . A second action  2  may include loading aliases and/or abstractions from the database  730  into the middle tier  720 . A third action  3  may including mapping the memory representation to the thin client  710  representation. In one example the thin client  710  representation may be in HTML. A fourth action  4  occurs when a user operates on the tree in the thin client  710 . A set of fifth actions  5  includes incremental operations on the tree with partial refreshes. A sixth action  6  includes confirming changes to the CEP pattern. After confirming the changes, a seventh action  7  includes persisting the changes by writing to the database  730 . 
         [0014]    In one example, a user makes a selection on a set of interactive menus that include information associated with events, conditions, and actions. The event patterns may be modeled as event-condition-action (ECA) rules, and the interactive menus may be presented by a thin client for pattern manipulation. In one example, the thin client may be an HTML web client. Implementing the interactive menus in an HTML web client may facilitate modification of ECA rules without requiring a large application to be downloaded or installed. Further, a thin client may facilitate modification of ECA rules on mobile devices. The thin client may also allow the user to view the event patterns as a hierarchy of event relationships, a hierarchy of specific events, and/or a hierarchy of conditions on event content. In the thin client, the event relationships and the conditions on the contents of events are represented as a tree with nodes for each artifact. The tree can be manipulated by clicking on a node, which will in turn activate the associated menu of operations allowed on that node. This menu is driven by the pre-set rules that determine the valid operations for a specific node based on its relative position in the tree and its context information. The thin client interacts with middle-tier that receives the commands for user clicks and menu item selections and responds with instructions to modify the tree representation on the client accordingly. By maintaining an in-memory version of the tree displayed to the client tool, the middle-tier minimizes the communication and the amount of information transferred between the client and the server. Upon completing an event pattern and selecting an action to be executed when this pattern is detected in real-time, the client submits ECA data to the CEP engine. 
         [0015]    Upon receiving ECA data from the thin client, a configuration logic may configure a CEP engine to initiate an action specified by the ECA data in response to the occurrence of one or more events that match the pattern specified by the ECA data. An event pattern may include, for example, an occurrence of a single event, an occurrence of a single event under a single condition, an occurrence of multiple events under a single condition, an occurrence of single event under multiple conditions, or an occurrence of multiple events under multiple conditions. In one example, the CEP engine may be configured by adding a listener object that initiates an action described by the ECA data to a set of listener objects. The listener object may be programmed to react to an occurrence of an event pattern described by the ECA data. In another example, configuring the CEP engine may include programming the CEP engine to initiate an action in response to an occurrence of an event pattern. By using a graphical user interface including interactive menus and programmatically generating code based on input from the menus, example systems and methods may allow users to manage complex event patterns without an in depth understanding of programming. This may make CEP management more accessible to users with a limited technical background. Further, the thin client may make CEP management usable on a larger variety of systems and devices. 
         [0016]    The following includes definitions of selected terms employed herein. The definitions include various examples and/or forms of components that fall within the scope of a term and that may be used for implementation. The examples are not intended to be limiting. Both singular and plural forms of terms may be within the definitions. 
         [0017]    References to “one embodiment”, “an embodiment” 1  “one example”, “an example”, and so on, indicate that the embodiment(s) or example(s) so described may include a particular feature, structure, characteristic, property, element, or limitation, but that not every embodiment or example necessarily includes that particular feature, structure, characteristic, property, element or limitation. Furthermore, repeated use of the phrase “in one embodiment” does not necessarily refer to the same embodiment, though it may. 
         [0018]    ASIC: application specific integrated circuit. 
         [0019]    CD: compact disk. 
         [0020]    CD-R: CD recordable. 
         [0021]    CD-RW: CD rewriteable, 
         [0022]    DVD: digital versatile disk and/or digital video disk. 
         [0023]    HTTP: hypertext transfer protocol. 
         [0024]    LAN: local area network. 
         [0025]    PCI: peripheral component interconnect. 
         [0026]    PCIE: PCI express. 
         [0027]    RAM: random access memory. 
         [0028]    DRAM: dynamic RAM. 
         [0029]    SRAM: synchronous RAM. 
         [0030]    ROM: read only memory. 
         [0031]    PROM: programmable ROM, 
         [0032]    SQL: structured query language. 
         [0033]    OQL: object query language. 
         [0034]    USB: universal serial bus. 
         [0035]    XML: extensible markup language. 
         [0036]    WAN: wide area network. 
         [0037]    “Computer component”, as used herein, refers to a computer-related entity (e.g., hardware, firmware, software in execution, combinations thereof). Computer components may include, for example, a process running on a processor, a processor, an object, an executable, a thread of execution, and a computer. A computer component(s) may reside within a process and/or thread. A computer component may be localized on one computer and/or may be distributed between multiple computers. 
         [0038]    “Computer communication”, as used herein, refers to a communication between computing devices (e.g., computer, personal digital assistant, cellular telephone) and can be, for example, a network transfer, a file transfer, an applet transfer, an email, an HTTP transfer, and so on. A computer communication can occur across, for example, a wireless system (e.g., IEEE 802.11), an Ethernet system (e.g., IEEE 802.3), a token ring system (e.g., IEEE 802.5), a LAN, a WAN, a point-to-point system, a circuit switching system, a packet switching system, and so on. 
         [0039]    “Computer-readable medium”, as used herein, refers to a medium that stores signals, instructions and/or data. A computer-readable medium may take forms, including, but not limited to, non-volatile media, and volatile media. Non-volatile media may include, for example, optical disks, magnetic disks, and so on. Volatile media may include, for example, semiconductor memories, dynamic memory, and so on. Common forms of a computer-readable medium may include, but are not limited to, a floppy disk, a flexible disk, a hard disk, a magnetic tape, other magnetic medium, an ASIC, a CD, other optical medium, a RAM, a ROM, a memory chip or card, a memory stick, and other media from which a computer, a processor or other electronic device can read. 
         [0040]    In some examples, “database” is used to refer to a table. In other examples, “database” may be used to refer to a set of tables. In still other examples, “database” may refer to a set of data stores and methods for accessing and/or manipulating those data stores. 
         [0041]    “Data store”, as used herein, refers to a physical and/or logical entity that can store data. A data store may be, for example, a database, a table, a file, a data structure (e.g. a list, a queue, a heap, a tree) a memory, a register, and so on. In different examples, a data store may reside in one logical and/or physical entity and/or may be distributed between two or more logical and/or physical entities. 
         [0042]    “Logic”, as used herein, includes but is not limited to hardware, firmware, software in execution on a machine, and/or combinations of each to perform a function(s) or an action(s), and/or to cause a function or action from another logic, method, and/or system. Logic may include a software controlled microprocessor, a discrete logic (e.g., ASIC), an analog circuit, a digital circuit, a programmed logic device, a memory device containing instructions, and so on. Logic may include one or more gates, combinations of gates, or other circuit components. Where multiple logical logics are described, it may be possible to incorporate the multiple logical logics into one physical logic. Similarly, where a single logical logic is described, it may be possible to distribute that single logical logic between multiple physical logics. 
         [0043]    An “operable connection”, or a connection by which entities are “operably connected”, is one in which signals, physical communications, and/or logical communications may be sent and/or received. An operable connection may include a physical interface, an electrical interface, and/or a data interface. An operable connection may include differing combinations of interfaces and/or connections sufficient to allow operable control. For example, two entities can be operably connected to communicate signals to each other directly or through one or more intermediate entities (e.g., processor, operating system, logic, software). Logical and/or physical communication channels can be used to create an operable connection. 
         [0044]    “Signal”, as used herein, includes but is not limited to, electrical signals, optical signals, analog signals, digital signals, data, computer instructions, processor instructions, messages, a bit, a bit stream, and so on, that can be received, transmitted and/or detected. 
         [0045]    “Software”, as used herein, includes but is not limited to, one or more executable instruction that cause a computer, processor, or other electronic device to perform functions, actions and/or behave in a desired manner. “Software” does not refer to stored instructions being claimed as stored instructions per se (e.g., a program listing). The instructions may be embodied in various forms including routines, algorithms, modules, methods, threads, and/or programs including separate applications or code from dynamically linked libraries. 
         [0046]    “User”, as used herein, includes but is not limited to one or more persons, software, logics, computers or other devices, or combinations of these. 
         [0047]    Some portions of the detailed descriptions that follow are presented in terms of algorithms and symbolic representations of operations on data bits within a memory. These algorithmic descriptions and representations are used by those skilled in the art to convey the substance of their work to others. An algorithm, here and generally, is conceived to be a sequence of operations that produce a result. The operations may include physical manipulations of physical quantities. Usually, though not necessarily, the physical quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated in a logic, and so on. The physical manipulations create a concrete, tangible, useful, real-world result. 
         [0048]    It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, and so on. It should be borne in mind, however, that these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise, it is to be appreciated that throughout the description, terms including processing, computing, determining, and so on, refer to actions and processes of a computer system, logic, processor, or similar electronic device that manipulates and transforms data represented as physical (electronic) quantities. 
         [0049]    Example methods may be better appreciated with reference to flow diagrams. For purposes of simplicity of explanation, the illustrated methodologies are shown and described as a series of blocks. However, it is to be appreciated that the methodologies are not limited by the order of the blocks, as some blocks can occur in different orders and/or concurrently with other blocks from that shown and described. Moreover, less than all the illustrated blocks may be required to implement an example methodology. Blocks may be combined or separated into multiple components. Furthermore, additional and/or alternative methodologies can employ additional, not illustrated blocks. 
         [0050]      FIG. 1  illustrates a method  100  associated with building complex event patterns. Method  100  includes, at  110 , presenting a set of interactive menus. The interactive menus may be presented by, an HTML client, a thin client, a Java® client, and so on. A thin client may not require an extensive installation. In one example, an HTML client and a Java® client may be thin clients. The set of interactive menus may be presented to a user. The interactive menus may include information associated with events, conditions and actions. The events, conditions, and actions may relate to a function performed by a complex event processing (CEP) engine. The CEP engine may relate to an application associated with, for example, radio frequency Identification (RFID), fraud, risk, sales, customer relationship management, cross-selling, data filtering, data transformation, semantic web domain node communications, and so on. 
         [0051]    Possible events may include, an update to a database, a receipt of a purchase order, a change to a stored value, a receipt of a signal, a user driven input, and so on. Possible conditions may include, a state of an attribute of an event, an occurrence of an event, a nonoccurrence of an event, an occurrence of a set of events, an occurrence of a set of events within a pre-defined time period, an occurrence of a sequence of a set of events, an occurrence of a subset of a set of events, an occurrence of an aggregation of a set of events, and so on, which could model scenarios such as potential threats, exceptions and opportunities. Possible actions may include, a change to a database, a provision of a signal, a change to a stored value, a notification to a user, an initiation of a function, and so on. 
         [0052]    For example, a first event may be a purchase of, from a series of five books, the first book in the series, a second event may be a purchase of the second book in the series, a third event may be a purchase of the third book in the series, and so on. Some example conditions may include the occurrence of the first event and the occurrence of the second event within one week of each other, the occurrence of the first event and the occurrence of the third event without the occurrence of the second event, and so on. These events and events occurring under a condition describe different complex event patterns in response to which various actions may be taken. A possible action to take in response to the occurrence of the first event may be to offer the second book in the series at a discount. A possible action to take in response the occurrence of the first event and the occurrence of the third event without the occurrence of the second event may be to notify the purchaser that they may have missed the second book in the series. One skilled in the art can see how other events, conditions, actions, and combinations thereof may be employed. 
         [0053]    Method  100  also includes, at  120 , receiving a set of event-condition-action (ECA) data. The ECA data may be received in response to a selection being made on an interactive menu. The ECA data may include data identifying an event, a condition, and/or an action. 
         [0054]    The ECA data may identify actions to perform in response to detecting events occurring under conditions. The action may also be performed in response to an occurrence of a complex event pattern. An event pattern may include a set of events, and a set of conditions associated with the set of events. An event pattern may include, for example, an occurrence of a single event, an occurrence of a single event under a single condition, an occurrence of multiple events under a single condition, an occurrence of single event under multiple conditions, or an occurrence of multiple events under multiple conditions. 
         [0055]    Example event patterns related to book purchasing may include, a purchase of a first book in a series, a purchase of a first book in a series during a specific time period, a purchase of a first book in a series and a purchase of a second book in the series within a predefined time window, a purchase of a first book in a series during a sale period after a predefined time, a purchase of a first book in a series and a purchase of a second book in the series within a predefined time window and without the purchase of a third book in the series, and so on. While a book selling example is provided above, one skilled in the art will appreciate that CEP may be employed in other areas (e.g. RFID, fraud, risk, sales, and so on). 
         [0056]    Method  100  also includes, at  130 , configuring a CEP engine to initiate an action in response to detecting an occurrence of events matching the specified pattern. Detecting the occurrence may be based, at least in part, on the ECA data. In one example, configuring the CEP engine may include adding a listener object that initiates an action described by the ECA data to a set of listener objects. In this example, the listener object may be programmed to detect an occurrence of events described by the ECA data. In another example, configuring the CEP engine may include programming the CEP engine to initiate an action described by the ECA data in response to detecting an occurrence of events matching the pattern described by the ECA data. 
         [0057]    Method  100  also includes, at  140 , storing the ECA data in a data store. The ECA data may be stored as, for example, a hierarchy of event relationships, a hierarchy of events, a hierarchy of conditions on event content, and so on. A hierarchy may be stored as, for example, a tree, an array, a linked list, a database, a table, and so on. In one example, the data store may also include the information associated with events, conditions, and actions presented at  110 . In another example, the ECA data may be stored to facilitate the provision of a graphical representation of a portion of a hierarchy of ECA relationships stored in the data store. In another example, ECA data may be stored to facilitate backing up and/or restoring one or more configurations associated with the CEP engine. 
         [0058]    Below is example code based on XML and SQL associated with a security application. The code may be generated at  130  in relation to configuring the CEP engine. 
         [0000]    
       
         
               
             
           
               
                   
               
             
             
               
                 ON 
               
               
                 BankTransaction (subjectId, transType, amount, fundFrom) bank, 
               
               
                 Transportation (subjectId, vesselType, ..., endDate) transport, 
               
               
                 FieldReport (subjectId, rptType, whoWith, ...) fldrpt 
               
               
                 IF 
               
               
                  &lt;condition&gt; 
               
               
                  &lt;and&gt; 
               
               
                   &lt;object name=“bank”&gt; 
               
               
                   tranType = ‘Transfer’ and amount &gt; 10000 and fundFrom != ‘USA’ 
               
               
                   &lt;/object&gt; 
               
               
                   &lt;object name=“transport”&gt; 
               
               
                    vesselType = ‘Truck’ and locFrom != locTo and 
               
               
                      IsRestrictedArea(locTo) = 1 
               
               
                   &lt;/object&gt; 
               
               
                   &lt;not by=“SYSTIMESTAMP+1”&gt; 
               
               
                   &lt;object name=“fldrpt”&gt; 
               
               
                    rpttype = ‘BACKGROUNDCHECK’ and EXTRACT(RPTBODY, 
               
               
                      ‘/history/arrests[@number=0]’) IS NOT NULL 
               
               
                   &lt;/object&gt; 
               
               
                   &lt;/not&gt; 
               
               
                  &lt;/and&gt; 
               
               
                  &lt;/condition&gt; 
               
               
                 THEN 
               
               
                  PerformAction(‘ADD2HIGHRISKAREA’, transport.locTo) 
               
               
                   
               
             
          
         
       
     
         [0059]    This code segment acts upon detecting a bank transaction event, a transportation event, and a field report event all associated with a subject. The code segment makes a series of checks on incoming events to determine if action is necessary. The code checks the bank transaction event to see if the transaction is greater than $10000 and if it originated outside the United States. The code also checks, for the transport event, to see if the vessel type is a truck, and if the destination of the subject is a restricted area and there is no matching instance of field report event within a 24 hour window. If the conditions checked by the code match the event pattern, the code initiates an action of labeling the destination of the subject as high risk. The matching of the events with the specified event patterns is performed incrementally as the events are streamed into the CEP engine. In this respect each event pattern behaves like a state machine, which initiates the corresponding action when it reaches an accepting state. One skilled in the art can see how other events, conditions, actions, and combinations thereof may be employed to perform other tasks. 
         [0060]    While  FIG. 1  illustrates various actions occurring in serial, it is to be appreciated that various actions illustrated in  FIG. 1  could occur substantially in parallel. By way of illustration, a first process could present a set of interactive menus, a second process could receive a set of ECA data, and a third process could configure the CEP engine. While three processes are described, it is to be appreciated that a greater and/or lesser number of processes could be employed and that lightweight processes, regular processes, threads, and other approaches could be employed. 
         [0061]    In one example, a method may be implemented as computer executable instructions. Thus, in one example, a computer-readable medium may store computer executable instructions that if executed by a machine (e.g., processor) cause the machine to perform a method. While executable instructions associated with the above method are described as being stored on a computer-readable medium, it is to be appreciated that executable instructions associated with other example methods described herein may also be stored on a computer-readable medium. 
         [0062]    In one example, data structures may be constructed that facilitate storing data on a computer-readable medium and/or in a data store. Thus, in one example, a computer-readable medium may store a data structure that includes, a first field for data associated with events, a second field for data associated with conditions, and a third field for data associated with actions. With this “raw” data available, the data structure may also include a fourth field for storing CEP data that is derived from data located in one or more of the first through third fields. While four fields are described, it is to be appreciated that a greater and/or lesser number of fields could be employed. 
         [0063]      FIG. 2  illustrates a method  200  associated with building a complex event pattern. Method  200  includes several actions similar to those described in connection with method  100  ( FIG. 1 ). For example, method  200  includes presenting a set of interactive menus at  210 , receiving a set of ECA data at  220 , configuring a CEP engine at  230 , and storing the ECA data at  240 . However, method  200  also includes, at  250 , controlling the CEP engine to initiate the action. The action may be initiated in response to the CEP engine detecting an occurrence of events matching a pattern specified by the ECA data. For example, in response to detecting that a person has purchased a first book in a series of books, and a second book in the series, but has not purchased a third book in the series, the CEP engine may be controlled to notify the person that they may be missing a book. The CEP engine may also be controlled to offer the third book in the series at a discount or as a package to encourage the person to purchase the book. 
         [0064]      FIG. 3  illustrates a system  300  associated with building a complex event pattern. System  300  includes a user interface logic  310 . User interface logic  310  may provide a set of interactive menus. The interactive menus may be provided by, an HTML client, a thin client, a Java® client, and so on. A thin client may not require an extensive installation. In one example an HTML client and a Java® client may be thin clients. The set of interactive menus may be provided to a user. The interactive menus may include information associated with events, conditions, and actions. The events, conditions, and actions may be associated with real world business tasks including sales, inventory management, finances, and so on. The events, conditions, and actions may relate to a function performed by a complex event processing (CEP) engine. The function may be, for example, offering a discount, arranging a shipment, initiating a money transfer, and so on. The CEP engine may relate to an application associated with, for example, RFID, fraud, risk, sales, customer relationship management, cross-selling, data filtering, data transformation, semantic web domain node communications, and so on. 
         [0065]    Possible events may include, an update to a database, a receipt of a purchase order, a change to a stored value, a receipt of a signal, a user driven input, and so on. Possible conditions may include, a state of an attribute of an event, an occurrence of an event, a nonoccurrence of an event, an occurrence of a set of events, an occurrence of a set of events within a pre-defined time period, an occurrence of a sequence of a set of events, an occurrence of a subset of a set of events, an occurrence of an aggregation of a set of events, and so on. Possible actions may include, a change to a database, a provision of a signal, a change to a stored value, a notification to a user, an initiation of a function, and so on. 
         [0066]    System  300  also includes, a CEP logic  320  to present the event metadata and the valid event pattern constructs in the form of interactive menus to the user-interface logic  310 . An event pattern is represented as a hierarchy of nodes consisting of the events, conditions on the contents of the events as well as the complex relationships that exist between the events. Possible transformations on each node of the event pattern tree are controlled by the relative position of the node in the tree as well as the context information. The end-user communicates his intent to manipulate the event pattern by clicking on a relevant node as represented in the thin client. The CEP logic  320  receives this request and based on the current state of the tree and the rules involving the CEP patterns generates a list of valid operations on the selected node. Depending on the type and context of the node selected, the valid operations could be to add a condition on the content of the event, add a specific event to occur in conjunction with other events, add a predicate for the detecting the events occurring within a time-window and so on. The list of valid operations generated by the CEP logic  320  is communicated back to the user-interface logic  310 , which in turn displays them in an interactive menu. The CEP logic  320  also receives the requests arising from the selections made on the interactive menus. The CEP logic  320  processes the requests by making necessary modification to the in-memory version of the event pattern tree and sends back commands to user-interface logic  310  to make similar modifications to the tree displayed in the thin-client. The CEP logic  320 , by maintaining an in-memory version of the evolving event pattern and encapsulating the logic that controls the possible operations on the tree, minimizes the communication and the amount of information transferred between the user-interface logic  310  and the CEP logic  320 . The CEP logic  320  aids in the building of ECA data for a rule that, includes a complete event pattern with specific conditions and the possible actions to perform in response to detecting events occurring under conditions expressed by the event patterns. An event pattern constructed using the CEP logic  320  and the user-interface logic  310  may include a set of events and a set of conditions associated with the set of events. An event pattern may include, for example, an occurrence of a single event, an occurrence of a single event under a single condition, an occurrence of multiple events under a single condition, an occurrence of single event under multiple conditions, or an occurrence of multiple events under multiple conditions, 
         [0067]    System  300  also includes a preparation logic  330 . Preparation logic  330  may prepare a CEP engine to initiate an action in response to detecting the occurrence of events based, at least in part, on the ECA data. In one example, preparing the CEP engine may include adding a listener object that initiates an action described by the ECA data to a set of listener objects. In this example, the listener object may be programmed to detect an occurrence of events matching the pattern described by the ECA data. In another example, preparing the CEP engine may include programming the CEP engine to initiate an action described by the ECA data in response to detecting an occurrence of events matching the pattern described by the ECA data. In one example, the XML and SQL based code sample shown above may be generated by the CEP engine based on the final representation of the ECA data and used by preparation logic  330  to prepare the CEP engine. 
         [0068]    System  300  also includes a data store  340 . Data store  340  may store the ECA data. ECA data may be stored in the data store by the CEP logic. The ECA data may be stored as, for example, a hierarchy of event relationships, a hierarchy of events, a hierarchy of conditions on event content, and so on. A hierarchy may be stored as, for example, a tree, an array, a linked list, a database, a table, and so on. In one example, the database may also include the information associated with events, conditions, and actions provided by the user interface logic  310 . In another example, the ECA data may be stored in data store  340  to facilitate providing a graphical representation of a portion of a hierarchy of ECA relationships stored in data store  340  by user interface logic  310 . In another example, ECA data may be stored in data store  340  to facilitate backing up, restoring, preparing, and/or re-preparing the CEP engine by preparation logic  320 . 
         [0069]      FIG. 4  illustrates a system  400  associated with building a complex event pattern. System  400  includes several items similar to those described in connection with system  300  ( FIG. 3 ). For example, system  400  includes an user interface logic  410 , a CEP logic  420 , a preparation logic  430 , and a data store  440 . However, system  400  also includes a CEP engine  450 . CEP engine  450  may initiate the action CEP engine  450  was prepared to perform in response to detecting an occurrence of the events matching a pattern the CEP engine  450  was prepared to detect. The action may be initiated in response to the CEP engine detecting an occurrence of events matching a pattern specified by the ECA data. For example, in response to detecting that a person has purchased a first book in a series of books, and a second book in the series, but has not purchased a third book in the series, the CEP engine may be controlled to notify the person that they may be missing a book. The CEP engine may also be controlled to offer the third book in the series at a discount or as a package to encourage the person to purchase the book. 
         [0070]      FIG. 5  illustrates an example computing device in which example systems and methods described herein, and equivalents, may operate. The example computing device may be a computer  500  that includes a processor  502 , a memory  504 , and input/output ports  510  operably connected by a bus  508 . In one example, the computer  500  may include a complex event pattern logic  530  configured to facilitate building event patterns. In different examples, the logic  530  may be implemented in hardware, software, firmware, and/or combinations thereof. While the logic  530  is illustrated as a hardware component attached to the bus  508 , it is to be appreciated that in one example, the logic  530  could be implemented in the processor  502 . 
         [0071]    Thus, logic  530  may provide means (e.g., hardware, software, firmware) for presenting a set of interactive menus that include information associated with events, conditions, and actions, where the events conditions and actions relate to a function performed by a CEP engine. Logic  530  may also provide means (e.g., hardware, software, firmware) for receiving, in response to a selection being made on an interactive menu, a set of ECA data that includes data identifying one or more of, an event, a condition, and an action. The action may be performed in response to an event pattern including a set of events and a set of conditions associated with the set of events. Logic  530  may also provide means (e.g., hardware, software, firmware) for configuring a CEP engine to initiate an action in response to detecting the occurrence of events. Detecting the occurrence may be based, at least in part, on the ECA data. Logic  530  may also provide means (e.g., hardware, software, firmware) for storing the ECA data. The means associated with logic  630  may be implemented, for example, as an ASIC. The means may also be implemented as computer executable instructions that are presented to computer  500  as data  516  that are temporarily stored in memory  504  and then executed by processor  502 . 
         [0072]    Generally describing an example configuration of the computer  500 , the processor  502  may be a variety of various processors including dual microprocessor and other multi-processor architectures. A memory  504  may include volatile memory and/or non-volatile memory. Non-volatile memory may include, for example, ROM, PROM, and so on, Volatile memory may include, for example, RAM, SRAM, DRAM, and so on. 
         [0073]    A disk  506  may be operably connected to the computer  500  via, for example, an input/output interface (e.g., card, device)  518  and an input/output port  510 . The disk  506  may be, for example, a magnetic disk drive, a solid state disk drive, a floppy disk drive, a tape drive, a Zip drive, a flash memory card, a memory stick, and so on. Furthermore, the disk  506  may be a CD-ROM drive, a CD-R drive, a CD-RW drive, a DVD ROM drive, a Blu-Ray drive, an HD-DVD drive, and so on. The memory  504  can store a process  514  and/or a data  516 , for example. The disk  506  and/or the memory  504  can store an operating system that controls and allocates resources of the computer  500 . 
         [0074]    The bus  508  may be a single internal bus interconnect architecture and/or other bus or mesh architectures. While a single bus is illustrated, it is to be appreciated that the computer  500  may communicate with various devices, logics, and peripherals using other busses (e.g., PCIE, 1394, USB, Ethernet). The bus  508  can be types including, for example, a memory bus, a memory controller, a peripheral bus, an external bus, a crossbar switch, and/or a local bus. 
         [0075]    The computer  500  may interact with input/output devices via the i/o interfaces  518  and the input/output ports  510 . Input/output devices may be, for example, a keyboard, a microphone, a pointing and selection device, cameras, video cards, displays, the disk  506 , the network devices  520 , and so on. The input/output ports  510  may include, for example, serial ports, parallel ports, and USB ports. 
         [0076]    The computer  500  can operate in a network environment and thus may be connected to the network devices  520  via the i/o interfaces  518 , and/or the i/o ports  510 . Through the network devices  520 , the computer  500  may interact with a network. Through the network, the computer  500  may be logically connected to remote computers. Networks with which the computer  500  may interact include, but are not limited to, a LAN, a WAN, and other networks. 
         [0077]      FIG. 6  illustrates a method  600  associated with complex event pattern building. Method  600  may be performed by a computer system having a graphical user interface. The graphical user interface may include a display and a selection device. Method  600  may be associated with providing and selecting from a set of data entries on the display. Method  600  includes, at  610 , retrieving a set of data entries. The set of data entries may be received from a data store associated with a CEP engine. A data entry may represent a construct in the event pattern or an action to perform in response to the occurrence of the events. Method  600  also includes, at  620 , displaying the set of data entries on the display in a set of interactive menus. The interactive menus may allow a business user without technical training to visualize and manipulate data associated with the CEP engine without learning programming skills. 
         [0078]    Method  600  also includes, at  630 , receiving a data entry selection signal from the set of interactive menus. The data entry selection signal may be indicative of the selection device selecting a selected data entry. For example a user may select a condition (e.g. a temporal relationship, a conjunction relationship, a disjunction relationship, and so on) from a member of the set of interactive menus to be applied to a set of events to create an event pattern. The user may then select an action from a member of the set of interactive menus to be performed in response to the newly created event pattern. Method  600  also includes, at  640 , configuring a CEP engine in response to the data entry selection signal. The CEP engine may be configured to initiate an action in response to an occurrence of some events that match the specified pattern. For example, the CEP engine may be configured by programmatically generating the XML and SQL based code sample shown above and storing it in a data store. 
         [0079]    While example systems, methods, and so on have been illustrated by describing examples, and while the examples have been described in considerable detail, it is not the intention of the applicants to restrict or in any way limit the scope of the appended claims to such detail. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the systems, methods, and so on described herein. Therefore, the invention is not limited to the specific details, the representative apparatus, and illustrative examples shown and described. Thus, this application is intended to embrace alterations, modifications, and variations that fall within the scope of the appended claims. 
         [0080]    To the extent that the term “includes” or “including” is employed in the detailed description or the claims, it is intended to be inclusive in a manner similar to the term “comprising” as that term is interpreted when employed as a transitional word in a claim. 
         [0081]    To the extent that the term “or” is employed in the detailed description or claims (e.g., A or B) it is intended to mean “A or B or both”. When the applicants intend to indicate “only A or B but not both” then the term “only A or B but not both” will be employed. Thus, use of the term “or” herein is the inclusive, and not the exclusive use. See, Bryan A. Gamer, A Dictionary of Modern Legal Usage 624 (2d. Ed. 1995). 
         [0082]    To the extent that the phrase “one or more of, A, B, and C” is employed herein, (e.g., a data store configured to store one or more of, A, B, and C) it is intended to convey the set of possibilities A, B, C, AB, AC, BC, ABC, AAA, AAB, AABB, AABBC, AABBCC, and so on (e.g., the data store may store only A, only B, only C, A&amp;B, A&amp;C, B&amp;C, A&amp;B&amp;C, A&amp;A&amp;A, A&amp;A&amp;B, A&amp;A&amp;B&amp;B, A&amp;A&amp;B&amp;B&amp;C, A&amp;A&amp;B&amp;B&amp;C&amp;C, and so on). It is not intended to require one of A, one of B, and one of C. When the applicants intend to indicate “at least one of A, at least one of B, and at least one of C”, then the phrasing “at least one of A, at least one of B, and at least one of C” will be employed.