OMS Standalone Central Server MVP

[Chris-Petty]

OMS Standalone Central Server MVP

In order to transition away from 4D mSupply Central Server we should scope out the minimum level of central data UI required to allow new deployments to consider using only OMS, with no mSupply Mobile or mSupply Desktop.

For purposes of this we can call:

• the new version of OMS that supports this: v3.0.0
• Legacy Central Server: LCS
• Open mSupply Central Server: OMCS

Additional Context

#3674: Assets have central editing for all stores, but not all store data syncs to central OMS server. I.e. a remote store’s assets sync but not the locations of the remote store, so location cannot be shown. Current thinking is only solution is for central to have all store data (as it is destined to do)

Scope MVP

The minimum required functionality to allow managing an OMS deployment

UI: New “Central Configuration” section in nav bar only available on central server. Sub section/page for all of the following:

Items
Names
Stores
Sites
Master Lists
Users
User permissions
Reports
Currencies
Abbreviations?
Categories?

• We’d need some way to configure OMS as a Central Server without OG setting it.

API challenge

Remote OMS sites would need to differentiate between a system that still has both legacy and OMS central servers or only central:

• Both: Still need to central and queue push/pull to Legacy/syncv5 api
• OMS only: only sync with v6

[Chris-Petty]

Full Sync OMS

For the API challenges a solution is basically move v3.0.0 to only sync with OMCS, and configure OMCS and LCS central servers to communicate with older versions of all our apps:

1. Legacy Central Server (LCS) sends all data to OMS Central Server (OMCS)
2. OMCS Sends all received data from remote sites to LCS
3. Legacy Desktop, Mobile and OMS < v3.0.0 continue to sync with LCS (v1, v2/3 and v5) respectively.
4. OMS < v3.0.0 sync with OMCS on v6 (to get OMS central features such as assets, pack variants)
5. OMS ≥ v3.0.0 and syncs with OMCS only

i.e.

Sync Client	LCS	OMCS
Legacy Desktop	✅
Mobile	✅
OMS < v3.0.0	✅	✅
OMS ≥ v3.0.0		✅

Note this is a bit of an extension to the original discussion topic. Strictly speaking, this idea is over kill for the goal of being able to do new deployments only with OMS. The key benefits are for transitioning existing clients off of all the legacy apps.

For a transfer from Legacy Desktop → OMSv3

1. Legacy desktop → LCS. LCS check sync version of other party, don’t generate transfer as ≥ sync v5
2. LCS sends all data from Legacy Desktop store to OMCS
3. When OMSv3 site requests data from sync v6, change_log provides all records where OMSv3 site’s stores are the “other party”
4. OMSv3 generates it’s own transfer

PROS:

• OMSC now has all data of all stores. Things like locations for assets work properly
• LCS no longer has burden of syncing all the remote sites that use >=v3.0.0
• Can start transitioning dashboards and integrations to OMSC
• Can gradually implement central config functionality and deploy into production
• Once MVP config is supported we can transition more sites smoothly to OMS, rather than having to move all of a country off old versions of apps in one go.

CONS:

• Complexity in system architecture. Which one should push and pull? Probably OMS (up until configuring sites perhaps)
• Harder traceability if something goes wrong (transfer not made, lines missing... where and how?)
• 2 Central Servers potentially sending a lot of updates to each other (we can probably optimise this specific case if this transition model is worthwhile)