You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Adi Raju <ad...@confluxtechnologies.com> on 2016/12/05 09:13:35 UTC
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, <http://www.confluxtechnologies.com/> 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: <ma...@confluxtechnologies.com>
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
RE: Business Event Processor
Posted by Adi Raju <ad...@confluxtechnologies.com>.
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ß <ma...@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]
>
>
>
Re: Business Event Processor
Posted by Sander van der Heyden <sa...@musonisystem.com>.
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ß <ma...@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<ma...@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]
>
>
>
RE: Business Event Processor
Posted by Markus Geiß <ma...@live.de>.
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<ma...@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]
RE: Business Event Processor
Posted by Adi Raju <ad...@confluxtechnologies.com>.
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<ma...@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]
RE: Business Event Processor
Posted by Markus Gei? <ma...@live.de>.
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+Processor
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<ma...@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]