Agenda

Presenter

Duration

Discussion

Review pending action items

 @Esther Ogunjimi

 10 minutes

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

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

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

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

Satya - we need to look at the overall eGovernment interoperability level.

Countries typically develope eGIF - e-Gov Interop Framework which contains standards across different aspect

Steve - the standards we are referring to are the domain standards within a particular building block.

Wes - for consistency, we follow a pattern similar to what was done for guidelines with assumption that the standards that have been mentioned in the core cross-cutting section are the default. And for business specific standards or domain specific ones, they should be added to the building block or if there's any changes to those guidelines (i.e., different version or using a different type of standard for some specific reason) those should be called out in the section.

Status updates

• Specification release progress - September

Leads

30 minutes

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

Wave 3

UI / UX, eSignature, eMarketplace specs are being reviewed by the architecture team. Waiting for GIS BB to send the spec to the team for the initial review. The initial review is planned to be completed by mid August.

USCT

USCT is finalised

The outreach communication steps for example implementation is reviewed and completed

Will be finalising the first version of registration steps

Testing

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

Working on open image integration

Sandbox team

The team is including smaller steps to USCT but the prototype with emulators is running and once the BBs are deployed, they can be exchanged but there are minor issue to be resolved with the deployed.

Working on weak portal which is the entry point to the simulation where BBs are picked is in drafting phase.

Emulators

@Steve Conrad

15 minutes

https://github.com/GovStackWorkingGroup/sandbox-bb-emulator

In scope or out of scope

Sandbox team has developed use-case specific emulators to act as lightweight implementations of BBs. Emulators should remain as a part of the sandbox infra and are not part of the BB testing harness/process.

Nico - the main difference between the mock and the emulator is that the emulator is a little more dynamic with a database behind. We will not be developing emulators for every UC in each BBs in the future but can do that for the first two UCs in the Sandbox.

The GoFore team implemented the emulators.

Satya - Treating the test harness as a mock is reductionist as that was not the only intention. The approach and strategy behind how the test harness was developed is more from a compliance perspective.

Irrespective of whether or not we have emulators for different use cases going forward, we need to enrich our compliance model which the automated test harness is the integral part. We should not be comparing the test harness and emulator as the compliance model for the test harness needs to exist. We need to strategically consider how we can have an external DPGs to be able to demonstrate the compliance towards it.

There might be a sunset for emulators once we are very clear on how the sandbox can quickly spawn off new use cases or be able to demonstrate new use cases using DPGs or emulators.

David - How will the emulators be evolved?

Nico - the emulators are dependent on the version of the API in the UC.

Wes -We can try to limit the amount of customisation and custom logic that is included as a part of the emulator, but by creating this thing that does have some logic in it and doesn't need to be maintained, we are incurring more overall things that have to be updated continuously as new versions of the specifications come out.

As suggested to Nico, we want to limit the amount of custom things that we produce that have a very limited value.

The priority for the sandbox now is simply to create a demo for a use case (hopefully multiple in the future). Being up-to-date with the current release is not as critical

Nico - having the whole sandbox current with the specifications is the real challenge and especially the actual building block candidates.

Taylor -this is the point of the version approach in the test hardness. So for three candidates identified by BB, and see their level of compliance against version one of the API specification.

When version two is proposed of the API specification, the reduction and compliance are seen immediately. If you decide those 3 candidates are important. More effort should be put on adapters and less effort put on me the emulators and the mocks.

Steve - the emulators are to get the Sandbox team through until there are suitable candidates that are able to be instantiated.

Do those emulators live in the building block repositories alongside the mocks?

Nico - The emulator is use case specific because it just reflects what is in the new steps of the use case needed. Everything in the repositories of the building blocks are not use case dependent, but mainly dependent on the building block or they are more generic.

Will it be confusing if there is one thing which is very much customised to one use case only in this repository.

1. Emulators can live with the sandbox infra just outside of the test harness. Emulators are use case specific lightweight implementations of a building block candidate that are for use in the sandbox. Not part of test

Having Test Mocks with the newest API spec version is a MUST. Having the sandbox and BB current with a newest API specs version is nice to have.

Data for Secure Page for entering financial information for validation with Registration BB

MiFos team

20 minutes

UX Switching

Presentation to TC 3rd Aug

Is Candidate Products getting updated?

@Nico Lueck

5min