Yet to confirm

Integration

Nico Lueck

Concept on integrating the TC/architecture team work on adaptors with the sandbox team Minimum Viable Product (MVP) eg. Happy Flow

For Sandbox development, the initial concept of an MVP for integration took one flow of the user for unconditional social cash transfer use case called the happy flow.

However, MiFos, MOSIP & Xrd discovered they need to wait for ITU contractors to either come up with an interim solution just for the MVP to finalise their work on customising their products towards GovStack specifications and have a fully compliant solution.

Alternatively, we could wait for these three solutions and these three providers to finish and have this fully compliant solution and they are integrated. This is the integration scenario of just one fully compliant system being integrated but we have not yet covered the integration scenario of the partially compliant solution which needs an adapter to be integrated.

While we wait for the building block providers of MOSIP, MiFOS XRD to come up with their compliance solution, we could work on open emails and registration to integrate them via an adapter but, the concept of an adapter is not designed yet, the team is blocked by this.

The team is proposing to continue in close collaboration with either the architecture team to go into fast sprints for design and testing. Also, find people from the specification side and developer to go into sprints next month - who will dedicate up to 4 hours weekly to the work.

• Steve - there is an adapter concept but it has not been fleshed out. It might work best to form a small dedicated team of one or two BB Leads, a developer, representative from the architecture team, Sandbox team to commit significant time to sprint.

  • What should the technical approach be for creating that kind of adaptor?

• Aleksander Reitsakas volunteered

• Wes - the delay is on the architecture team e.g.,coming up with the design for how it will be implemented. The GoFore team can be the developers to work on this. We could also have people from the Sandbox team engage with the architecture team to focus on getting the design done as soon as possible, then we can iterate on the design with work from the GoFore team.

• Ramkumar - Do we have a Use Case where we can map the requirements to the adapter to the specific Use Case?

• Meeliz - Use Case should start with a minimum requirements because the adapter should be tested from minimum to maximum, not to just take a full scope of a functionalities and start to build. The MVP journey should be the first reference case for building the adapters, and the application that are not contracted can be as a test softwares for those adapting journey.

• Vijay - the payment BB is in the process of finalising the APIs related to bug disbursement which will be used by the unconditional social cash transfer use case because these were not finalised in the requirement spec. The payment flow captured in the above document needs to be reviewed to reflect the bug disbursement process.

Compliance concept

Nico Lueck

Update on compliance concept and current projects to get candidates compliant Compliance Concept and Integration Scenarios

• When do we call which software to be compatible or compliant? What criteria are to be met?

• Satya - It would be a good idea for the compliance concept to also link with the compatibility ratio coming out of the test harness.

• Wes - We have a compliance process that we are trying to create and there is need to have things in place to ensure it can be supported so that we can run through a compliance process with actual software.

  • Do we have a deadline for when we want that to be ready?

  • What needs to happen from the technical perspective for us to be able to support whatever the compliance process looks like at this first stage?

• Nico - there are some dependencies that need to be in place i.e., specification 1.0 publication and having test harness. Although there are projects that have started while the compliance concept is not finished.

• Wes - We should come up with specific deadline for when we want to have this ready, to make it easy to prioritise the work on this dependencies.

• Steve - We could define some candidate tools we want to try to integrate? What test do we want to be able to run? The Sandbox team needs to define some immediate technical steps to spin up couple of examples, and then build out.

Status update

BB Leads

Steve Conrad Dominika Bieńkowska (Deactivated) Meelis Zujev (Deactivated)

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

• Specification 1.0 publication

  Jira Legacy
  server System JIRA serverId f5c6bdaf-d23e-347d-a1e8-579e20a81dda key TECH-206

  • Consent BB

    • Resolving v1.0 spec - almost there, most comments resolved. "Workflow" chapter requires rewriting and redesigning of workflows - found a compromise that allows to finish v1, and push some of the changes to the next release of Consent BB.

    • Internal BB workflows vs inter-BB workflows - we keep and relocate within spec v1.0 the existing Consent BB workflows (predominantly external / inter-BB workflow and create the internal workflows in the next versioning of spec

    • Assessing the proposals for Consent BB proposals. In the final stage of selecting the vendor. Build takes 6 months - all bidders propose nearly the same timeline.

  • Payment BB

    • The data structures section need reviewing.

    • On the API section, there are some comments that need to be included based on comments from MiFos.

    • Working on the account map implementation, the bug disbursement API and voucher management documents for the G2P API that could be implemented in Sandbox afterwards.

    • Payment team, Sandbox team and MiFos team will meet to discuss implementation in Sandbox.

• Wave 3 BBs

• USCT use case definition

  Jira Legacy
  server System JIRA serverId f5c6bdaf-d23e-347d-a1e8-579e20a81dda key TECH-225

  • Had the final review of the Registration BB steps, waiting for sign off from the BB Lead.

• Testing

  • Finalised all the APIs for messaging BB. Next priority will be the Payment and Registration BBs.

  • Improving the testing app; adding sorting, filtering.

  • Reviewing and adding to BBs and to the software.

• Steve - We could start to build out the example implementation for the EPR Use Case.

• Satya - The three BBs providers have onboarded and started sprinting. We should prioritise completion of the test harness before the end of May and target a sprint by the end of May to align the USCT demo integration work with the sandbox. Also, see how much of the existing BB implementations can be part of the demo. Because before these BB products can integrate themselves to the sandbox, they first have to get tested using the test harness, and only then we can go ahead.

  • We need to prepare the set of documentation or the steps that are needed for the test harness.

  • On ERP, let there not be any corresponding work on the BB providers right now, so it does not hamper the rest of the implementation timeline.

• Sandbox Team

  • Completely installed full payment application into the Sandbox and created the entrance there.

  • Demo for unconditional social transfer

• Architecture Team

  • Focusing on the review process and preparing for the v1.0 release.

  • Made changes to the BB template and working on aligning the content with the template.

  • Will be discussing the adaptor after the review process