Agenda

Presenter

Duration

Discussion

Review pending action items

 10 minutes

https://govstack-global.atlassian.net/browse/TECH-654

https://govstack-global.atlassian.net/browse/TECH-670WIP

Messaging BB candidate: Rapid pro. Discussion on adaptation requirements underway

https://govstack-global.atlassian.net/browse/TECH-742

Status Updates

Leads

30 minutes

https://govstack-global.atlassian.net/jira/plans/reports/6EFAz

Wave 3 specifications update - @PSRAMKUMAR

UI/UX BB has submitted their draft spec to the architecture team for review.

eMarketplace BB is completing today and will be submitted Jul 21, 2023 to the architecture team.

GIS and eSignature BBs also will be submitting their specification w/c Jul 24, 2023

Testing team

• Most of the reviews are completed. Payment BB test review has some conflict in the PR. This will be resolved and merged.

Sandbox team

Working to integrate new BB into the UC.

Working Djibouti UC

Simulation will be published on public channel w/c Jul 24, 2023

Architecture team

• The team will be addressing infrastructure and deployment using Kubernetes and information mediator.

• The team will be discussing an issued raised by Juame around authorization and arbach. How to associate particular permissions and roles with users within the various building block contexts.

Vasil - not knowing what is connected to BBs is over simplified.

Karim - Currently APIs exposed by other Building Blocks require authentication. (e.g. if we are using APIs provided by ID building block, we have to authenticate) and get a token before calling the API.

Steve - we are proposing that the adaptor would hold the authentication credentials needed to get the API token

Capability definition

@Artun Gürkan

15 minutes

23-07-12 Introducing Idea of Service Blocks (Capabilities) This presentation is from a UI/UX designer perspective.

Steve - Wes and Steve will develop a template for the capabilities service blocks.

Testing and Integration

@PSRAMKUMAR

20 minutes

Questions from testing team:

Should we establish two separate types of test suites for BBs in corresponding folder - /mocks and /emulator of corresponding github folders. Question who will develop mocks and who will develop emulators - prioritized roadmap

• Are emulators use-case specific? 

• DPG compliance :  is 100% API coverage essential for a DPG to qualify? What if based on a specific usecase, a partial set of APIs are needed and a DPG is fully complaint but not all of the APIs of the BB spec? Should compliance need to be qualified in relevance to a Use-case or not? Should we have  use-case based test suites in addition to  maintaining a full test suite?

• Building a generic adapter that can transform any payload based on a JSON schema mapping input output name fields and format. Developing a simple tool to map field names and generate the JSON schema for different adaptations.

• Testing UI level switching between BBs

Ramkumar - Are we building in mocks for consent BB? And who is building it? Will it be GoFore or SolDevelo? Are we developing a mock and an emulator for consent building block?

Discussed with Consent BB that a mock emulator will be developed because it is important for the Sandbox team. Leasing with the SolDevelo team for this.

Satya - Benjamin in the Consent BB has been taking innovative approach with the Consent BB. He has developed this whole Django - he is able to generate the APIs as well as the mock tests using his Django framework. The test suites developed by Benjamin will need to be migrated into the overall test suites SolDevelo has developed.

Vasil - What Benjamin developed is in Phyton and the Sandbox team is developing in Java. The team could have some Python, but cannot modify and extend. It has to be a ready to use product which is generating 100% or become dependent on the Consent team. The dependency is slowing down the implementation of the scenarios.

What is the standard for emulator of a building block? Or what is the reference implementation definition if done when we are talking for API specification?

Pawel - Are we developing emulators for each BBs?

Damien - It would be good to define some kind of requirements for the emulator and see how current solution with Mokum meets them, and what adjustments perhaps we would have to make to Benjamin solution (Django framework) to make it work for every building block as well as sandbox environment.

Steve - The idea of an emulator solves a lot of problems. We need to define clearly what the scope of this project would be and then identify the resources that will implement it.

Do we want to develop one single implementation that could receive an open API spec?

Alek - It is impossible to have one emulator for all BBs because the specs is syntax of goals and there is no semantics for each endpoint.

Satya - Why did we build the testing framework the way it is using the BDC model and the cucumber gerkins scripts? Because the objective is not to build emulators or not to have every DPG in the sandbox but for every DPG to show they can demonstrate their compliance against the GS APIs. We wanted a simple model where these DPGs can become examples that can be tested using an automated framework and the results can be shown on Circle CI.

There were no example implementation for Consent BB when we started out.

Steve - The candidate DPGs are quite large and it is not realistic to deploy them in the Sandbox.

How we converge on a common format for Registering Institution ID

@karim.jindani

15 minutes

Open

Open

This is essential to be defined for consistency in the spec. So that all BBs are aligned especially in the case of multiple Institutions or Gov Entities on an instance.