md – object model domain esales checker presentation régis elling 26 th october 2005

MD – Object Model DomaineSales Checker Presentation

Régis Elling26th October 2005

MD-Object Model Domain / eSales Checker Presentation —All rights reserved © 2005,

Alcatel

Summary

Objectives

Solution Description

Application - eSales Checker

Conclusion

Question & Answers


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.


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.


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


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.


Alcatel

Solution Description – XML – Path 2/3> A simple Path structure – A variable

<Path>

<Member Type="Alcatel.Polaris.eSales.FrontEnd.FrameAgreement.Frame" MemberType="var" />

</Path>

> A complex Path structure with no argument – a get property

<Path Name="FA_HEADER_CURRENCY">

<Member Type="System.String">Alcatel.Polaris.eSales.FrontEnd.FrameAgreement.Frame.get_Currency</Member>

<Object>

<Path>

<Member Type="Alcatel.Polaris.eSales.FrontEnd.FrameAgreement.Frame" MemberType="var" />

</Path>

</Object>

</Path>


Alcatel

Solution Description – XML – Path 3/3> A complex Path structure with a Argument – A

method <Path>

<Member Type="Alcatel.Polaris.eSales.FE.Bll.GenericMessaging.EntityAttribute">"Alcatel.Polaris.eSales.FE.Bll.PurchaseOrder.POOrderLine.GetAttribute(System.String)

</Member>

<Object>

<Path>

<Member Type="Alcatel.Polaris.eSales.FE.Bll.PurchaseOrder.POOrderLine" MemberType="var" />

</Path>

</Object>

< Argument>

<Value Type="System.String">UnitPrice</Value>

</Argument>

</Path>


Alcatel

Solution Description – Object model


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.


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.


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.


Alcatel

Application – eSales Checker


Alcatel


> 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)


Alcatel


> 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.


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.


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.


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.


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.


Alcatel

Question & Answers

md – object model domain esales checker presentation régis elling 26 th october 2005

Documents