Page History

...

There can be individual screen (reusing same implementation with just a different {processor} name end point) for processor definition of individual feature.

Advantages

• Single Business Event Listener and Single Database call to retrieve all the processor info in one shot
• No clutter of new APIs
• No or reduced Database design and new tables for each feature
• Since the metadata is stored as JSON, data for each different scenario within a processor is limited only to its validation logic/capability

Example Design for Flagging of Accounts feature on top of this framework

In the simplest of terms, flagging of accounts feature allows to tag a Savings or Loan account with a flag. The flags are custom definable by the MFI. Also MFI can define what actions are not allowed when based on flags.

Implemenation Notes

1. Define a Code-Value Mapping attribute and allow MFI to define their own Flags for Savings and Loans seperately
2. Add new command API on savings and Loan APIs to tag accounts with Flags
3. Implement AbstractBusinessEventProcessor as AccountFlaggingValidator
   1. Template method takes the options for Flags from Code-Value and also identifies entity and business events that can be processed
   2. Validate method validates that the code-values are from the definition in note.1
   3. Process method throws InvalidActionForFlaggedAccountException if it finds the business event is not allowed for the account flag.
   4. JSON data would be as follows

{

    entity : "loan",

    event : "waive interest",

    isPreEvent : true,

    processor : "accountFlaggingValidator",

    data : {

        blockedForFlags : ["XYZ", "ABC"]

    }

}

Example Design for Data Driven Authorisation

In the simplest of terms, Data Driven Authorisation enforces the user to have specific role before being able to perform an action. For eg, Loan Approval of amount more than 10000 should be done by user with role "Manager"

Implementation Notes

1. We might not need any additional modifications to existing APIs
2. Implement AbstractBusinessEventProcessor as DataDrivenAuthorisationValidator
   1. Template method shall return available roles as options and provide entities and actions for which this is supported
   2. Validation will make sure the range of amount is complete and non-overlapping and also role/entity/action are valid
   3. Process method throws InvalidAuthorisationForGivenDataException when the validation fails
   4. JSON data structure would be as follows:

{

    entity : "loan",

    event : "approval",

    isPreEvent : true,

    processor : "dataDrivenAuthorisationValidator",

    data : {

        [

            {

             "fromAmount": 10000,

             "toAmount":1000000,

             "roleId": 10

            },

            {

             "fromAmount": 1000001,

             "toAmount": 1000000000,

             "roleId": 20

            }

        ]

    }

}