You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Rahul Goel <ra...@gmail.com> on 2018/03/08 05:43:55 UTC
Architecture Proposal | Fineract CN SMS & Email Notifications
Hi
I would like to propose my idea for implementation for *SMS & Email
Notifications Service*.
*As per my current understanding :*
This single service is responsible for preparing and delivery of SMS/Email.
MFI staff can enable notifications which member chooses when creating their
account. Apart from this, this service will contain integrations with
third-party like Twilio.
Basically this service will be responsible for campaigns, delivery of
Notifications and vendor integrations.
*What I propose :*
We should break this service into further smaller microservices as follows:
1. *Prepare-Notification-Service*
- This service will listen to different events and will act
accordingly, gathering information from other microservices such as
accounting, office, customer etc for data and validations
purposes and will
decide which set of users to send notification, thereby selection
corresponding notification template and then sending request either
single, bulk API of conveyor service or publish to specific queues whose
consumer will be again the conveyor service.
- In case of campaigns, this service will filter out the users to
whom the campaign is to be targeted, preparing all the other relevant
information required for campaign handling and in the end for
notifications, it will talk to conveyor service
2. *Conveyor-Service*
- As the name suggests, this service will act as a conveyor only. It
will talk to template service(talked about this below) for sms/email
notification final content.
- It will contain integration with third party vendors like Twilio.
- If in future we consider PUSH Notifications for desktop/mobile
devices, it will integrate that too.
- It will control notification logs like whether an EMAIL/SMS was
delivered or not, implement retry mechanism if required.
- It will control which vendor to use for communication purposes. If
for example one vendor is down for some reason, this service
will redirect
all notifications request to some other vendor available at that time
- It can be scaled independently if required.
- This service basically deals with actual sending of the
notifications.
3. *Template-Service*
- As the name suggests this service will be responsible for SMS/EMAIL
templating.
- It will talk to only conveyor-service
- It will contain basic templates in db and will return final
prepared template, For example
- pre-defined template is:
*Hi {{userName}}, your account No {{accountNumber}} has been
debited with {{currencyCode}} {{amount}}.*
- It will return: *Hi Rahul, your account No 123456789 has been
debited with INR 1000.*
- Conveyor-service will provide provide relevant payload and
templateId as received from notification service or directly through API.
- The final template prepared by this service will be used by
conveyor-service to send the desired notification.
- If we want to change the template of any type of notification in
future then that would be possible through this service APIs without
affecting any other service or code.
I would like to hear community member's thoughts and viewpoints on this
proposal. I am open to all kind of suggestions.
--
RAHUL GOEL
Re: Architecture Proposal | Fineract CN SMS & Email Notifications
Posted by Myrle Krantz <my...@apache.org>.
Excellent. You should have the necessary permissions now.
On Mon, Mar 12, 2018 at 3:58 PM, Rahul Goel <ra...@gmail.com> wrote:
> Hello Myrle,
>
> I have signed up now.
> Here are my details :
> username : rahul.usit12
> Profile URL : https://cwiki.apache.org/confluence/display/~rahul.usit12
>
>
> On Mon, Mar 12, 2018 at 12:46 AM, Myrle Krantz <my...@apache.org> wrote:
>
>> Hello Rahul,
>>
>> Are you sure you signed up for the Apache Fineract Confluence? Can
>> you give me a link to your profile please? Unfortunately I can't find
>> it when I look. As an example, here's mine:
>> https://cwiki.apache.org/confluence/display/~myrle My confluence id is
>> myrle.
>>
>> I've created an empty page for you to fill here once we have you set up.
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75975771
>>
>>
>> Best Regards,
>> Myrle
>>
>> On Thu, Mar 8, 2018 at 7:10 PM, Rahul Goel <ra...@gmail.com> wrote:
>> > Confluence Id : rahul.usit12@gmail.com
>> >
>> > On Thu, Mar 8, 2018 at 4:18 PM, Myrle Krantz <my...@apache.org> wrote:
>> >
>> >> Rahul,
>> >>
>> >> I think this is an excellent proposal. Might it make sense to begin a
>> >> new area in confluence to begin work in a more content-managed manner?
>> >>
>> >> If you have a confluence id, let me know what it is, and I'll give you
>> >> permissions, and point you to where it belongs in the current
>> >> confluence structure.
>> >>
>> >> Best Regards,
>> >> Myrle
>> >>
>> >>
>> >> On Thu, Mar 8, 2018 at 6:43 AM, Rahul Goel <ra...@gmail.com>
>> wrote:
>> >> > Hi
>> >> >
>> >> > I would like to propose my idea for implementation for *SMS & Email
>> >> > Notifications Service*.
>> >> >
>> >> > *As per my current understanding :*
>> >> > This single service is responsible for preparing and delivery of
>> >> SMS/Email.
>> >> > MFI staff can enable notifications which member chooses when creating
>> >> their
>> >> > account. Apart from this, this service will contain integrations with
>> >> > third-party like Twilio.
>> >> > Basically this service will be responsible for campaigns, delivery of
>> >> > Notifications and vendor integrations.
>> >> >
>> >> > *What I propose :*
>> >> >
>> >> > We should break this service into further smaller microservices as
>> >> follows:
>> >> >
>> >> > 1. *Prepare-Notification-Service*
>> >> > - This service will listen to different events and will act
>> >> > accordingly, gathering information from other microservices
>> such as
>> >> > accounting, office, customer etc for data and validations
>> >> > purposes and will
>> >> > decide which set of users to send notification, thereby
>> selection
>> >> > corresponding notification template and then sending request
>> >> either
>> >> > single, bulk API of conveyor service or publish to specific
>> queues
>> >> whose
>> >> > consumer will be again the conveyor service.
>> >> > - In case of campaigns, this service will filter out the users
>> to
>> >> > whom the campaign is to be targeted, preparing all the other
>> >> relevant
>> >> > information required for campaign handling and in the end for
>> >> > notifications, it will talk to conveyor service
>> >> > 2. *Conveyor-Service*
>> >> > - As the name suggests, this service will act as a conveyor
>> only.
>> >> It
>> >> > will talk to template service(talked about this below) for
>> >> sms/email
>> >> > notification final content.
>> >> > - It will contain integration with third party vendors like
>> Twilio.
>> >> > - If in future we consider PUSH Notifications for desktop/mobile
>> >> > devices, it will integrate that too.
>> >> > - It will control notification logs like whether an EMAIL/SMS
>> was
>> >> > delivered or not, implement retry mechanism if required.
>> >> > - It will control which vendor to use for communication
>> purposes.
>> >> If
>> >> > for example one vendor is down for some reason, this service
>> >> > will redirect
>> >> > all notifications request to some other vendor available at that
>> >> time
>> >> > - It can be scaled independently if required.
>> >> > - This service basically deals with actual sending of the
>> >> > notifications.
>> >> > 3. *Template-Service*
>> >> > - As the name suggests this service will be responsible for
>> >> SMS/EMAIL
>> >> > templating.
>> >> > - It will talk to only conveyor-service
>> >> > - It will contain basic templates in db and will return final
>> >> > prepared template, For example
>> >> > - pre-defined template is:
>> >> > *Hi {{userName}}, your account No {{accountNumber}} has been
>> >> > debited with {{currencyCode}} {{amount}}.*
>> >> > - It will return: *Hi Rahul, your account No 123456789 has
>> been
>> >> > debited with INR 1000.*
>> >> > - Conveyor-service will provide provide relevant payload and
>> >> > templateId as received from notification service or directly
>> >> through API.
>> >> > - The final template prepared by this service will be used by
>> >> > conveyor-service to send the desired notification.
>> >> > - If we want to change the template of any type of notification
>> in
>> >> > future then that would be possible through this service APIs
>> >> without
>> >> > affecting any other service or code.
>> >> >
>> >> > I would like to hear community member's thoughts and viewpoints on
>> this
>> >> > proposal. I am open to all kind of suggestions.
>> >> >
>> >> >
>> >> > --
>> >> > RAHUL GOEL
>> >>
>> >
>> >
>> >
>> > --
>> > RAHUL GOEL
>> > +91-9873124753
>>
>
>
>
> --
> RAHUL GOEL
> +91-9873124753
Re: Architecture Proposal | Fineract CN SMS & Email Notifications
Posted by Rahul Goel <ra...@gmail.com>.
Hello Myrle,
I have signed up now.
Here are my details :
username : rahul.usit12
Profile URL : https://cwiki.apache.org/confluence/display/~rahul.usit12
On Mon, Mar 12, 2018 at 12:46 AM, Myrle Krantz <my...@apache.org> wrote:
> Hello Rahul,
>
> Are you sure you signed up for the Apache Fineract Confluence? Can
> you give me a link to your profile please? Unfortunately I can't find
> it when I look. As an example, here's mine:
> https://cwiki.apache.org/confluence/display/~myrle My confluence id is
> myrle.
>
> I've created an empty page for you to fill here once we have you set up.
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75975771
>
>
> Best Regards,
> Myrle
>
> On Thu, Mar 8, 2018 at 7:10 PM, Rahul Goel <ra...@gmail.com> wrote:
> > Confluence Id : rahul.usit12@gmail.com
> >
> > On Thu, Mar 8, 2018 at 4:18 PM, Myrle Krantz <my...@apache.org> wrote:
> >
> >> Rahul,
> >>
> >> I think this is an excellent proposal. Might it make sense to begin a
> >> new area in confluence to begin work in a more content-managed manner?
> >>
> >> If you have a confluence id, let me know what it is, and I'll give you
> >> permissions, and point you to where it belongs in the current
> >> confluence structure.
> >>
> >> Best Regards,
> >> Myrle
> >>
> >>
> >> On Thu, Mar 8, 2018 at 6:43 AM, Rahul Goel <ra...@gmail.com>
> wrote:
> >> > Hi
> >> >
> >> > I would like to propose my idea for implementation for *SMS & Email
> >> > Notifications Service*.
> >> >
> >> > *As per my current understanding :*
> >> > This single service is responsible for preparing and delivery of
> >> SMS/Email.
> >> > MFI staff can enable notifications which member chooses when creating
> >> their
> >> > account. Apart from this, this service will contain integrations with
> >> > third-party like Twilio.
> >> > Basically this service will be responsible for campaigns, delivery of
> >> > Notifications and vendor integrations.
> >> >
> >> > *What I propose :*
> >> >
> >> > We should break this service into further smaller microservices as
> >> follows:
> >> >
> >> > 1. *Prepare-Notification-Service*
> >> > - This service will listen to different events and will act
> >> > accordingly, gathering information from other microservices
> such as
> >> > accounting, office, customer etc for data and validations
> >> > purposes and will
> >> > decide which set of users to send notification, thereby
> selection
> >> > corresponding notification template and then sending request
> >> either
> >> > single, bulk API of conveyor service or publish to specific
> queues
> >> whose
> >> > consumer will be again the conveyor service.
> >> > - In case of campaigns, this service will filter out the users
> to
> >> > whom the campaign is to be targeted, preparing all the other
> >> relevant
> >> > information required for campaign handling and in the end for
> >> > notifications, it will talk to conveyor service
> >> > 2. *Conveyor-Service*
> >> > - As the name suggests, this service will act as a conveyor
> only.
> >> It
> >> > will talk to template service(talked about this below) for
> >> sms/email
> >> > notification final content.
> >> > - It will contain integration with third party vendors like
> Twilio.
> >> > - If in future we consider PUSH Notifications for desktop/mobile
> >> > devices, it will integrate that too.
> >> > - It will control notification logs like whether an EMAIL/SMS
> was
> >> > delivered or not, implement retry mechanism if required.
> >> > - It will control which vendor to use for communication
> purposes.
> >> If
> >> > for example one vendor is down for some reason, this service
> >> > will redirect
> >> > all notifications request to some other vendor available at that
> >> time
> >> > - It can be scaled independently if required.
> >> > - This service basically deals with actual sending of the
> >> > notifications.
> >> > 3. *Template-Service*
> >> > - As the name suggests this service will be responsible for
> >> SMS/EMAIL
> >> > templating.
> >> > - It will talk to only conveyor-service
> >> > - It will contain basic templates in db and will return final
> >> > prepared template, For example
> >> > - pre-defined template is:
> >> > *Hi {{userName}}, your account No {{accountNumber}} has been
> >> > debited with {{currencyCode}} {{amount}}.*
> >> > - It will return: *Hi Rahul, your account No 123456789 has
> been
> >> > debited with INR 1000.*
> >> > - Conveyor-service will provide provide relevant payload and
> >> > templateId as received from notification service or directly
> >> through API.
> >> > - The final template prepared by this service will be used by
> >> > conveyor-service to send the desired notification.
> >> > - If we want to change the template of any type of notification
> in
> >> > future then that would be possible through this service APIs
> >> without
> >> > affecting any other service or code.
> >> >
> >> > I would like to hear community member's thoughts and viewpoints on
> this
> >> > proposal. I am open to all kind of suggestions.
> >> >
> >> >
> >> > --
> >> > RAHUL GOEL
> >>
> >
> >
> >
> > --
> > RAHUL GOEL
> > +91-9873124753
>
--
RAHUL GOEL
+91-9873124753
Re: Architecture Proposal | Fineract CN SMS & Email Notifications
Posted by Myrle Krantz <my...@apache.org>.
Hello Rahul,
Are you sure you signed up for the Apache Fineract Confluence? Can
you give me a link to your profile please? Unfortunately I can't find
it when I look. As an example, here's mine:
https://cwiki.apache.org/confluence/display/~myrle My confluence id is myrle.
I've created an empty page for you to fill here once we have you set up.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75975771
Best Regards,
Myrle
On Thu, Mar 8, 2018 at 7:10 PM, Rahul Goel <ra...@gmail.com> wrote:
> Confluence Id : rahul.usit12@gmail.com
>
> On Thu, Mar 8, 2018 at 4:18 PM, Myrle Krantz <my...@apache.org> wrote:
>
>> Rahul,
>>
>> I think this is an excellent proposal. Might it make sense to begin a
>> new area in confluence to begin work in a more content-managed manner?
>>
>> If you have a confluence id, let me know what it is, and I'll give you
>> permissions, and point you to where it belongs in the current
>> confluence structure.
>>
>> Best Regards,
>> Myrle
>>
>>
>> On Thu, Mar 8, 2018 at 6:43 AM, Rahul Goel <ra...@gmail.com> wrote:
>> > Hi
>> >
>> > I would like to propose my idea for implementation for *SMS & Email
>> > Notifications Service*.
>> >
>> > *As per my current understanding :*
>> > This single service is responsible for preparing and delivery of
>> SMS/Email.
>> > MFI staff can enable notifications which member chooses when creating
>> their
>> > account. Apart from this, this service will contain integrations with
>> > third-party like Twilio.
>> > Basically this service will be responsible for campaigns, delivery of
>> > Notifications and vendor integrations.
>> >
>> > *What I propose :*
>> >
>> > We should break this service into further smaller microservices as
>> follows:
>> >
>> > 1. *Prepare-Notification-Service*
>> > - This service will listen to different events and will act
>> > accordingly, gathering information from other microservices such as
>> > accounting, office, customer etc for data and validations
>> > purposes and will
>> > decide which set of users to send notification, thereby selection
>> > corresponding notification template and then sending request
>> either
>> > single, bulk API of conveyor service or publish to specific queues
>> whose
>> > consumer will be again the conveyor service.
>> > - In case of campaigns, this service will filter out the users to
>> > whom the campaign is to be targeted, preparing all the other
>> relevant
>> > information required for campaign handling and in the end for
>> > notifications, it will talk to conveyor service
>> > 2. *Conveyor-Service*
>> > - As the name suggests, this service will act as a conveyor only.
>> It
>> > will talk to template service(talked about this below) for
>> sms/email
>> > notification final content.
>> > - It will contain integration with third party vendors like Twilio.
>> > - If in future we consider PUSH Notifications for desktop/mobile
>> > devices, it will integrate that too.
>> > - It will control notification logs like whether an EMAIL/SMS was
>> > delivered or not, implement retry mechanism if required.
>> > - It will control which vendor to use for communication purposes.
>> If
>> > for example one vendor is down for some reason, this service
>> > will redirect
>> > all notifications request to some other vendor available at that
>> time
>> > - It can be scaled independently if required.
>> > - This service basically deals with actual sending of the
>> > notifications.
>> > 3. *Template-Service*
>> > - As the name suggests this service will be responsible for
>> SMS/EMAIL
>> > templating.
>> > - It will talk to only conveyor-service
>> > - It will contain basic templates in db and will return final
>> > prepared template, For example
>> > - pre-defined template is:
>> > *Hi {{userName}}, your account No {{accountNumber}} has been
>> > debited with {{currencyCode}} {{amount}}.*
>> > - It will return: *Hi Rahul, your account No 123456789 has been
>> > debited with INR 1000.*
>> > - Conveyor-service will provide provide relevant payload and
>> > templateId as received from notification service or directly
>> through API.
>> > - The final template prepared by this service will be used by
>> > conveyor-service to send the desired notification.
>> > - If we want to change the template of any type of notification in
>> > future then that would be possible through this service APIs
>> without
>> > affecting any other service or code.
>> >
>> > I would like to hear community member's thoughts and viewpoints on this
>> > proposal. I am open to all kind of suggestions.
>> >
>> >
>> > --
>> > RAHUL GOEL
>>
>
>
>
> --
> RAHUL GOEL
> +91-9873124753
Re: Architecture Proposal | Fineract CN SMS & Email Notifications
Posted by Rahul Goel <ra...@gmail.com>.
Confluence Id : rahul.usit12@gmail.com
On Thu, Mar 8, 2018 at 4:18 PM, Myrle Krantz <my...@apache.org> wrote:
> Rahul,
>
> I think this is an excellent proposal. Might it make sense to begin a
> new area in confluence to begin work in a more content-managed manner?
>
> If you have a confluence id, let me know what it is, and I'll give you
> permissions, and point you to where it belongs in the current
> confluence structure.
>
> Best Regards,
> Myrle
>
>
> On Thu, Mar 8, 2018 at 6:43 AM, Rahul Goel <ra...@gmail.com> wrote:
> > Hi
> >
> > I would like to propose my idea for implementation for *SMS & Email
> > Notifications Service*.
> >
> > *As per my current understanding :*
> > This single service is responsible for preparing and delivery of
> SMS/Email.
> > MFI staff can enable notifications which member chooses when creating
> their
> > account. Apart from this, this service will contain integrations with
> > third-party like Twilio.
> > Basically this service will be responsible for campaigns, delivery of
> > Notifications and vendor integrations.
> >
> > *What I propose :*
> >
> > We should break this service into further smaller microservices as
> follows:
> >
> > 1. *Prepare-Notification-Service*
> > - This service will listen to different events and will act
> > accordingly, gathering information from other microservices such as
> > accounting, office, customer etc for data and validations
> > purposes and will
> > decide which set of users to send notification, thereby selection
> > corresponding notification template and then sending request
> either
> > single, bulk API of conveyor service or publish to specific queues
> whose
> > consumer will be again the conveyor service.
> > - In case of campaigns, this service will filter out the users to
> > whom the campaign is to be targeted, preparing all the other
> relevant
> > information required for campaign handling and in the end for
> > notifications, it will talk to conveyor service
> > 2. *Conveyor-Service*
> > - As the name suggests, this service will act as a conveyor only.
> It
> > will talk to template service(talked about this below) for
> sms/email
> > notification final content.
> > - It will contain integration with third party vendors like Twilio.
> > - If in future we consider PUSH Notifications for desktop/mobile
> > devices, it will integrate that too.
> > - It will control notification logs like whether an EMAIL/SMS was
> > delivered or not, implement retry mechanism if required.
> > - It will control which vendor to use for communication purposes.
> If
> > for example one vendor is down for some reason, this service
> > will redirect
> > all notifications request to some other vendor available at that
> time
> > - It can be scaled independently if required.
> > - This service basically deals with actual sending of the
> > notifications.
> > 3. *Template-Service*
> > - As the name suggests this service will be responsible for
> SMS/EMAIL
> > templating.
> > - It will talk to only conveyor-service
> > - It will contain basic templates in db and will return final
> > prepared template, For example
> > - pre-defined template is:
> > *Hi {{userName}}, your account No {{accountNumber}} has been
> > debited with {{currencyCode}} {{amount}}.*
> > - It will return: *Hi Rahul, your account No 123456789 has been
> > debited with INR 1000.*
> > - Conveyor-service will provide provide relevant payload and
> > templateId as received from notification service or directly
> through API.
> > - The final template prepared by this service will be used by
> > conveyor-service to send the desired notification.
> > - If we want to change the template of any type of notification in
> > future then that would be possible through this service APIs
> without
> > affecting any other service or code.
> >
> > I would like to hear community member's thoughts and viewpoints on this
> > proposal. I am open to all kind of suggestions.
> >
> >
> > --
> > RAHUL GOEL
>
--
RAHUL GOEL
+91-9873124753
Re: Architecture Proposal | Fineract CN SMS & Email Notifications
Posted by Myrle Krantz <my...@apache.org>.
Rahul,
I think this is an excellent proposal. Might it make sense to begin a
new area in confluence to begin work in a more content-managed manner?
If you have a confluence id, let me know what it is, and I'll give you
permissions, and point you to where it belongs in the current
confluence structure.
Best Regards,
Myrle
On Thu, Mar 8, 2018 at 6:43 AM, Rahul Goel <ra...@gmail.com> wrote:
> Hi
>
> I would like to propose my idea for implementation for *SMS & Email
> Notifications Service*.
>
> *As per my current understanding :*
> This single service is responsible for preparing and delivery of SMS/Email.
> MFI staff can enable notifications which member chooses when creating their
> account. Apart from this, this service will contain integrations with
> third-party like Twilio.
> Basically this service will be responsible for campaigns, delivery of
> Notifications and vendor integrations.
>
> *What I propose :*
>
> We should break this service into further smaller microservices as follows:
>
> 1. *Prepare-Notification-Service*
> - This service will listen to different events and will act
> accordingly, gathering information from other microservices such as
> accounting, office, customer etc for data and validations
> purposes and will
> decide which set of users to send notification, thereby selection
> corresponding notification template and then sending request either
> single, bulk API of conveyor service or publish to specific queues whose
> consumer will be again the conveyor service.
> - In case of campaigns, this service will filter out the users to
> whom the campaign is to be targeted, preparing all the other relevant
> information required for campaign handling and in the end for
> notifications, it will talk to conveyor service
> 2. *Conveyor-Service*
> - As the name suggests, this service will act as a conveyor only. It
> will talk to template service(talked about this below) for sms/email
> notification final content.
> - It will contain integration with third party vendors like Twilio.
> - If in future we consider PUSH Notifications for desktop/mobile
> devices, it will integrate that too.
> - It will control notification logs like whether an EMAIL/SMS was
> delivered or not, implement retry mechanism if required.
> - It will control which vendor to use for communication purposes. If
> for example one vendor is down for some reason, this service
> will redirect
> all notifications request to some other vendor available at that time
> - It can be scaled independently if required.
> - This service basically deals with actual sending of the
> notifications.
> 3. *Template-Service*
> - As the name suggests this service will be responsible for SMS/EMAIL
> templating.
> - It will talk to only conveyor-service
> - It will contain basic templates in db and will return final
> prepared template, For example
> - pre-defined template is:
> *Hi {{userName}}, your account No {{accountNumber}} has been
> debited with {{currencyCode}} {{amount}}.*
> - It will return: *Hi Rahul, your account No 123456789 has been
> debited with INR 1000.*
> - Conveyor-service will provide provide relevant payload and
> templateId as received from notification service or directly through API.
> - The final template prepared by this service will be used by
> conveyor-service to send the desired notification.
> - If we want to change the template of any type of notification in
> future then that would be possible through this service APIs without
> affecting any other service or code.
>
> I would like to hear community member's thoughts and viewpoints on this
> proposal. I am open to all kind of suggestions.
>
>
> --
> RAHUL GOEL