Minutes of the weekly meeting of the Mojaloop Design Authority 2021-07-14 10:00 UTC
- Sam Kummary firstname.lastname@example.org (SK)
- Henk Kodde (HK)
- Simeon Oriko email@example.com (SO)
- Justus Ortlepp firstname.lastname@example.org (JO)
- Miguel de Barros email@example.com (MDB)
- Lewis Daly [firstname.lastname@example.org (LD)
- Michael Richards Michael.Richards@modusbox.com (MR) (temporary chair)
- DA issue #80: Mojaloop integration into the action FRMS (raised by JO)
- Minutes of last meeting accepted, should they exist
- HK introduced the Actio product. Preferred integration approach is to act as a listener on the Kafka events topic.
- MDB: events may be missing information, or events may be lacking (e.g. admin logs) HK: looking at POST /quotes and PUT /quotes, POST and PUT /transfers.
- JO: what about loading new customers, or admin actions. MDB - no plan to include these on the events queue at present. JO - this establishes a pattern. MDB- happy with that as an idea.
- MDB: this is for current architecture. JO - will have to revisit when reference architecture implemented.
- MR - what about differential access to events? JO - should be part of the listenre function, which should belong to Mojaloop. MDB - could have a pre-filter to stop people getting access to messages they shouldn’t. Put messages on a new topic, Action just consumes all the messages in that topic. Should this be a separate Kafka in the DMZ? Question of latency: MDB thinks this isn’t a problem, JO worried about it.
- Order of preference from JO: 1) connect to existing topic; 2) create new topic inside Moja platform; 3) create new Kafka functionality in DMZ. Differnece between 2 and 3: MDB, there isn’t one.
- JO: what are the next steps? In the actions…
- MR: we are looking at picking up events from the event queues, and therefore in their canonical form; but what about the difference between FSPIOP and ISO 20022 messages in their original forms? In a very content-rich format like ISO, there may well be information in the message that doesn’t appear in the canonical form, but might be of interest to Actio. Potential answer: we should be reading information from the topic which is being read by the Notifications BC - that is, the actual message which is being forwarded to the recipient.
- JO to revise issue on Github to reflect our discussion.
- DA members to comment on proposal on Github.
- JO: raise this issue for review by reference architecture group.