fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander van der Heyden <sandervanderhey...@musonisystem.com>
Subject Re: Business Event Processor
Date Wed, 07 Dec 2016 08:39:23 GMT
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.geiss@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.raju@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: support@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.geiss@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.raju@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:
> support@confluxtechnologies.com<mailto:support@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]
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message