Book Image

Instant Oracle BPM for Financial Services How-to

By : B.M Madhusudhan Rao
Book Image

Instant Oracle BPM for Financial Services How-to

By: B.M Madhusudhan Rao

Overview of this book

Oracle Business Process Management helps in process automation and improvement with a very high level of flexibility for all the process participants from the process planning team to the end users. It also makes it possible to have corporate employees and customers collaborating towards common goals. Instant Oracle BPM for Financial Services How-to covers many concepts that can be easily reused across industries such as core banking, healthcare, travel, self service automation, e-governance, and so on. It highlights various roles of Business Process Management such as Business Process Modeling, Process Developer, Process Owner, and Process Participant along with the way they work together in a financial services environment. Instant Oracle BPM for Financial Services How-to is your guide to implementing Oracle Business Process Management whilst working in the Financial Services industry.Starting through the discovering of implementation and Business challenges for financial services we will move on to Modeling, Implementation, Process ork-flow’s, deployment and testing. Moving on to cover advanced topics such as Process administering, changing business processes using process analysts, business reporting, participants and notifications and finally collaboration. You will learn to setup, maintain and alter your Business Process Management aimed specifically for the Financial services industry.
Table of Contents (8 chapters)

Modeling a home loan business process (Intermediate)


In this recipe, we will partially model and simulate a business process with a core focus on Oracle Business Rules from a financial services perspective. In home loan scenarios, a customer is asked to fill an online form or talk to a financial advisor at the bank. These discussions capture the basic required dataset such as the loan purpose, property value, loan amount required, loan repayment duration, applicant's monthly or annual income, type of employment, and age. These datasets are used to analyze the eligibility of the applicant, and to find out whether they qualify for the requested loan amount. Banks often classify their customers into Gold/Platinum customers based on various parameters such as annual income, loyalty with the bank for existing customers, and transactional amount. The primary focus in this recipe is to check if the person is within the eligible age limit and belongs to a particular income group based on which customers are classified into Platinum, Gold, Silver, and Bronze customers. The people who do not meet the required age group or income group are considered as not eligible.

Note

Many screen captures, deployment- and configuration-related steps are not shown in detail in this book. However, these are made available in the ready-to-use source code and on my blog (jamessmith73.wordpress.com) under the BPM for Financial Services section.

Getting ready

We will start with a ready-made schema, available in the source code that is used to check the eligibility of an applicant. This recipe need JDeveloper and a running SOA Suite instance. Download the recipe's source code and take a look at the jamesbank.xsd schema file from the source code folder for request and response elements.

How to do it…

Let's perform the following steps:

  1. Launch JDeveloper and create a new BPM application.

  2. Name the application as JamesBank and then click on Next.

  3. Name the project as LoanEligibilityProj and then click on Next.

  4. In Project SOA Settings, select Composite with BPMN Process.

  5. Select Synchronous Service and name it as LoanEligibilityProcess.

  6. Change to the BPM Project Navigation view and select LoanEligibilityProcess.

  7. Create a business object and name it as EligibilityBO. Create a new destination module and name it as Module. Select Based on External Schema; this schema then needs to be picked from the schema browser. This is where we need to pick up eligibilityRequest from the jamesbank.xsd schema file.

    Note

    Ensure that the XSD file is copied into the project from the external directory.

  8. Similarly, create another business object and name it as EligibilityRespBO. This maps to the eligibilityResponse element of the jamesbank.xsd schema.

  9. Now we need to create input and output argument definitions. Name the input arguments as inputArgs.

  10. Similarly, create outputArgs that maps to the EligibilityRespBO business object.

  11. Under Process Data Objects, create a new process data object and name it as EligibilityPDO.

  12. Similarly, create EligibilityRespPDO that maps to the Module.EligibilityRespBO component.

