Weitere Kapitel dieses Buchs durch Wischen aufrufen
Target audience Developer, rule author, business analyst (may skip 3.3) In this chapter you will learn The structure of rule projects in JRules The different components of a rule project Rule project relationships and their importance in modularizing rule development The Business Object Model (BOM), which is used for rule authoring, and how to build it from the application (or executable) object model Best practices for organizes organizing rules, and the artifacts they depend on, in rule projects Best practices for the design of a stable and flexible BOM Key points Getting the rule project structure right is an important first step in rule authoring. Rule project dependencies can be used to modularize rule development and to maximize the reuse of rule artifacts. The BOM to XOM mapping is a powerful mechanism for obtaining a vocabulary that embodies business needs from an application model geared towards IT needs. The BOM update and refactoring capabilities of Rule Studio enable us to selectively propagate some changes from the XOM to the BOM, and to shield the BOM – and rules – from the others.
Bitte loggen Sie sich ein, um Zugang zu diesem Inhalt zu erhalten
Sie möchten Zugang zu diesem Inhalt erhalten? Dann informieren Sie sich jetzt über unsere Produkte:
Almost. More on this later.
If a rule project depends on another rule project, the domain of the query will be extended to include the rules included in that project. And so on (recursively). More on project dependencies in Sect. 10.2.2.
JRules comes with a predefined set of rule properties, but developers can extend the rule model and add organization or application-specific metadata.
On some level, a rule is like a query: the condition part ‘queries’ the working memory for tuples of objects satisfying some conditions, and the action part applies some actions to the result.
More about this in Sect. 10.3.
Not true, but an acceptable first approximation.
This means that a regular rule author cannot edit projects’ dependencies, and that is a good thing, because of the subtle implications on rule writing (BOM visibility, variable visibility, etc.).
This is counter-intuitive to inheritance, where locally defined structures and behavior prime over inherited ones.
We don’t have a table for each rule project element types as similar element types are represented by the same table, but have one attribute distinguish between them.
Actually, in this case only the one about the threshold birthdate for the policy holder is substantive. The others are due to small – non essential – differences in serialization format between the two environments.
One reason we may want to do that is if deployment to the Rule Execution Server (RES) of the development, testing, QA, or production environment is performed from RS as opposed to from RTS, which is the recommended practice.
We can do that by removing a user group from the groups of users who have the right to access the project. By doing so, the project no longer shows up in their project selection in RTS.
We have also encountered situations where IT developers are transferred, administratively, from the IT department over to business units where they report to a manager within the business unit.
SCM files deal in files: they do not know about rule projects, rule packages, and the like, and thus, performing a (text) file-based reconciliation of two rule project versions is typically tedious and error prone.
JRules includes Office plug-ins that enables to edit rules in Word documents, and decision tables in Excel spreadsheets. See Chap. 8.
When the selection of a property does not make sense or when “all” is implied by default, the property parameter takes the value “-.”
In this case, the permission <Update, No, Technical Rule, *> may not even be needed, as what is not explicitly allowed is not permitted by default … unless we have a more generic permission such as <Update, Yes, *, - > that we want to override for Technical Rules. And so forth.
We can all thank Java, C++, C, or the assembly language for this numbering convention, depending on how far back you want to go ☺.
So which object model do we refer to in the BOM to XOM mapping? Logically, this should be the XOM, as we are showing how BOM elements map to XOM elements. In practice, we can refer to the BOM, and to any Java object model referenced in the rule project, included but not limited to the XOM. Thus to access the attribute “date” of Claim, I can use either “myClaim.date” or “myClaim.getDate().”
The BOM to XOM mapping is used by the engine during run-time. Further, IRL functions can refer to BOM virtual functions. If we allow IRL functions to be called normally within the BOM to XOM mapping, we could end up with an arbitrarily long – and potentially circular – translation sequence from BOM to XOM.
The Java type for ?instance is ilog.rules.engine.IlrRuleInstance.
This feature of JRules has been around since 2002, i.e. prior to JDK 1.5 (which came out in the fall of 2004) which introduced support for genericity, and the handling of collections has remained unchanged for backward compatibility reasons.
You may need to “clean” the project for the warnings to show up.
Rule queries and Eclipse search functionality enable us to ascertain that. We could also first deprecate the element then see if any rules generate “deprecated” warnings, and if none do, we could then safely delete it.
For example, if we move a data member and its accessors up the hierarchy of classes, the right thing to do would be to move the corresponding public data member up the BOM hierarchy. However, the tool cannot do that on its own: the “BOM Update” will enable us to add the member to the superclass, but will not remove it from the original class, and will not complain about it since it does have a XOM equivalent. However, if the data member is used in a rule, the rule editor will complain about an “ambiguous sentence,” meaning that two data members have the same verbalization.
It is technically possible to assign no category to a BOM element, which makes it unavailable for rule authoring, altogether.
Naturally, provided they are properly designed.
OK, maybe you do not want all of the rules that are specific to either PersonalAutoPolicy or CommercialAutoPolicy to apply to DualUseAutoPolicy’s and that is OK, because the tool allows you to pick and choose (see Sect. 10.5 about rule orchestration).
That is, it contains a minimum number of “orthogonal” concepts that can accommodate the most data or functionality needs.
Less if you use lousy naming patterns – or none at all – in your XOM/Java code.
- Rule Authoring Infrastructure in JRules
Mr. Jérôme Boyer
Prof. Hafedh Mili
- Springer Berlin Heidelberg
- Chapter 10
Neuer Inhalt/© ITandMEDIA