View Source

Date

10 Dec 2016

Attendees

Goals

Understand ODK 2.0 Architecture and how OpenLMIS would use it

Action items

Nick Reid (Deactivated) Understand ODK App Designer output, and how it might work within OpenLMIS
Josh Zamor to send documents about OpenLMIS RBAC to ODK team

ODK 2.0 Description and Changes

Original ODK Update is a huge clump of code, that is being refactored into a dockerized service that doesn't use big table, but uses a structured database (mysql/postgres). Changes are coming to the Agrogate service API as the current API doesn't match the underlying structure — but a majority of the API should stay the same , and is keep the existing unit tests to honor the service API contracts.

Docker containers are stripped down aggrogate (built on linux and windows images). Trying to do two paraell paths — windows cloud or linux cloud

ODK is part of a larger university project in collaboration with UC Berkeley (Go Bears) called Mezuri (Esperanto for "measure") — its a ‘Jupiter workflow’ (which is something developers understand (I don't)

The general structure of ODK is a file structure based on 'projects' — which are the primary definition of an endpoint that is used by an ODK application to read and write data about tables to. A project is defined by a form-def.js file, which can be generated from an XLSX Form. These projects are rendered into an Android environment. In ODK each project/endpoint is a separate database.

There is also an AppName, which allows the ODK application to group projects together. This allows ODK to store forms of very different types on the same device.

Apps use the follow file structure, which allows the HTML/JS/Assets that make up the ODK android app to be switched around. Mobile branding just replace html elements

ODK file system

-- system

-- config overrides system

-- data which holds the database

-- output hold logs

-- permanent can put any large items here

The full SQL Lite database is stored on an SD card in the phone. Each row has an owner (which is used with groups) — rows can be set as ‘read-only’

Currently there are no webhooks implemented in the ODK Service that OpenLMIS might use. They have said they would make the webhooks work for us.

ODK 2 Questions

Users and permissions (groups)

Azure cloud
MSQL has structures we don’t want to rebuild (supporting 3rd party logins)
Currently aggregate permissions work as they did

How ODK and OpenLMIS might be integrated

Requisitions has data that needs to be configured — it is a mix of complex and simple data — so of it is programatic that would change in many different ways

How to integrate ODK-compliant forms for openlmis

Requisition page sends form def to ODK and gets data from form server as users enter it into a handset
Converts Xlsx converter — takes xform — no one writes form-def
ODK Survey is just web pages and a form def
ODK spins up an endpoint
Sync protocol with phone and form server
Phone pulls down the forms

Josh’s MPH scenario:

If the form schema changes
ODK won’t munge data
There is new data/forms which workers now need to move to somewhere else
Can define a munging service to move old data into a new database
Workers will need to update their old forms and URL

Facility visibility — implemented in groups, groups enforce permissions in visibility

Time locking data — role permissions (called data filtering)

Can I take data out and lock it

Adapt-R (UCSF Study) deletes rows out of ODK once safely stored else where (but causes problem with error correction)

OpenLMIS would create a form manager to allow services to expose form-defs to ODK which could then be downloaded and used by people using ODK on android devices. The OpenLMIS RBAC Permissions and users would need to be loaded into ODK and updated. Support data (programs and facilities) would have to be loaded into ODK tables so that it can be synchronized.

Overall we would never touch ODK's database structure directly, and simply read data out of ODK as needed and let services use as they need.

UI and ODK App

Tables and survey use the same interfaces, they are passed a DB javascript object and render code according to implemented javascript. This is the Android common interface that is underneath it.