I am wondering if anyone has had any success in removing an entity (using rules) after it has been created. I am working on building a rating tool and a requirement is to have a "decline rate" button that would ideally remove the entity instance before it is passed to the Doc Gen server and Siebel. If you have any suggestions or ideas that you can offer up I would greatly appreciate it.
Edited by: 957209 on Nov 19, 2012 10:40 AM
Entity instances should not be "removed". Either the instance exists or it does not and the data should reflect whichever is true for the entire "think" process after all incoming data is known. For example, if you create an instance, decide to decline it, then somehow the instance is deleted, then logically the decline cannot exist because it refers to a nonexistent instance.
If the entity instances in question are being inferred by rules in the first place, then one approach is to separate the list of potential instances (i.e. the id's of those instances that might be selected, declined, etc, ... ). The id's are then used to populate the interface, assuming you want to present the possible options. Then a rule can be used to create the entity instances for only those id's that were selected (or not declined, as the case may be).
If the entity instances are not inferred but provided as part of the data (either as part of an incoming transaction or created through an interview) then the usual approach is to model that the instance "is declined" as a boolean attribute. (i.e. you can't decline something if it doesn't exist in the first place)
With some background / detail on the requirements that led to the desire to remove instances, there may be better advice ...
This should do it...
all instances of the test entity (the key) exists if
the decline rate is not pressed or
it is unknown whether the decline rate is pressed
The test entity will exist unless "the decline rate is pressed"
However, there are architectural and rule quality ramifications...
Edited by: Paul Fowler on Nov 20, 2012 5:37 AM
This question led me to ask "what does it look like if I have a temporal condition on the inferred existence of an entity?"
So, I put the following two rules in a ruleset with an entity called "the test entity" and hit debug... all instances of the test entity (the key) exists if
the decline rate is not pressed or
it is unknown whether the decline rate is pressed the count of entities = instanceCount(all instances of the test entity)
I then put change points on the attribute "the decline rate is pressed".
What I found is that OPA does not like to infer entities with a condition that is temporal. It never inferred the entity. Is that documented in the help text? Is that a bug? Did I do it wrong? Is this a problem?
from the article:
"Write rules that infer relationships and entities" (which is the one that the "what's new" bit takes you to)
there's a section on notes/limitations - item 5 says:
Combining inferred relationships with temporal values is not supported.
Although this is strictly in the section about inferred relationships the same logic necessarily applies - when you infer an instance you infer both the instance and the relationship.
My view is that generally an instance of an entity has an existence or it doesn't - it might have an operative date range but the thing still has an existence - so trying to combine existence/non-existence with temporal values doesn't really work from a conceptual perspective (all the attributes - beyond identifying attribute- of an entity might end up being temporal, but that's another story).
I believe there's also been some chat at various stages and between various people as to whether a relationship should be allowed to have more information associated with it beyond simply "I exist between A and B" - but at present that's what it has.
Edited by: Sean Reardon on Nov 20, 2012 6:08 AM
Interesting. I can see both sides.
I think that temporally speaking, entities can come into and out of existence.
In the State of NY, for instance, we just had a pretty good storm come through here that is no longer in existence. Certain insurance rules only apply when one or more storm exists.
I could probably come up with a dozen other examples like temporary disabilities and so forth. Making these items temporal attributes (instead of temporal entities) is the current solution, I assume. Or creating the entity for all time, but having a temporal attribute on the entity that we have to use to infer the outcomes... whichever.