Hey Adi, thanks for the reply. ; o)
Triggering SMS or sending notifications are features that should happen asynchronous, because they are executed after a business logic was successfully executed. For validation we may should think about utilizing what the Spring framework has to offer instead of implementing it ourselves. We may should try to find consensus on Data Driven Authorization within the community, given the configuration is usually very complex and the real benefit is questionable. Cheers Markus -----Original Message----- From: Adi Raju [mailto:adi.r...@confluxtechnologies.com] Sent: Wednesday, December 7, 2016 05:59 AM To: dev@fineract.incubator.apache.org Subject: RE: Business Event Processor Hi Markus, This proposal is mainly intended to help any synchronous processing requirements. For eg, In case of validation failure the API(command) should fail. I do not see ActiveMQ of help here. Data Driven Authorisation as such is bigger feature umbrella, in that we want to control data visibility even in the read APIs based on different business rules. In the example provided, "Data Driven Authorisation" was a simple validation feature request, which requires allowing an API based on role and not just permission assigned to the App User. Regards, Adi Raju Principal Architect, Conflux Technologies Pvt Ltd Address: #304, 2nd Floor, 7th Main Road, HRBR Layout 1st Block, Bengaluru, Karnataka, 560043 INDIA Disclaimer: The information contained in this e-mail message and any files/attachment transmitted with it is confidential and for the sole use of the intended recipient(s) or entity identified. If you are not the intended recipient, please email: supp...@confluxtechnologies.com and destroy/delete all copies and attachment thereto along with the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and is unlawful. The recipient acknowledges that Conflux Technologies Private Limited or its subsidiaries and associated companies are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions. Before opening any attachments, please check. -----Original Message----- From: Markus Gei? [mailto:markus.ge...@live.de] Sent: 05 December 2016 20:51 To: dev@fineract.incubator.apache.org Subject: RE: Business Event Processor Hey, why not utilizing an existing event queue, e.g. ActiveMQ, to get this feature in. I don't see any real benefit of creating our own mechanism for this. And I believe we are mixing requirements/features here, e.g. data driven auth is not an event feature ... so it should not be modeled to become one. Cheers Markus From: Adi Raju [mailto:adi.r...@confluxtechnologies.com] Sent: Monday, December 5, 2016 10:14 AM To: dev@fineract.incubator.apache.org Subject: Business Event Processor Hi All, 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 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. https://cwiki.apache.org/confluence/display/FINERACT/Business+Event+Processo r Please review and provide your comments. Regards, Adi Raju Principal Architect, Conflux Technologies Pvt Ltd<http://www.confluxtechnologies.com/> Address: #304, 2nd Floor, 7th Main Road, HRBR Layout 1st Block, Bengaluru, Karnataka, 560043 INDIA Disclaimer: The information contained in this e-mail message and any files/attachment transmitted with it is confidential and for the sole use of the intended recipient(s) or entity identified. If you are not the intended recipient, please email: supp...@confluxtechnologies.com<mailto:supp...@confluxtechnologies.com> and destroy/delete all copies and attachment thereto along with the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and is unlawful. The recipient acknowledges that Conflux Technologies Private Limited or its subsidiaries and associated companies are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions. Before opening any attachments, please check. [Finflux]
