9 Internal Workflows
This section provides a detailed view of how this Building Block will interact with other Building Blocks to support common use cases.
9.1 Administrative/Analyst Functions
The Digital Registries building block facilitates the foloowing main internal workflows:
9.1.1 Create a registry database in User Interface
9.1.2 Process registry data in User Interface
9.1.3 Create registry database in API interface
9.1.1 User Story 1 - Create registry database in user interface
As an Administrator/Analyst I want to use a web user interface to create a register database (example registry use case - social security program) so that I can configure and launch the registry database instantly to be used by internet users and client systems (e.g. Registration Building Block, Information Mediator Building Block) via web interface and API.
Actors: Analyst - An administrator user who is creating/changing the registry database schema. The main actor/user in these requirements is the Analyst.
Preconditions:
User is authenticated;
User is authorized as an admin;
User interface is a web interface;
User has internet;
System has electricity.
Process:
Create a new registry database project.
Define the database fields.
Publish the database.
Validate/configure the API services.
Manage user rights to access the database and APIs.
Post conditions:
System contains a database that is ready to process new data.
System has API services to CRUD (Create, Read, Update, Delete) data (and API to validate if data exist).
User can enter data to the registry via web user interface (UI).
User can see log information in the UI.
User can see statistics in the UI.
User can give authorization to use the database and process data.
System contains a database that is ready to process new data.
System has API services to CRUD data (and API to validate if data exist).
User can enter data to the registry via web UI.
User can see log information in the UI.
User can see statistics in the UI.
User can give authorization to use the database and process data.
9.1.2 User Story 2 - Process registry data in User Interface
As an Administrator/Analyst, I want to process (Create, Read, Update, Delete) registry data so that I do not have to know the query language.
Actors
Analyst: the main actor in these requirements is the Analyst/Administrator.
Data owner: a physical person whose personal data is stored in the registry.
Preconditions:
Analyst is authenticated and authorized to use the Building Block and process data in the database;
The user interface is a web interface;
User has internet;
System has electricity.
Process:
Analyst searches a record via search or filter function;
Analyst selects a record;
Analyst processes a record;
System stores changes to the Change Log database.
Postconditions:
Processing changes by Analyst are done and log for change is created.
9.1.3 User Story 3- Create registry database in API interface
As an IT developer, I want to Create/update/delete registry database schema via API services.
Actors
IT developer (Developer): Main actor in these requirements is planning to open a new business program and web form to capture applicants' data. Captured data must be registered in the registry. In this use case, a Developer is any user who is using API services to create and manage registries database.
Preconditions:
Developer is using API with a client system or a script that is connected to Information Mediator Building Block. Client system is any Building Block that is using API services via Information Mediator;
IT Developer (Information Mediator organization) has been given authorization to Create/update/delete database schema via API services.
Developer has internet;
System has electricity.
Process:
Developer uses a client system to edit the registry database in the Building Block. Developer can:
Create database schema;
Read database schema;
Modify database schema;
Delete database schema and all data in it.
Postconditions:
When Developer is authorized to use Building Block API then the Digital Registries Building Block allows processing CRUD (Create, Read, Update, Delete) schema of a registry, and all authorized users can;
When Developer is not authorized to process/CRUD the database schema, the system allows to process schema of all databases where an anonymous user has been allowed to edit the database schema (simplification for GovStack Sandbox instance);
When a user has no authorization, one can not create nor change (CRUD) any schema in the Building Block.
9.2 Applicant Functions
9.2.1 Process data in API interface
9.2.1 User Story 4 - Process data in API interface
As an Applicant, I want to process CRUD (Create, Read, Update, Delete) data in the registry database.
Actors:
Applicant - The main actor in these requirements is an applicant via the client system. In this use case applicant is any user who is using a client system (Registration Building Block). For example, a Health Care worker is an applicant in this user story; a mother, using the Registration Building Block. An example client system in this document is Registration Building Block.
Preconditions:
Applicant is using client system (e.g. Registration Building Block) that is connected to Information Mediator Building Block;
Client system has been given authorization to access Registry to process (CRUD) information;
Applicant has been given authorization to access Registry to process (CRUD) information;
Applicants are registered in the system and able to use authentication. Applicant is Authenticated by client system or Security Building Block (Authentication).
Applicant has internet;
System has electricity.
Process:
Applicant uses a client system to process data in the registry
Applicant can create data;
Applicant can read data;
Applicant can update data;
Applicant can delete data;
Applicant can create or update data;
Applicant can validate data.
System logs all processing events in the dedicated audit registry.
Postconditions:
When Applicant is authenticated by a client system (e.g. Registration Building Block) the registry allows processing (CRUD) information from the registry. All users who are authenticated can read data.
When a user is not authenticated in the system, the system allows processing (CRUD) data from all databases where an anonymous user has been allowed to process data.
When a user has no authorization, one can not process (CRUD) any information in the registry.
Last updated