Do you think twice when you get an automatic SMS notification because your
prescription is ready? (Neither do I.) This seamless experience is driven by
“workflow automation”, a key feature that OpenFn provides. The OpenFn
Integration Toolkit is a Digital Public Good (DPG) used by governments and NGOs
to boost efficiency through workflow automation. The automation that OpenFn
provides includes automatically sending SMSs, automating stock updates across
supply chain systems, tracking clinical visits, and helping plan vaccine
rollouts. We support our partners’ work by lifting the burden of manual data
transfers between platforms.
OpenFn automation happens via jobs which define
specific steps ("operations") that OpenFn should perform. They're written in a
scripting language that runs on top of (and has
full access to) Javascript. A basic understanding of Javascript will take
your job writing on OpenFn to the next level. To improve my limited knowledge of
JavaScript, I have been taking Codecademy's
Introduction to JavaScript Course.
Have you ever struggled to layout the strategy for testing your React App? Well,
you are not alone! Here a few hints from the lessons I learned during my
experience testing a
React/Redux app with a
Phoenix/Elixir
backend.
We're very happy users of Elixir and Phoenix at OpenFn, given that we've been
using it continuously for about 6 years - upgrades and all. Our front-end
toolchain, albeit far from out of date (Webpack 5.52.1
today) has left some
room for improvement.
So you're using docker's multi-stage builds and noticed that your build times
aren't nearly as quick as you expected?
Jobs are business processes turned into functional-style scripts. What does that
mean, how should you approach writing jobs?
This is a quick one, but I just got off an exciting call with an organization
that's going to set up some jobs to move data into Salesforce from CommCare and
realized that despite this being one of our more common integration
requirements, we haven't done a 'tips' article for this type of project. Until
now.
“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:
- Real-time, or event-based, syncs
- Scheduled syncs
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.
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 👍 ✅.