2 Replies Latest reply: Nov 11, 2008 11:12 AM by scot RSS

    Primitive vs Composite Event Architecture Decision

      I am exploring the use of rules manager in a product pricing application. There are two primitive events of interest: item cost change and item price change.

      A complete set of rules and workflow can be managed, individually, for each of these events. Reps might be interested if an item changes cost. Customers if an item changes price. Whatever.

      Also, there is interest in composite events, such as a cost increase without a corresponding price increase within a week.

      First, I can't be the only one exploring rules manager for pricing related activities. If anyone else is doing so, or knows of a good article / case study specific to this domain, I'd love to read more.

      But second, my main question revolves around how to design such a structure. I see two main options, and I'm too new at this to know which one is the better approach.

      1. Define 3 event structures (cost, price, composite). Define 3 corresponding rule classes (2 primitive, 1 composite), each with their own callbacks, result views, etc. Manage three (smaller and more specific / seperate) sets of rules and actions, each one specific to an event type. When a cost change event comes in, process it twice, once to the cost_event, and once to the cost_price_comp_event. Keeps the primitive event conditions simple and isolated, with fewer to define that are in xml form. Fewer rules to evaluate per evaluation, but one extra evaluation.

      2. Define 3 event structures as before, but only one, composite, rule class. All rules, both single object and composite, managed inside this one, larger, structure. Seems less modular, and if you've already got sets of primitive rules defined you'd have to migrate them. But, when a cost change event comes in, you'd only have to process it once against the composite structure.

      Thanks for any insight on these matters you can provide.
        • 1. Re: Primitive vs Composite Event Architecture Decision

          Although we do not have any case studies, we have customers using Rules Manager for variety of applications such as CRM rules, product licensing, tax code, and label generation for a shipping company.

          Regarding the second question, your analysis of the two approaches is good. One additional factor that could help you pick one approach over the other is any inter-rule dependencies that exist within a rule class. For example, if more than one rule matches a set of events and only one of them should finally execute the action, it can be modeled using Exclusive consumption policy. If simple and composite rules are defined in the same rule class, such policies are enforced on the combined set of rules and this should be taken into account.

          As you said, the primitive rules defined in a composite rule class use an extended SQL-XML syntax. But migrating existing simple rules to composite rules is straight forward and can be done with a simple INSERT as SELECT statement.
             insert into composite_rules (rlm$ruleid, rlm$rulecond) (select rlm$ruleid, 
                <object name="pm_event_name">
             </condition>') from simple_rules); 
          The XML syntax is further hidden from the end-users when the application is managed using the  [UI Application|http://www.oracle.com/technology/products/database/rules_manager/rlmui_viewlet_swf_0.html]  (that can be downloaded from the  [rules manager page|http://www.oracle.com/technology/products/database/rules_manager/index.html]). Appropriate action preferences can be used to clearly distinguish the primitive rules from the composite rules. 
          Rules Manager evaluates the rule conditions as a set and breaking up the rules into smaller sets may not yield any performance benefits. Only exception is if the evaluation of the rules in the composite rule class is conditional and is based on the outcome of the evaluation of the primitive rules. But if the rules in primitive and composite rules classes are evaluated for each incoming event, the cost of two rule evaluation calls will always exceed the one such call on a consolidated rule class. 
          Please let me know if you have any questions. 
          • 2. Re: Primitive vs Composite Event Architecture Decision
            Thanks Aravind for your thoughts, and for responding so quickly.

            I'll take some time to think about this further.