MD – Object Model Domain eSales Checker Presentation Régis Elling 26 th October 2005

MD-Object Model Domain / eSales Checker Presentation —Page 2 All rights reserved © 2005, Alcatel Summary  Objectives  Solution Description  Application - eSales Checker  Conclusion  Question & Answers

MD-Object Model Domain / eSales Checker Presentation —Page 3 All rights reserved © 2005, Alcatel Objectives > Functional needs Evolutive execution engine capable of performing actions (comparisons, assigments, provide execution results) on eSales structures (PO, Frame Agreement). Have a engine that can be parameterized with low costs. > Technical needs The engine must be fast in rule execution. It has to able to support a large quantity of rules and data.

MD-Object Model Domain / eSales Checker Presentation —Page 4 All rights reserved © 2005, Alcatel Solution Description - Packages > Separation of the functional needs into multiple packages The Rule Engine (called) package: – Executes rules, – Provide an execution result, – No functional knowledge. The checker (calling) package: – Prepares the rules to be executed, – Feeds the Rule Engine with the necessary data for the execution, – Interprets the results depending on the context, – Contains the functional knowledge.

MD-Object Model Domain / eSales Checker Presentation —Page 5 All rights reserved © 2005, Alcatel Solution Description – Rule Engine > Overview of the solution Entries provided: – The execution context (Object Pool), a set of objects on which the rules are to be executed. – The rule to be executed, an XML structure describing a set of actions to perform on objects. – The C# reflection API executing the actions using the Object Pool. Exits resulting: – A C# object resulting of the action of the rule (Boolean, String….) Rule Engine package (C# reflection API) Object Pool XML Rule Result object

MD-Object Model Domain / eSales Checker Presentation —Page 6 All rights reserved © 2005, Alcatel Solution Description – XML – Path 1/3 > The Path structure One Member structure representing the method, property to execute or variable to fetch, One or no Object structure representing the execution procedure to obtain an object described in the Member structure, One, many or no Argument structure representing the execution procedure to obtain the arguments necessary to execute the Member structure. > Both Object and Argument structures can contain a Path structure.

MD-Object Model Domain / eSales Checker Presentation —Page 7 All rights reserved © 2005, Alcatel Solution Description – XML – Path 2/3 > A simple Path structure – A variable > A complex Path structure with no argument – a get property Alcatel.Polaris.eSales.FrontEnd.FrameAgreement.Frame.get_Currency

MD-Object Model Domain / eSales Checker Presentation —Page 8 All rights reserved © 2005, Alcatel Solution Description – XML – Path 3/3 > A complex Path structure with a Argument – A method "Alcatel.Polaris.eSales.FE.Bll.Purchase Order.POOrderLine.GetAttribute(System.String) UnitPrice

MD-Object Model Domain / eSales Checker Presentation —Page 9 All rights reserved © 2005, Alcatel Solution Description – Object model

MD-Object Model Domain / eSales Checker Presentation —Page 10 All rights reserved © 2005, Alcatel Solution Description – Object Pool > Definition: The object Pool is a hashtable that contains instantiated objects used by the rules, which are executed by the Rule Engine. Therefore, the business layer calling the project has to initialize this set of object and provide them for execution. These objects represents the execution context. > What objects? All objects defined as variables in the XML rules to be executed. These objects are declared using the MemberType=“var” node extension, in the Member tag. These objects a related to the Business Layer calling the Rule Engine and are therefore not related to the Rule Engine project.

MD-Object Model Domain / eSales Checker Presentation —Page 11 All rights reserved © 2005, Alcatel Solution Description – Reflection API > Definition: The Reflection API allows a C# program to inspect and manipulate itself. It can be used to effectively find all the types in an assembly and/or dynamically invoke methods in an assembly. It can at times even be used to emit Intermediate Language code on the fly so that the generated code can be executed directly.

MD-Object Model Domain / eSales Checker Presentation —Page 12 All rights reserved © 2005, Alcatel Solution Description – Execution process > Initialization The XML rule provided to the Rule Engine Path objects initializes objects and links them for the execution. The Object Pool necessary for the rules execution is provided in the dedicated hashtable. > Execution Resolve Object of the Path Resolve Argument of the Path Execute Member using the Object and Argument results. Provide execution results.

MD-Object Model Domain / eSales Checker Presentation —Page 13 All rights reserved © 2005, Alcatel Application – eSales Checker

MD-Object Model Domain / eSales Checker Presentation —Page 14 All rights reserved © 2005, Alcatel Application – eSales Checker > Checker Project contains Functional aspect of the solution, a Checker rule is a combination of the following aspects: – Comparison rules to detect discrepancies in the Customer Orders (Test, Condition and NextConditions classes). – Result data to provide a summary of the detected discrepancies to the users (Valuation, CheckerResults classes). – Action to correct (if possible) the detected discrepancies (Action class) on objects in the Object Pool. Technical aspect of the solution: – All Checker classes are related to the Rule Engine project using the Path class. – The results are interpreted by the calling classes (e.g: Comparison is a Boolean stating if the test succeeded or not)

MD-Object Model Domain / eSales Checker Presentation —Page 15 All rights reserved © 2005, Alcatel Application – eSales Checker > Parameters All functional attributes (Operand class) and operations (Operator class) are defined with a XML that after execution provides the required results. The combination of Operands and Operators defines a Checker Rule. Each Operand is assigned specific attributes that enable to link it to other operands or operators. > Demo Define a rule. Execute it. Show results.

MD-Object Model Domain / eSales Checker Presentation —Page 16 All rights reserved © 2005, Alcatel Conclusion – Positive aspects > Independent of the context: The clear separation of the functional and technical aspects enables to re-use the engine in totally different contexts (e.g. eSales Enrichment process). > Evolutive: All evolutions in the calling object model can be used by adding/updating the Operands and Operators. XML can be easily used to define an execution process that answers to a specific customer need. > Performance: Though the reflection API is known to be slow, the execution results are concluding in memory cost and speed.

MD-Object Model Domain / eSales Checker Presentation —Page 17 All rights reserved © 2005, Alcatel Conclusion – Negative aspects > Complex parameters The XML (Path, Object, Argument) it not obvious when first seen and very strict in terms of writing (a space character can crash the execution). A modification in the object model has to be reflected in the parameters, they are closely linked each one to another. > Debugging is complicated If an error occurs during the execution, it is not always simple to determine what is the cause by just reading the logs.

MD-Object Model Domain / eSales Checker Presentation —Page 18 All rights reserved © 2005, Alcatel Conclusion – Axes of evolution > Project genericity Extract the ComplexOperators class from the execution process. Remove all notion of Operands and Operators from the project so that is could be used in a totally different way and context. > Improvements Improve the errors returned by the execution engine. This could handle specific cases.

MD-Object Model Domain / eSales Checker Presentation —Page 19 All rights reserved © 2005, Alcatel Conclusion – Limits > Object models are necessary To use the engine, a detailed object model has to be defined in order to create XML execution structures. > Object Pool cannot contain objects of same type The key of the Object Pool being the Type of the object, only one object of each type can be stored in it. > Complex operations have to be coded When a series of complex operations have to be performed the XML structure does not enable to describe it completely. Therefore, an algorithm handling the operation has to be developed and called in the engine.

MD-Object Model Domain / eSales Checker Presentation —Page 20 All rights reserved © 2005, Alcatel Question & Answers