Skip to main content

Sync Like You Mean It: Thinking Through System “Syncing” Protocols

“Syncing” is getting two systems to a state of harmony. This might mean keeping a list of patients up to date, though modifications can be made in either system. It might mean copying transactions from one system to another on a nightly basis. It might mean a lot of things, but the key concept is that when you sync systems, you’re asking them to work together while simultaneously respecting both software systems’ independence.

In this post we’ll discuss two different syncing protocols to consider when designing your data integration. These include:

  1. Real-time, or event-based, syncs
  2. Scheduled syncs

Our Servers or Yours: Thinking through deployment options

Zandile is a program manager at an iNGO and she needs to use CommCare, DHIS2, and OpenFn for an upcoming public health project. She understands that all three pieces of software can be deployed locally, or accessed as SaaS (Software as a Service).

Essentially, Zandile needs to decide if she would like to run the software on someone else’s servers (SaaS), or on her organization’s own servers (deployed locally). Before making a decision she outlines the basic, non-technical considerations for both options.

Tracked entity instances in DHIS2

tl;dr: Lots of our users want to upsert tracked entity instances in dhis2, but upserts aren’t supported by a standard DHIS2 API endpoint. We built one in our dhis2 adaptor: it’s composed of existing APIs and a bit of logic 🤔. Now you can upsert tracked entity instances to DHIS2 👍 ✅.

Allow Yourself to Fail

Hi all, this is a very short post with a simple message: design for failure. Even if you've never heard of MSSQL (or Azure, or Microsoft?), I want to talk for one moment about the importance of upserts and a funny developer term called "idempotence."