The Target (modular) Architecture of openIMIS foresee several deployment possibilities and is installed "aside" a legacy installation. Aside may mean:
- on the same server, but as a separated (set of) process (listening to distinct ports)
- or on separated servers connected to each others behind a 'gateway' in order to look like a single one for the users
openIMIS - wiki - concreet installations.odp
When installed on 2 distinct servers, the legacy/new openIMIS installations are variations of the following configurations:
The LEGACY_* installation is the "usual" openIMIS setup.
The only thing that is required is to open the 1433 port (database) for connections coming from the new server (NEW_IP).
The NEW_* stack is assembled via the openimis-dist_dkr docker-compose configuration and, today, provides the following components:
- the gateway is built from openimis-gateway_dkr docker and is dedicated to secure and route incoming calls to the appropriate components. It manages the SSL certificate and redirect 80 to 443 (switch from http to https)
- the / URLs are routed to http(s)://LEGACY_DNS, while doing so the lua scripts "intercept" the login and maintain a session on the gateway for the user. In other words, the http(s) requests/responses issued during the login phase are interpreted by the lua script to serve as STS (Security Token Service) and thus simulates a SSO configuration.
- the /front URLs are also part of the simulated SSO config: it allow any client browser to download the React app (and then issue the calls to /iapi to access configuration, data,...)
- the /api URLs are dedicated to be called directly from connected apps (mainly for the /api/api_fhir endpoints). They are not protected by the lua scripts and thus don't take part in the fake SSO setup. By default the NEW_AUTH is a Basic Auth.
- the /iapi URLs are dedicated to serve graphql calls from the React app. They are protected by the lua scripts and thus require the user to be authenticated by the "legacy" openIMIS
- the backend is built from openimis-be_py docker and is dedicated to serve the django application for /api calls (mainly the /api/fhir_api), but the /api/graphql is also exposed. It requires the LEGACY_IP - DATABASE_NAME credentials
- the ibackend is also built from openimis-be_py docker and serves the django application for /iapi calls (mainly the /iapi/graphql). It requires the LEGACY_IP - DATABASE_NAME credential.
- the frontend is built from openimis-fe_js docker and is dedicated to serve the React app.
The backend / ibackend setup is not "mandatory": we could have only one "backend".
However it has a tremendous advantage: backend / ibackend can have distinct "lifecycles": they can be switched on/off independently and may even host distinct versions of the various components.
In other words, if a bug is detected by the users (thus in the graphql api), we can patch it without impacting (not even stop/start) the endpoints for the applications connected to the FHIR API
... and the other way round too: we can fix the FHIR API without impacting the users.
One clear limitation though: they are connected to the same database (thus if the patch requires database change, the backward compatibility of the change must be guaranteed).
DEMO Platform (TEMPORARY SOLUTION)
LEGACY_DNS: https://demo.openimis.org/
LEGACY_IP: 132.148.242.96
DATABASE_NAME: ??
LEGACY_SERVER: Windows 2012 R2
NEW_DNS: https://openimis.bluesquare.org/
NEW_IP: 18.197.14.226
NEW_SERVER: Ubuntu 18.04.02 LTS
frontend modules versions:
- openimis/fe-core@0.0.21
- openimis/fe-home@0.0.10
- openimis/fe-location@0.0.8
- openimis/fe-insuree@0.0.15
- openimis/fe-medical@0.0.8
- openimis/fe-medical_pricelist@0.0.2
- openimis/fe-product@0.0.4
- openimis/fe-policy@0.0.11
- openimis/fe-claim@0.0.18
- openimis/fe-claim_batch@0.0.3
- openimis/fe-admin@0.0.14
- openimis/fe-tools@0.0.11
- openimis/fe-profile@0.0.11
ibackend modules versions:
- openimis-be-core==0.0.15
- openimis-be-location==0.0.7
- openimis-be-medical==0.0.7
- openimis-be-medical_pricelist==0.0.2
- openimis-be-product==0.0.3
- openimis-be-insuree==0.0.7
- openimis-be-policy==0.0.8
- openimis-be-contribution==0.0.1
- openimis-be-claim==0.0.16
- openimis-be-claim_batch==0.0.3
NEPALI "TEST" Platform:
LEGACY_DNS: http://imistest.hib.gov.np/
LEGACY_IP: 202.70.87.17
DATABASE_NAME: NP_CENTRAL_V3
LEGACY_SERVER: Windows 2012 R2
NEW_DNS: https://openimis.bluesquare.org/
NEW_IP: 18.197.14.226
NEW_SERVER: Ubuntu 18.04.02 LTS
Legacy openIMIS Version: 1.2 (... connected to NP_CENTRAL_V3 ??)
DATABASE Version: 1.3
frontend modules versions:
- openimis/fe-core@0.0.15
- openimis/fe-home@0.0.7
- openimis/fe-location@0.0.5
- openimis/fe-insuree@0.0.10
- openimis/fe-medical@0.0.5
- openimis/fe-policy@0.0.8
- openimis/fe-claim@0.0.12
- openimis/fe-admin@0.0.11
- openimis/fe-tools@0.0.9
- openimis/fe-profile@0.0.9
ibackend modules versions:
- openimis-be-core==0.0.12
- openimis-be-location==0.0.4
- openimis-be-medical==0.0.5
- openimis-be-product==0.0.1
- openimis-be-insuree==0.0.6
- openimis-be-policy==0.0.7
- openimis-be-contribution==0.0.1
- openimis-be-claim==0.0.10
- openimis-be-api_fhir==0.0.4
backend modules versions:
- openimis-be-core==0.0.11
- openimis-be-location==0.0.3
- openimis-be-medical==0.0.3
- openimis-be-product==0.0.1
- openimis-be-insuree==0.0.4
- openimis-be-policy==0.0.6
- openimis-be-contribution==0.0.1
- openimis-be-claim==0.0.7
- openimis-be-api_fhir==0.0.4
NEPALI QA Platform
LEGACY_DNS: ??
LEGACY_IP: 132.148.151.32
DATABASE_NAME: openIMIS-demo-1.3.0
LEGACY_SERVER: Windows 2012 R2
NEW_DNS: https://openimis.nepalehr.org
NEW_IP: 18.194.86.139
NEW_SERVER: Ubuntu 18.04.02 LTS
frontend modules versions: N/A
ibackend modules versions: N/A
backend modules versions:
- openimis-be-core==0.0.11
- openimis-be-location==0.0.3
- openimis-be-medical==0.0.3
- openimis-be-product==0.0.1
- openimis-be-insuree==0.0.4
- openimis-be-policy==0.0.6
- openimis-be-contribution==0.0.1
- openimis-be-claim==0.0.7
- openimis-be-api_fhir==0.0.4