Hi guys, +1 on all of Markus' points. I do think there is a real need to deal with synchronous events in a better way especially as the current implementations are diverse and indeed do not take (sufficient) advantages of re-using data already available and go back to querying the DB.
On Data Driven Authorization, I feel it's indeed one of those topics where everyone seems to have a different picture of what we are trying to achieve. From my side I think the current break-up between branches and assigning users and roles to that is already quite a good way of doing it, it's just been implemented in a lazy way with many steps skipped in reports, but also in various API calls. When it comes to role-based authorisation on loan amounts etc, I think the current credit checks feature we use is already a nice step forward, if you were to replace that by using Spring Expressions instead of SQL you could already achieve a lot of this in a very customisable way without completely overhauling the entire authorisation logic. Similar things can apply to savings products, this would then leave approving of clients etc, which I think is much less of an issue, mainly as you can still verify a lot of these before you actually take deposits or provide funds to the customer. S Sander van der Heyden CTO Musoni Services Mobile (NL): +31 (0)6 14239505 Skype: s.vdheyden Website: musonisystem.com Follow us on Twitter! <https://twitter.com/musonimfi> Postal address: Hillegomstraat 12-14, office 0.09, 1058 LS, Amsterdam, The Netherlands On 7 December 2016 at 09:18, Markus Geiß <markus.ge...@live.de> wrote: > 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] > > >
