Compare between facts in condition

In Oracle Business Rules, it is usually the practice to validate a fact against a constant. But there might be cases where you would want to map the input from an user to one of fact, compare another fact with input from the user and make decisions. In other words, when the value of the constant to be issued in the condition is itself ambiguous, it is better to use the facts vs facts instead of facts vs constant method. For instance, I have a case where I have three inputs IP1, IP2 and IP3 coming in and I do not want to fix values (use constants for comparison in condition of rules) and instead make a condition directly involving IP1, IP2 and IP3. My schema in such a case will look like:

The decision table involving the facts will look like below:

The facts have been directly compared against each other without the need for a constant.

Peace!

Cheers,
- AR

The rete network does not update the modified data

This is a case where there is a dictionary D1 which is being invoked from BPEL. A set of facts F1, is passed to D1 and the same is returned from D1. There also exists D2, which uses the same set of facts as D1. D2 is invoked from the decision function of D1 (after D2 has been linked to D1, obviously !). I get F1 into D1 and I make a call to D2. D2 modifies F1 to F1.1 and returns call to D1. However, D1 does not understand F1 has changed to F1.1 and since it has been initialized with F1, continues to process the rules with F1 and F1.1 is not all considered.

This has been confirmed to be an inconsistent behavior from the rete network and rules engine and it has been identified as a bug. It would be fixed in the future releases (not sure of the release). Till if you face the same issue, you can survive with two workarounds:

A: Make call outs to rules from BPEL

1. Call D1 from BPEL, execute rules in D1
2. Instead of calling D2 from D1, call D2 from BPEL
3. Then call D1 again. The rete network in this case initializes D1 with facts available in Step2

B: Assert the facts in D2 before returning control to D1

1. Call D1, then D2 from decision function of D1
2. Modify F1 to F1.1 in D2
3. Using advanced functions do a assert and return of F1.1 (this makes the rete refresh the facts)
4. Return control to D1 and proceed

Keep tracking this thread for the update on the bug and fix for the same !

Peace!

Cheers,
- AR

Reducing the size of dictionaries

I was working on a case study where I had to create close to 10 dictionaries, each of them having the same facts being passed to them. The XSD I was using was of a considerable size, say 27KB and the XML generated from it was 15KB. When the facts were created the dictionary size came to 1.3 MB. So since each of these dictionaries had facts imported in them, each was about 1.3 MB and so the entire .jar file post compiling was about 15 MB.

This was a simple 10 dictionaries in a project case. Consider 50-60 dictionaries and each of size 1 MB. The project would take about 20 minutes to deploy, considering my case study took 6 minutes to deploy. Maintenance becomes an issue here and SOA server after deployment becomes slow and unstable.

Alternative is, have the facts in one dictionary. Link this dictionary to all other dictionaries using the same facts and use the imported facts in rules. This reduces the size of the dictionaries considerably. Statistically, for my case study, the size of one of the dictionary (where facts were present) remained the same. The size of the others came down to 500KB (depends on decision table number, no.of rules etc) approx. The size of the entire deployable was halved.

Peace !

Cheers,
- AR