Contents
On this page we collect migration issues that will still have to be looked at for a full migration to the Target Technology Stack .
Custom Modifications
Impact: depends, will have to be collected per country by implementation partners
push for customizations based on module configuration
Custom Modifications in Nepal
β a lot of custom functionality: https://openimis.atlassian.net/jira/software/c/projects/ONI/boards/43
(tender in preparation as part of a general openIMIS maintenance contract) : Swiss TPH
establish list of functions that need to be migrated
prio 1: existing modification in legacy / hybrid version
prio 2: new feature requests (must)
prio 3: new feature request (nice to have)
Custom Modifications in Tanzania
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
Custom Modifications in Cameroon
HIV
π§βπ report on migration needs done by STPH (-> Implementers) - covered in Project: Customization Cameroon
EDUCASH
Cash-Transfer scheme => to be migrated to modular?
Custom Modifications in Gambia
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)
Lock Mechanism
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
Reports
List of reports: Wiki: Report module, migration status: https://docs.google.com/spreadsheets/d/1ORCdW5qajBbDT4BaKmAKf6W7X4wbs2Rcd0EQNEVRRzQ/edit?usp=sharing
wip - which reports still need to be migrated? which ones are still used?
some reports donβt work
list of reports to all sites with feedback on what they are still using (no nice-to-haves!)
also have a look at https://www.metabase.com/start/oss/
Documentation How-To / Best-Practices of Migration
Admin Tools
List of tools that make it easier for windows server admins to switch to linux/postgresql.
If your desktop computer / server usually uses a package manager to install software (e.g. Linux distributions), try installing the package from the standard repositories of your system first.
Domain | Name (link) | Browser | Linux | Win | FOSS | Description |
---|---|---|---|---|---|---|
DB Admin |
|
| π§ | Comfortable PostgreSQL DB Admin tool | ||
SQL Client |
|
| π§ | Comfortable Visual SQL client with ER diagrams | ||
SQL Client |
|
| π§ | simple SQL client | ||
Server Monitoring |
| π§ | Server statistics daily / weekly / monthly | |||
Server Admin |
| π§ | web-based server administration | |||
Explain Plan Analyser |
| π§ | Visualise query execution plans: |