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

Logical Deployment Diagram:

Open

• gateway: hit point of all incoming traffic: users as well as applications, mobile device flows,...

• backend & ibackend: python modules implementing business logic

• frontend: browser (react) application (i.e. static content downloaded by browsers)

• legacy app: .NET code (*.aspx) serving the legacy pages

• rabbitmq: queueing server (when async calls are served distributed)

• worker: python modules (same as backend), but connected to rabbit mq

• database: mssql database, holding legacy business logic as stored procs

Reference Deployment Diagram:

Open

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).

RELEASE (TEMPORARY SOLUTION)

The release.openimis.org installation is NOT a standard openIMIS installation in several major aspects:

• because of Windows 2012 compatibility issues, it is not running within dockers

  • React app is served from IIS

  • Django app is deployed as a separate Windows service

  • openResty gateway is deployed as a separate Windows service, with a corresponding 'fake' app on IIS (to establish reverse proxy rules)

• the application is deployed from the source code, from the release github branch (i.e. not from published components versions from npm or pypi)

The only objective of this setup is to enable acceptance testing for the release but should not be reproduced for production usage.

Some highlights:

• the C:\Windows\System32\drivers\etc\hosts file has an entry for release.legacy.openimis (bound to 127.0.0.1) in order to make release.legacy.openimis IIS app routable from the OpenResty gateway

• the (react) front is built (yarn build) from C:\new_OpenIMIS_TEST\frontend\openimis-fe-* modules, linked (yarn link) into C:\new_OpenIMIS_TEST\frontend\openimis-fe_js

• the (django) backend is served from C:\new_OpenIMIS_TEST\backend\openimis-be_py\launch.bat, which uses the C:\new_OpenIMIS_TEST\backend\openimis-be_py\venv virtual env in which all C:\new_OpenIMIS_TEST\backend\openimis-be-*  modules are linked (pip install -e ...)

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