1. DS can be exposed as a WS
2. can be invoked via JMS or pure java call also
3. migration path from DS to jRules though possible is not recommended since the extended capabilities of Jrules will most probably necessitate a rewrite of the rules
4. recommended for < 30 business rules
5. best practice minimum necessary data should go in as input (actually least possible)
6. reference data should not be inputed/provided but the DS is responsible for acquiring it via an integration and if applicable with a caching layer in between.
7. no interface available for business to update DS in runtime at least in standard version.
8. a rule change or a new rule means process app redeployment
9. Generally used for process route decisions, validate coach inputed data, decision parameters within BPM services.
10. Provides regular JS besides BAL rules and Decision tables for more complex data based manipulations
Basic purpose of a rule is to make a decision, derive new data based on old data, enforce a business policy
1. BAl rules internally have a jrules engine
2. slower than decision tables to run because of embedded jrules engine.
3. provided features which Decision table can not do e.g. compare one variable to another or one variable to a collection
4. there is no output data binding for decision services in gateways
e.g. a BAL rule is if request type is A or request type is B set valid = true
u will use tw.decision.valid to use the BAL rule output variable
5. the order matters and the rules are executed in the specified order
6. if condition true then action or action only which is always executed.
7. provide iteration capabilities and control statements in an english manner.
compare variables with hard coded single or multiple values or comparison operators, action or otherwise kind of assignments
All other components in a service e.g. tacking, nested services, js etc are available