fineract-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adi Raju" <adi.r...@confluxtechnologies.com>
Subject RE: Business Event Processor
Date Fri, 09 Dec 2016 06:51:33 GMT
Thanks for the inputs.
Here are some clarifications for the design:
Considering that we already have two eventing mechanism available and used by different features
	a. Using Spring ApplicationEvent. Used by the likes of hook event notification which can
be for asynchronous processing. Listeners of this event cannot affect API response.
	b. Business Event Notification (custom implementation) used for synchronous processing. Listener
of this event, can affect the API response as well.

1. In the proposed design, we are not trying to introduce any new Eventing mechanism, but
we are trying to provide a unified framework around the Business Event Notification for synchronous
validations or processing. Validating for account flag is a good example of usage. A generic
SMS might not be a good example, but an SMS that is supposed to be initiated for a 2 step
verification type scenarios is still a good use case for this framework, since failure to
send OTP should alter the response of the API. 
2. For the given small requirement of Data Driven Authentication, this solution would work.
But before the feature is developed in the community scope of the feature can be finalized
and usage of this design can be decided.
3. I cannot use Spring Eventing mechanism here, because the BusinessEventProcessors are more
of services than event listeners. For eg, we want getTemplate() to be able to return an object
to the caller. Event listeners are void methods and they cannot return anything.
4. We will replace AbstractBusinessEventProcessor with IBusinessEventProcessor service contract
interface. We will remove the BusinessEventProcessRegistry from the design and use the @Qualifier
to identify the different implementation processor services.

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: Sander van der Heyden [mailto:sandervanderheyden@musonisystem.com] 
Sent: 07 December 2016 14:09
To: dev@fineract.incubator.apache.org
Subject: Re: Business Event Processor

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
View raw message