...
Table of Contents | ||||||
---|---|---|---|---|---|---|
|
Custom Modifications
Impact: depends, will have to be collected per country by implementation partners
push for customizations based on module configuration
...
payment layer through REST API - dedicated API for GePG (Government ePayment Gateway)
MUSE API exists (will not be changed) - fully based on modular version
GePG API exits in legacy
needs to be migrated to modular architecture (as a custom API)
capitation payment,
commission
Covered by Project: 2022.T1c Modularisation III :
GePG not covered for the implementation in TZ, but support in global components might be possible
🧑🏭 mobile apps on REST API
🧑🏭 specific reports → migrate to ReportBro https://docs.google.com/spreadsheets/d/1ORCdW5qajBbDT4BaKmAKf6W7X4wbs2Rcd0EQNEVRRzQ/edit?usp=sharing
🧑🏭 Download master data
list of beneficiaries
🧑🏭 Funding
…
capitation payment configuration in Product
batch run
capitation payment SP
batch run SP
...
Cash-Transfer scheme is in progress of migration
REST API
Impact:
Mobile Apps will not work any more
GOTHOMIS & Payment Layer in TZ
stuck to MS SQL because of stored procedures that are called from REST API (ca. 45)
Discussion:
C#-part can be re-used, but depend on stored procedures
done - needs to be compiled for .net core per Windows and Linux (done in Docker)
Mobile App on REST
Need new mobile app on FHIR → budget needed
ePayment on REST
migrate APIs to python = new adapter to payment switch → budget needed
Interoperability on REST
e.g. GOTHOMISs & afyacare
will remain on rest - will need to be done by GOTHOMIS & Afyacare
done - Added to Docker packaging
done - issue with env variables (ex. DB connection string)
done - sharing of files (ex. Insuree pictures)
rejected - Test REST API against PostgreSQL - not practical as REST-API will not be migrated on PostgreSQL
list of interactions with DB: https://docs.google.com/spreadsheets/d/1XdamXxLejmPRzM5xN8dCSPSIbfNv1PgJ/edit#gid=1496686413 - will not be needed after
create/modify payment layer adapter on the openIMIS side for TZ
Stored Procedures
Impact: depends
Discussion: need to list remaining stored procedures that will not be migrated
https://docs.google.com/spreadsheets/d/18XxbBsPXvHrq7Enu7Bj02WpE1GiIaslNP1aMK6ECQcU/edit#gid=0
done:
in modular version: everything needed was migrated either to Python (business logic) or PostgreSQL (a few small queries)
SPs for REST API will not be migrated - need to run on MS SQL (-> see there)
...
will need to be migrated to PostgreSQL?
testing - PostgesSQL uses low isolation level by default - might solve the problem
might not be needed, documentation on how to approach potential problems
wip
Legacy Offline Mode
Impact: none
doesn't work in legacy version, not used
needs popping up but will have to be addressed as new features
MS-SQL Driver in Django
Impact:
Custom Access to MS-SQL DB
affects JSON-B column access
hinders upgrade to Django 4
Discussion:
only a problem as long as s.o. is using MS SQL
maybe there are new drivers
solved - there is an official MS driver for Django now
DB-Initialisation Script
Impact:
new installations (new, empty DB) not yet using all attributes
migration script need to know DB version to adjust to all scenarios
Discussion:
done - DB - initialisation:
two separate INIT scripts for PostgreSQL & MS SQL available
done - legacy migration:
migration script for the legacy data available
done - future development will be against PostgreSQL
other DB will have to use Django Migration scripts to fork to their DB system (automatically through Django “make migration“ - might need manual adaptations)
documentation needed
most is done automatically at startup
create a link in each release note point at a migration path for that version with manual exceptions
testing of the documentation is needed
...