Hi Mhawila,
Re: your use case, let's set up a quick call (
https://calendly.com/taylor-downs) to make sure we're understanding everything correctly. If those instances are not available from the internet (no public IPs?) you might be looking at a local deployment or connecting OpenFn-cloud through sort of VPN. That's no problem, but will require a bit more setup and maintenance work on your end. Either way, moving from a custom module to an integration platform like OpenFn will give you
much more visibility, error-handling capabilities, and administrative controls over how these systems talk to one another.
Your question about accessing the returned patient is a great one! It gets to the core of how jobs work in OpenFn. Each "operation" is a function that returns a promise and is actually passed"state" alongside its arguments. State is a json object which consists—at least—of a configuration key (containing some sort of login/authentication information) and a data key (containing the body of the message/event/received request that triggered the execution of a particular job. (If it's a real-time, event-based job. Jobs can also run periodically with a cron schedule, or based on the success or failure of another job.)
In Aleksa's job, she's passed the exactlyOne option to get patients, so she wants the run to fail if we find 0 or >1 matching patient, based on that emrID field (see how it comes from state.data! She knows that next operation (createEncounter) will only be executed if the first operation succeeds. Think of a job expression as a whole bunch of promise.then calls which take state and return state. That same pattern is extended over cronjobs (so that the second run of a cronjob inherits the final state of the first run—which is very useful for keeping a "cursor" while polling an external API for new data) and flow jobs (so that when job A succeeds, job B has access to its final state).
I have two thoughts here:
(1) If you want a low/no-code solution, let's define the business requirements that your team has for the various integrations and then write one or two "helper functions" so that all your users need to see on OpenFn is something like this:
identifyAndUpdate(
dataValue('uuid'),
dataValue('patient')
);
(2) If you're keen to dig into the mechanics of OpenFn/core (which is
great!) then I'd check out
https://github.com/OpenFn/openfn-devtools and play around with the
alterState operation, either on the hosted iPaaS (see
https://docs.openfn.org) or locally, using our open-source stuff. To follow Aleksa's pattern but really crack open the hood, you could write something like this:
getPatients({ something with the initial state });
alterState(state => {
console.log('Do what you'd like in here...');
console.log(state);
console.log('But always return state!');
return state;
});
createEncounter({ something with the updated state });
Hope this helps! Excited that you're digging in, and looking forward to speaking with you about the OpenMRS project.
Taylor