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: 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: Sander van der Heyden [mailto:sandervanderhey...@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.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]
>
>
>