Now perform the following steps to create a business rule in order to check eligibility:

  1. From the Component Palette, drag-and-drop a Business Rule component between the start and end activities of the BPM process and name it as EligibilityRule.

  2. Create a new business rule by clicking on the + icon to the right of the Business Rule field and name it as EligibilityBR.

  3. Pass input and output parameters from the process data objects.

  4. Edit the business rule in the Rules Editor:

    1. Create a decision table, name it as EligibilityDecisionTable, and then click on Bucketsets from the left tab.

    2. Enter the age range, monthly income range, and loan range discussed as follows:

      • The age ranges will be less than 18, 18 to 50, and greater than 50 years

      • The monthly income ranges will be less than 30,000, between 30,000 to 60,000, between 60,000 to 100,000, and greater than 100,000 INR

      • The loans range will be less than 1,000,000, between 1,000,000 to 5,000,000, and greater than 5,000,000 INR

    3. Select global variables by clicking on Globals from the left tab in the Rules Editor.

    4. Select EligibilityRule, set the rule conditions, and then assign values based on it.

We will now understand the rule modeling in the decision table.

  • The next screenshot shows EligibilityDecisionTable where applicants with age group less than 18 and greater than 50 years are marked as "NE" (not eligible). Applicants who are in the eligible age group are classified into various categories based on the monthly income and the loan amount requested.

  • In the decision table, we will ignore people with age range less than 18 and greater than 50 years and mark them as "NE" in the response status.

  • The people with monthly income less than 30,000 INR are also marked as "NE".

  • This leaves us with the people between the age group 18 and 50 years and loan applicants with monthly income greater than 30,000 INR who are marked as eligible.

  • The applicants with a monthly income greater than 100,000 INR and a loan request greater than 5,000,000 INR are the people who are core customers for the success of, let's say, "James Bank". So we set them as "Platinum" customers in EligibilityRespPDO.

  • The rest of the eligible customers (applicants) fall under the "Gold", "Silver", and "Bronze" categories.

  • We can then calculate fixed and variable EMI amounts based on the EMI calculation formulas.

Now that our business rules are ready, we will add them into the process in order to check applicant's eligibility.

How it works…

Bucketsets allow us to define a range of values to be used in the business rules. In the bucketset, we created the ranges for age, monthly income, and the requested loan ranges.

Global variables are the variables that are available within the business rule, which can be even changed during runtime by the process analyst in the business process. We will now create two global variables—one for fixed rate of interest EMIs and another for variable rate of interest EMIs. Fixed interest rate and variable interest rate are the variables that will hold these interest rates as their values.

The process flow and the model (shown in the next screenshot) for the LoanEligibility business process modeling is summarized as follows:

  1. The user submits a loan request at the Start event.

  2. EligibilityRule gets fired. This determines various rule parameters based on the business rule defined in the previous section.

  3. A decision is made as to whether the applicant is eligible or not. If the applicant is not eligible, the process ends.

  4. If the applicant is a Platinum customer, a special discount is offered and a notification is sent to the loan officer as a heads up.

  5. If the customer is from the Platinum, Gold, Silver, or Bronze category, then the process moves ahead for further modeling, which will be discussed in next recipe. At this stage, we can leave that as a "not implemented" activity or mark it as Is Draft.

  6. Deploy the business process to SOA Administration Server.

We will now simulate our home loan business process to check how it works so far:

  1. Let us log in to Enterprise Manager (http://localhost:7001/em) as weblogic, and run the process by selecting LoanEligibilityProj.

    Note

    Replace the URL with your hostname or IP address if it is not localhost or using any other port.

  2. Provide the following test inputs:

    • Property City: Bangalore

    • Loan Request Amount: 7500000

    • Loan Purpose: Home Loan

    • Market Value of Property: 9500000

    • Repayment Duration in months: 60

    • Applicant Age: 30

    • Employment Type: Salaried

    • Company Name: JS Bank

    • Average Monthly Income: 150000

    The output of this process will be a Platinum customer, which can be viewed from the Audit Trail and Flow tabs. The green line in the flow denotes a happy path or the path taken by the process for the given input data.

There's more…

Business rules not only support decision tables, but also if-then conditions. The same rule can be modeled as: if the customer age is less than 18, then assign the eligibility status as not eligible. It's a matter of choice whether you use decision tables or if-then conditions. Decision tables support complex business logic within business rules when compared to if-then conditions.