This is one of the possible Use Cases.
This use case illustrates a real business application of (production) rules working with XML data.
Originally proposed by: GaryHallmark
- Developed as proof of concept with large Oracle customer
- Illustrates integration of Business Processes and Rules
3. Links to Related Use Cases
Rule-Based Combined Access to XML and RDF Data: also uses XML Data
4. Relationship to OWL/RDF Compatibility
5. Examples of Rule Platforms Supporting this Use Case
All the major business rule vendors have facilities to work together with business process modeling and execution software, such as Oracle BPEL.
6. Benefits of Interchange
- Vendors of business data such as credit histories could supply default rules to evaluate their data
- With multiple rule vendors supporting RIF, there would be a variety of business-user-friendly tools to customize rules to meet specific objectives
7. Requirements on the RIF
- access and compare XML data in rule conditions
- modify XML data in rule actions
8.1. Actors and their Goals
- credit applicant submits application to credit approval service and wants approval or denial
- credit history vendor provides credit history based on applicant identity data via web service
8.2. Main Sequence
- applicant submits credit application to approval service implemented with BPEL orchestration
- BPEL forwards application to decision service for validation of identity data
- BPEL requests credit history of applicant from web service
- BPEL forwards credit history to decision service for evaluation
- decision service returns approval or denial document also containing rationale
- BPEL forwards decision to applicant
This use case is based on a real commercial credit approval service. The service is deployed as a Web service that takes an applicant credit request document as input and returns an approval or denial (with reason).
The implementation of the service is a BPEL orchestration of two web services -- a credit history providing service and a decision service containing a rules engine. BPEL first passes the credit request document to the decision service to determine, using rules, whether a enough information (SSN, Mother's maiden name, etc.) is available to request a credit history. If so, BPEL then requests a credit history and from the history providing service and passes the credit history document to the decision service to be evaluated. Based on the evaluation, credit is approved or denied.
Because the rule engine is a web service, existing BPEL diagramming and execution facilities can be used to integrate rules into this credit approval service. The credit evaluaton model can be changed easily using GUI tools to customize rules. Use of RIF would improve the situation further. First, the credit history vendor could supply a default set of rules for evaluating its histories. Second, there would be several rule editing and customization tools from different RIF compatible vendors to tailor the rules to meet specific business objectives.
Because web services use XML data for their request and response format, the rules must be able to access and compare XML data in their conditions, and modify and generate XML data in their actions.
The credit evaluation rules are grouped into three rulesets that are executed sequentially. Rules in the first ruleset apply thresholds to several "red flag" quantities in the credit report, such as
- number of times a payment was 60 days late
- debt to income ratio
- number of foreclosures or reposessions
- number of garnishments
- number of liens
A red flag above the threshold results in denial of credit.
Rules in the second ruleset increment a credit score variable. For example,
- if applicant owns residence, add 40
- if applicant rents, add 30
- if applicant's income is under 20000, add 10
- if applicant's income is between 40000 and 50000, add 40
- if applicant lived at current address 2 to 4 years, add 20
The third and final ruleset compares the applicant's credit score and income to threshold values, and makes the final decision to approve or deny credit to the applicant.
The decision and supporting rationale is returned from the decision service as an XML document. This decision document is then used to construct the reply to the original credit approval request.
Comments, issues, etc. Again, note that the wiki automatically keeps a revision history.