Ebenezer, Can you give some guidance to our interns that are working on notifications in our customer-facing Mobile Wallet and Mifos Mobile CN applications. On the client-side both are capable of receiving and displaying FCM via the app but wanted to discuss how your notifications microservice documented at https://cwiki.apache.org/confluence/display/FINERACT/Fineract+CN+Notification can be connected to and how it must be extended further to support FCM.
This conversation has borne out of the below discussions around notifications being generated for a number of the Payment Hub use cases and general use cases for our customer-facing apps (see thread below). For Fineract 1.x, the server-side notification generation and storage should be sufficient along with the client-side consumption of FCM but we need to document the process more extensively. Ed ---------- Forwarded message --------- From: Ed Cable <[email protected]> Date: Fri, Jun 5, 2020 at 4:22 PM Subject: Re: Meeting to Discuss Connecting Payment Hub EE to Mobile Banking and Wallet Apps to Receive Request to Pay Notifications To: Naman Dwivedi <[email protected]>, shivansh tiwari < [email protected]>, Devansh Aggarwal < [email protected]>, ANKUR SHARMA <[email protected]>, RM <[email protected]>, Ishan Khanna <[email protected]>, Abhijit Ramesh <[email protected]>, Garvit Agarwal < [email protected]>, Ashwin Ramakrishnan <[email protected]>, Shivangi Singh <[email protected]>, Istvan Molnar < [email protected]>, Józsa Kristóf <[email protected]>, Nébli Zoltan < [email protected]>, Sashank Mishra <[email protected]>, Saksham Handu <[email protected]>, <[email protected]>, Pranjal Goswami <[email protected]>, Ebenezer Graham <[email protected]>, courage angeh <[email protected]>, Bharath Gowda <[email protected]> Cc: <[email protected]>, <[email protected]> Hi all, Just to follow up on the second leg of the meeting we had to discuss the notifications sub-system being used for the Request to Pay API for the mobile wallet as well as a general update about the mobile wallet use case in the near term to have it work in the new lab environment. https://us02web.zoom.us/rec/share/5-oyIZrd1mZLYNLutAL8avU5H9zPX6a8gClL-fEPyh5OYllEDFBX8_ENod_Zeup_?startTime=1591200315000 >From the discussion, it appears the current manner in which notifications are generated and stored in Fineract 1.x will work for the request to pay API. However we must ensure that the self-service users (which should be in the same users table but just denoted as "self-service") are subscribed to this topic to receive the notification. All students working on the customer-facing apps for Fineract 1.x, should familiarize themselves with the notifications system (see previous design and how it works) as the client-side integration should also be complete for mifos mobile and mobile wallet. If you have any questions, please share them publicly on the mifos and fineract dev list and discourse forum as it's a valuable discussion for community. @Ebenezer Graham <[email protected]> can we grab some time to discuss integration with the Fineract CN notifications microservices. We identified some small action items to take to make the current mobile wallet work for the prior 2 Mojaloop use cases and soon the 3rd Mojaloop use case in our lab environment. We need to: 1) Provide Shivansh and Devansh with both the updated environment details of the Fineract, Payment Hub instances in the new lab environment as well as the updated API endpoints. 2) Confirm where the MSISDN is being stored as an additional attribute for Fineract. 3) Ensure that the Interop users/customers that are created in the Fineract instances have an associated self-service user account and to add these credentials to the lab environment Google sheet. https://docs.google.com/spreadsheets/d/1b8BRajrpNacFNEH6gGENDVWIGusLc0pGRd6MnKbqTKM/edit?usp=sharing Once the above is in place, we should be able to have the initial 2 mojaloop use cases of peer to peer transfer and payment via QR code work with actual authenticated self-service users (not just hard-coded JSON user data). On Tue, Jun 2, 2020 at 9:19 AM Ed Cable <[email protected]> wrote: > Hi everyone, > Thank you for those who were able to join, especially to Pranjal for > joining short notice. We made some good progress in the discussion but will > continue this conversation once Istvan can join during part of our call > tomorrow that was scheduled for Open Banking fintech app requirements. > > Here's a summary of what we concluded and outstanding questions/next steps: > *Fineract 1.x* > > - Creation and Storage of Notifications on Back-End > - Per the design of Pranjal and implementation by Courage and > Adhiyan, the notifications subsystem for creating and storing > notifications > through the publisher/subscriber/topic model is complete and more > recently > has been updated by Nazeer to work with FCM messaging > - Slides on Design of Notification Subsystem: > > https://docs.google.com/presentation/d/1jzqEQxxRYa1ZvN_SXLRwDgXBux1cb3_IMBWbdS7rRV0/edit?usp=sharing > - Link to PR updating notifications for Fineract - > https://github.com/apache/fineract/pull/421 > - Receiving notifications through channel apps > - Working for Community App > - Works for Mifos Mobile and for Mobile Wallet > - PR for MIfos MObile for FCM Messaging - > https://github.com/openMF/mifos-mobile/pull/1180 > - Questions/Concerns > - Based on Pranjal's current understanding of Request to Pay use > case, he believes for notifications like payment requests that are high > priority, time-critical, and actionable, we should enhance > notifications to > generate and store them in a different manner than the current generic > system for information updates > - Istvan, within Zeebe, how many times will we re-try sending > out the payment request notification if the payer doesn't take > action? > - Would the flow be Mojaloop API to Connector in Payment Hub to > Fineract and then to Channel? > > > *Fineract CN* > > - Creation and Storage of Notifications on Back-End > - Separate notifications framework created by @Ebenezer Graham > <[email protected]> who i'm looping into this discussion. > > > *Other Questions* > > - *Mobile Wallet Authentication via Self-Service Users* > - Shivansh shared that for the integration that he and Naman did > last year to support the peer to peer and merchant proximity use cases > that > they had to this all with just hard-coded JSON users based on the 4 demo > user accounts and that they weren't aware of how they would be able to > actually authenticate via self-service users to initiate these > transactions. > - So we both need to for the interim, ensure we can support doing > these transactions in the mobile wallet via self-service APIs but then > once > we've fully mapped the entire app to use Open Banking APIs, do the > transacstions via that manner. > - @Istvan Molnar <[email protected]> for our demo web app which > allowed a customer to scan a QR code and make payment to a merchant, I > thought we were using self-service API, I guess that was only for a > staff > person that was acting like a customer. > - We need to have this transaction actually be supported from our > self-service API (in interim) and then open banking API. > - I'm glad this call flagged this as it's an important distinction > that I didn't realize we weren't yet supporting because for our lab > environment, the P2P and proximity payment are supposed to be > customer-initiated scenarios, not staff ones. > - *This all speaks to the importance and criticality of having our > lab environment use the community-developed channel apps and not just > reference demo apps as we need to try to closely model real-world > scenarios.* > > > Thanks, > > Ed > > > > On Mon, Jun 1, 2020 at 11:44 AM Ed Cable <[email protected]> wrote: > >> Hi Mobile Wallet and Mobile Banking teams, >> >> As part of the ongoing work with supporting the Mojaloop request to pay >> API, we will finally get the opportunity to work more closely with the DPC >> team to incorporate our community-developed channel apps into the lab >> environment. Primarily, we need to be able to demonstrate the end to end >> scenario where notification generated by the payer needs is received by the >> payee so they can take action to initiate payment based on the request. >> >> I'm setting up a call with our mentors and interns for the mobile banking >> and mobile wallet apps to discuss a few of the following points with >> Istvan, Kristofz, and Zoltan: >> >> >> - What are the endpoints for the communications? >> - How are notifications being generated? In Fineract or in the app? >> - What form factor can notifications be received via? In app through >> FCM, via SMS? >> - How are channel apps invoking the credentials? >> >> I'm going to send out an invite for 1500GMT on Tuesday. >> >> Cheers, >> >> Ed >> >> > > -- > *Ed Cable* > President/CEO, Mifos Initiative > [email protected] | Skype: edcable | Mobile: +1.484.477.8649 > > *Collectively Creating a World of 3 Billion Maries | *http://mifos.org > <http://facebook.com/mifos> <http://www.twitter.com/mifos> > > -- *Ed Cable* President/CEO, Mifos Initiative [email protected] | Skype: edcable | Mobile: +1.484.477.8649 *Collectively Creating a World of 3 Billion Maries | *http://mifos.org <http://facebook.com/mifos> <http://www.twitter.com/mifos> -- *Ed Cable* President/CEO, Mifos Initiative [email protected] | Skype: edcable | Mobile: +1.484.477.8649 *Collectively Creating a World of 3 Billion Maries | *http://mifos.org <http://facebook.com/mifos> <http://www.twitter.com/mifos>
