4 posts tagged with "dhis2"

We are excited about the recent release of Progressive Web App (PWA) features in our App Platform, which you can read about in this blog post introducing them, and we think we have some interesting stories to share about their development. We faced interesting design challenges as we sought to make these features easily generalizable to any app, and the ways we used available technologies to solve those challenges are quite unique. The purpose of this post is to share our novel approach to managing service worker lifecycles and other PWA functionality in a generic way.

The general availability of DHIS-to-RapidPro was announced in the DHIS 2.39 release. Funded by UNICEF, DHIS-to-RapidPro provides connectivity between DHIS2 and an open-source workflow engine geared towards mobile-based services called RapidPro.

DHIS-to-RapidPro is a reliable, extensible, operations-friendly Java solution, powered by Apache Camel, that offers:

• Routine synchronisation of RapidPro contacts with DHIS2 users.
• Aggregate report transfer from RapidPro to DHIS2 via polling or webhook messaging.
• Automated reminders to RapidPro contacts when their aggregate reports are overdue.

Tracker-to-Aggregate, or T2A for short, is a pattern that has been used with great success when improving the performance of program indicators in DHIS2. Program indicators are expressions based on data elements and attributes of tracked entities which can be used to calculate values based on a formula. T2A can solve the problem where it’s computationally expensive to calculate program indicators in real-time. A common symptom to this recurring problem is an endless spinning circle when opening a dashboard that computes a program indicator over millions of tracked entity instances:

DHIS2 is a platform that can receive and host data from different sources, while it can also share data with other systems and reporting mechanisms. Integrating with DHIS2, or building any integration for that matter, requires manual or automated testing of the integration itself. The growth of container technology, and in particular Docker, has reduced the pain of automating the testing of integrations. By automating, I mean self-contained integration test suites that run out-of-the-box and require no manual setup of their external runtime dependencies (Docker Engine is assumed to be installed on the machine running the tests).