0

I am going to validate multiple objects but individually (one at a time) using ilog jrules.

My current thought is wrap all items needs to be validated in a input param called "itemToValidate" as follows

<xs:element name="itemToValidate">
    <xs:complexType>
        <xs:sequence>
            <xs:element name="employer" type="tns:employer" minOccurs="0" />
            <xs:element name="department" type="tns:department" minOccurs="0" />
        </xs:sequence>
    </xs:complexType>
</xs:element>

then in a rule called "init" in package called "init" get each item and set to a variable for example "the employer" then for each item (element) in "itemToValidate" would have a package such as "employer" for all rules related to "the employer"

issue i am facing with this is I need to check the null ness for all rules before the actual validation.

is there a way to avoid that? or is there any wrong with my implementation?

Thanks

Chaminda Amarasinghe
  • 1
  • 1

3 Answers3

0

I am not sure to understand your issue. "Check the null ness for all rules before the actual validation".

Why are you not setting the objects in the working memory and let JRules deal with the memory and use local rule variable rather than global variables?

Set "my employer" to an Employer
if the name of "my employer" is bob
then print "hello"

I would create a function that pushes the "ItemsToValidate" in the working memory first and then write rules as I did. By doing this, if there is no Employer to validate then rules never fire because there is no item of type Employer in the memory.

Damien
  • 1,401
  • 9
  • 4
0

The Tester section of the BOM-to-XOM mapping of the class you are interested in can be implemented to check for the existence of the fields you care about.

For example, the tester can be written as :

return this.employer != null

This would mean that the itemToValidate where the employer is null would not be evaluated in the rules you write. This would eliminate the null check (for the employer).

Check the knowledge center under the "class mapping tester using IRL" topic

Leon Matthews
  • 61
  • 4
-1

Simply in our project we did a single verbalization for this approach, using:

the value {VALUE} is defined (return a boolean)

Hope this helps.

André Dias
  • 11
  • 3