Agenda

Presenter

Duration

Discussion

Review pending action items

 @Esther Ogunjimi

 10 minutes

TECH-654: Updates based on technical reviewDone

Status update

BB Leads @Meelis Zujev (Deactivated) @Steve Conrad @Tarek Rashed

 45 minutes

Scrum standup-style (what we did this week; plans for next week; blockers/pain points and open/unresolved questions?

• Specification 1.0 publication

TECH-615: Building Block Alignment to Template for 1.0 PublicationDone

TECH-657: 1.0 Read-Through Required ChangesDone

• Final read of the 1.0 publication ongoing

• Only the people in the approval group will be able to merge any change request

• Wave 3 BBs

• USCT use case definition TECH-225: Implement INST-1 - Unconditional Social Cash Transfer Use CaseIn Progress

• Testing https://docs.google.com/presentation/d/1QWQQSxSIOEIElzJMbyZDaPhooW7ULRE0j5MZHLg6Ud8/edit#slide=id.p

  • Satya - How do we look at the different model of testing? Our current approach of API testing is more of data oriented API testing - writing Gherkin scripts. There is another way of testing which is structure oriented as to data oriented. @Taylor Downs and @Farai Mutero discovered another way of carrying out tsting through the process if writing test cases for WF BB - it is not just data oriented but structure oriented testing. This is about not giving specific data examples as inputs, but overall identify the the API structure format. We can do structural oriented test cases other than just data oriented that is currently been done.

  • Taylor - WF BB test is written such that when for instance when you request a patient from digital public good X, you receive an object with at least a name attribute whose value is a string.

  • Ingmar - Sometimes, the content is important to validate the BB candidate.

• Sandbox Team

  • Concluded the stimulation wireframe testing journey

  • Working toward deployment validation scripts - small scale testing harness for toward Sandbox upon existing BBs. Validating to ensure the scripts are all working perfectly.

  • Speeding up the MVP journey and aligning with MOSIP and MiFos team. Still deliberating on how to build the MVP happy flow in action for really BBs.

• Architecture Team

  • Final reviews of the technical specifications.

  • concluded on adaptor conversation

Payment BB expectation

@Kibuuka, Arnold

10 minutes

To align with other BBs on areas of alignments Cross cutting requirements - clarifications

Steve - what information is needed to store the account mapper? Do we want to store the actual account information? What financial service provider will be used? Is the account mapper required to store the financial address or just the address of the FSP?

Vijay - It is the intention not to keep the foundational ID in the mapper but in the functional ID. However, the functional ID cannot be used with the FSP.

In situation where there is switch, there will be oracle that will map the financial address to what is already pre-existing; no information will be required from the user but the information will be directly from Oracle. In case where the switch is not available, the user will be requested to enter the information directly.

All information is stored in tokenised form.

Satya - How much of the implementation is MiFos specific? Can we pick out actual components and have different DPG for payments or the Oracle or the FSP or the switch and still try to assemble a payments BB going forward? How does GS payment BB retain it originality and still be able to have MiFos and other DPGs.

Vijay - the account mapper will be custom developed for payment BB. The oracle will be Mojaloop and for switch stimulation. MiFos will be used for the voucher engine, payment server and payment hub. All these has been customised according to GS payment BB requirements. So, the API that's being exposed need to comply with APIs for payment hub.

Arnold - The original components in the payments building  are logical components of the payments hub.

Ingmar - When moving information via Information Mediator, will the tokens be put together with the messages?

Alek - This is up to how the APIs are designed

Concept of adaptor (contd)

@Steve Conrad

15 minutes

Adaptor Concept

• Adaptor is not used for out bound request

  • Taylor - what types of technologies are most appropriate for building adapters given these three sort of use cases?

  • Steve - there are tools like Apache Camel or Ballerina which is an orchestration language you know which certainly could do it. But, will that be too much or heavy? The third option is custom code which is the least preferred option. This is an open questions

  • Satya - with regards to the ongoing USCT work, can this be implemented within the current USCT work?

  • Wes - building out our own infrastructure or even having our own designs is not gonna be enough. We should have some guidance as we get into complicated computing intensive adaptors.