Page Comparison

...

...

• The community has developed an OpenLMIS mobile strategy the clearly states the community would like an independent mobile reference application that can be used with OpenLMIS v3.
• There is donor interest to adapt the SIGLUS mobile app to be compatible with OpenLMIS v3. (SIGLUS is a robust Android app that integrates with a custom OpenLMIS v2 server)
• The User Interface for OpenLMIS v3 is built on Angular v1.x. The final release for Angular v1.x will be in July 2018 and it will then begin the final 3 year long term support phase. The entire user interface will need to be upgraded to another version of Angular, or another framework before July 2021. The community has begun discussions on this transition.

Key Risks

• Risk: It might be too hard of a problem or too much work for the current budget to try addressing the "orderables" concept with the OpenLMIS v3 Commodity Model (commodity types, trade items, and lots) while also addressing the "legder" concept (CQRS event model).
  • Ways to mitigate this risk:
    • Slow down and assess this more deeply before we make a choice between tech options.
    • Do more in-person with Josh or other experts on v3 model so deliverabes can understand the "orderables" model and the "ledger" model.
    • Reduce the scope to tackle the "ledger" concept first, and not try to tackle the "orderables" concept. We could break this work up into smaller parts rather than try to achieve the "whole enchilada" at once.
• If we haven't done a big enough risk assessment, then we may not be able to deliver the feature set.
• What is the UI and back-end server doing?
  • What is the difference between stock events and stockcard line items as well as the stockcards?
• Discussion:
  • The OpenSRP system already has a read-only ledger type concept.
    • Conclusion: The ledger aspect is not as big a risk, now that we have talked about it. The risk is really around the "orderables" model.
  • How do we stay "DRY" and build the business rules about conflicts and sync into offline devices.
  • Josh: Our scope could be reduced if we get rid of centralized lot management.
    • Decentralized lot management would make this project easier.
    • Josh: "Move away from synchronization". Separate the data from the business logic. Ensure the business logic is similar/aligned in both systems.
• When offline, we need to be able to follow the same business logic

Decision

With which of the following options should we proceed?

•  OpenSRP Orderables - Android Native: Build out orderables in OpenSRP and integrate with Nifi
•  OpenSRP Stock Management - ReactNative: Convert OpenSRP's stock control module to ReactNative and build out orderables
•  Embed SIGLUS Stock Management in OpenSRP: Extract the SIGLUS Stock Management and Inventory features and make them available as a component within OpenSRP. OpenSRP would 
•  SIGLUS Stock Management to OpenLMIS v3: Adapt SIGLUS Stock Management and Inventory features to be compatible with OpenLMIS v3 and integrate it with OpenSRP
  If we adopt SIGLUS, we have two approaches:
  •  Native v3 support in Android Client: Develop native support for OpenLMIS v3 in the Android Client so that it directly interacts with the OpenLMIS v3 server
  •  v3 Support through middle layer or microservice: Do not change the Android Client. Instead, develop a middle layer or microservice that handles the transactions between the OpenLMIS v3 architecture and the SIGLUS Android Client.

Detailed Options

OpenSRP Orderables - Android Native

...

• This approach does not conform to the OpenLMIS v3 strategy of building an independent application
  • This functionality would only exist inside the OpenSRP app, and running it depends on having an OpenSRP server running.
• This approach would not result in a product that is as mature as adapting SIGLUS
• Components are not able to be reused outside of Android

...

• If used as a reference application for OpenLMIS, implementers would have a dependency on OpenSRP server and OpenMRS.
• This approach only partially conforms to the OpenLMIS v3 strategy of building an independent application
  • There is still a dependency for the data to all flow through OpenSRP server (the product list, all metadata, the stock events, etc).
• OpenLMIS will have to maintain both a web (JavaScript) and mobile (Android Native) codebase

...

• Schedule Risk: This option hasn't been scoped and presents a greater schedule risk than the other sub-strategy

v3 Support through API Gateway (middle layer

...

)

This strategy focuses on keeping the SIGLUS Android client as it is and building a middle layer between the SIGLUS Android client and the OpenLMIS v3 microservice APIs. In this case, we would only minimally develop SIGLUS to integrate it with OpenSRP. The middle layer would handle all transactions from the SIGLUS Android client and perform business logic to translate the mobile requests to the appropriate API calls for the OpenLMIS v3 architecture.

...

• This approach requires a long-term dependency on the OpenLMIS v2 data model in the Android client unless there is additional funding and benefit to convert the SIGLUS Android Client to be compatible with OpenLMIS v3.
• Higher maintenance cost long-term.

Risks:

• Schedule Risk:
  • The team assumes a tool like Nifi can be used to perform this interaction, which requires much less programming than doing this in Java. Nifi is already a dependency of the OpenLMIS v3 reporting architecture so we would not be adding an architectural component.

Comparison of Upgrading SIGLUS v. Developing Orderables in OpenSRP

This section focuses on a point-by-point comparison of the requirements for delivering the integration of stock management and inventory. Both options require a lot of work. The orderables data model shift from OpenLMIS v2 to v3 effectively requires that the data model of products be rewritten which impacts all business logic (presenters) and the majority of views on the Android client.

Note on OpenSRP core strategy: We will use the same interface, but make the card view dynamic to allow for a server side configuration of the orderable (commodityType and tradeItem) list. All metadata will be synced from OpenLMIS to the OpenSRP server using Nifi. We will also need to introduce a new bulk inventory process that will need to be designed.

Major areas of risk for the Upgrade SIGLUS:

• Generally, there's a schedule and cost risk of having to develop OpenLMIS microservices for this project:
  • Authentication upgrade to work with OpenLMIS v3 may require Auth microservice development
  • We will need to create a microservice from scratch to manage the mobile deployment syncing, which is a huge undertaking
• Schedule Risks:
  • Ramping up on SIGLUS to be proficient in development will take 2-3 weeks for the full time Android developers who are already proficient with OpenSRP, Nifi and the OpenLMIS APIs