THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Of late, community has been building features like 'Workflow using datatables', 'Triggered SMS', 'Notifications' etc, also we have many more features in roadmap like 'Flagging of Accounts', 'Data Driven Authorisation', 'Tasks Framework' etc. In all of these features, there is one commonality, which is to listen on a business event on an entity and perform either additional validation or processing. Drawback being that on each such business event each of these additional processing/validation results in a Database query to check if any additional processing or validation is required. The more such features we continue to add, the more we are slowing down the system by way of adding more and more DB calls whether required or not. Also we are adding more and more new APIs and related processing code which in my view is mundane as well as time consuming. This design proposal is an attempt proposes to generalize all such features under one single framework and API modelling, thus reducing the calls to DB and also improving the turn-around time for feature addition.
Design Approach
Business Event Notifier is an existing feature that notifies interested listeners to be able to act on any business event on any entity. A Business Event internally represented by Entity/Action/PreOrPostEvent information. Approach is to provide a framework around which any processors/validators can be added to be able to act on any Business Event.
Consider the below Class and ER diagram:
A generic framework implementation provides template/create/read/delete capabilities thru an unified or generalised API endpoint '/bep/{processor}', where {processor} represent different features like 'sms', 'workflow', 'datadrivenautorisation' etc. Against a unique triplet of "Business Event/Product Id/Processor", metadata required for processing by individual processor would be stored in generic JSON string format. A null ProductId as part of triplet would mean the default processing.
AbstractBusinessEventProcessor is abstraction for different processors possible. Any concrete implementor of this Abstract class potentially add a new processing/validation capability.
Any concrete implementor of AbstractBusinessEventProcessor has to do the following:
- Identify themselves against a processor name by overriding 'processorName' property. PS: A concrete implementation in AbstractBusinessEventProcessor makes sure the instance is registered with BusinessEventProcessorRegistry against the 'processorName'.
- Provide implementation of getTemplate, validateData methods for the metadata it expects for its processing. BusinessEventProcessorWritePlatformService will take help of these methods to be able to take the matadata and save in JSON format.
- Provide implementation of processBusinessEvent method which will be invoked by BEPEventListener for any relevant Business Event. This is where actual processing or validation as needed by the feature will be performed.