Openmrs adapter 5.0.2 not updating resources

Adaptors & Templates
1

Dear Altruist,
We were trying to write an OpenFN job to upsert an encounter in OpenMRS. However, it seems that it is always creating new resources (encounters) instead of updating existing ones. Though the console log shows it has indeed found the resources and successfully updated them,

ADA Preparing composed upsert on encounter
ADA GET /ws/rest/v1/encounter?patient=f1add10d-6851-43b1-b7d9-7236a06b478f&encounterType=7e10b3cb-e42f-11e5-8c3e-08002715d519&fromdate=2025-06-12T11%3A06%3A28.234&todate=2025-06-12T11%3A11%3A13.962&limit=1 - 200 in 198ms
ADA encounter found: updating existing resource
ADA Preparing to update encounter
ADA POST /ws/rest/v1/encounter - 201 in 146ms
ADA Successfully updated encounter

Have you encountered a similar issue before? Would you please suggest what we might be missing? The following are our environment and version details.
We are using the openFN lightning v2,
VER Versions:
▸ node.js 22.16.0
▸ worker 1.13.6
▸ @openfn/language-common 2.4.0
▸ @openfn/language-openmrs 5.0.2

Thanks,
Sohel

1 Like
2

Hi @sohel, thanks for writing in.

At first glance this looks like a bug in the adaptor code. It looks like the adaptor function is posting to the wrong URL.

We’ll take a look and get back to you as soon as we can.

1 Like
3

Thank you @joe for your quick checking, there is also another kind of problem with this version that may be relevant, this case’s upsert did not find the encounter and wanted to create a new encounter URL for the POST, but that also seems generate incorrect POST URL.
It seems it drops the resource name at the end of POST URL,
e.g. POST to https://:our-host:/openmrs/ws/rest/v1

Preparing composed upsert on encounter
ADA GET /ws/rest/v1/encounter?patient=6074816c-ade7-41bd-abf9-17205e9c2fff&encounterType=7e10b3cb-e42f-11e5-8c3e-08002715d519&fromdate=2025-06-12T11%3A06%3A28.234&todate=2025-06-12T11%3A11%3A13.962&limit=1 - 200 in 709ms
ADA encounter not found: creating new resource
ADA Preparing to create 
R/T 3-createOpenMRSEncounter aborted with error (3.514s)
R/T Error reported by "each()" operation line 2:
R/T Error: POST to https://<our-host>/openmrs/ws/rest/v1 returned 405: Method Not Allowed
    @openfn/language-common/dist/util.cjs:149:19)
    @openfn/language-common/dist/util.cjs:235:3)
    @openfn/language-openmrs_5.0.2/dist/index.cjs:90:22)
    @openfn/language-openmrs_5.0.2/dist/index.cjs:290:22
R/T Additional error details:
R/T {
  "body": {
    "error": {
      "code": "org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter$ServletHandlerMethodResolver:677",
      "message": "[Request method 'POST' not supported]"
    }
  },

Hope this might also be helpful for you while checking.

4

Hello @sohel,

Can you share your code snippet as well?, I am curios on how your using upsert() with each()

5

Hello @mtuchi , Thank you for checking here is my code snippet,

  // Creating encounters in openMRS
  each(
    $.encounters,
    upsert(
      'encounter',
      state => {
        const { trackedEntity,eventId, ...encounter } = state.data;
        console.log(
          'Upserting encounter record...',
          JSON.stringify(encounter, null, 2)
        );
        return encounter;
      },
      {  
         patient: $.data.patient,
         encounterType: $.data.encounterType,
         fromdate: $.data.encounterDatetime,
         todate: $.data.visit.stopDatetime,
         limit:1
      }
    ).then(state => {
            state.newEncounterUuid ??= [];
            console.log('state.references ::', state.references)
            state.newEncounterUuid.push({
              eventId: state.references.at(-1)?.eventId,
              trackedEntity:state.references.at(-1)?.trackedEntity,
              patient_uuid: state.references.at(-1)?.patient,
              enounter_uuid: state.data.uuid,
            });
            return state;
      })
  );
6

@sohel I think I have a fix to your first issue. Are you comfortable using the openfn CLI? Are you able to run some local testing on the unreleased adaptor? I can help you but don’t worry if this sounds too difficult :slight_smile: We can just release the adaptor to the app and see if it works

Regarding your second issue I can see the problem. That also looks like a adaptor bug. It might be a little harder, I’m going to give it some thought.

1 Like
7

Sure @joe, Thank you very much that pretty fast with fixation, I am not super used to with CLI yet :-), but let me know how I may help with local testing ?

8

@sohel hmm, Ok, maybe just leave this with us. I think I can get you two fixes by Monday? Does that sound alright?

Are you using our sas/coud app? On app.openfn.org?

We’ll release straight to the app - so I’ll need to work out some test cases locally (that’s the bit that will take time)

For the record, to test locally, you’d need to:

  • clone the adaptors repo locally
  • check out the correct branch
  • build the repo
  • create a local copy of your workflow (there are a few ways to do this)
  • Point your CLI at the adaptors repo
  • Run your workflow through the CLI

None of that stuff is very difficult - but I think it’s easier if we put a patch release straight out :slight_smile:

1 Like
9

Thank you @joe for the quick help, yes, we are waiting for the patch release.
Sorry, we are not using SAS; we are checking with the local instance.
Yes, it seems local testing involves a handful number of steps :slight_smile:, better for us to skip for now as you are doing this already.

10

@sohel no problem - leave it with us and we’ll have this sorted soon

11

Hi @sohel - openmrs @5.0.3 is now out.

This should fix both the problems with upsert :crossed_fingers:

I’ve tested as best I can but please have a look against your own code and let me know if it’s working.

12

Thank you, @joe, for your quick fix. The new version we tested from the CLI is spotless and working as expected.
New Resource:

Preparing composed upsert on encounter
GET /ws/rest/v1/encounter?patient=f1add10d-6851-43b1-b7d9-7236a06b478f&encounterType=7e10b3cb-e42f-11e5-8c3e-08002715d519&fromdate=2025-06-08T11%3A06%3A28.234&todate=2025-06-08T11%3A11%3A13.962&limit=1 - 200 in 279ms
encounter not found: creating new resource
Preparing to create encounter
POST /ws/rest/v1/encounter - 201 in 286ms
Successfully created encounter

Update Resource:

Preparing composed upsert on encounter
GET /ws/rest/v1/encounter?patient=f1add10d-6851-43b1-b7d9-7236a06b478f&encounterType=7e10b3cb-e42f-11e5-8c3e-08002715d519&fromdate=2025-06-12T11%3A06%3A28.234&todate=2025-06-12T11%3A11%3A13.962&limit=1 - 200 in 233ms
encounter/4ff392d6-cd50-4841-8cb2-86396c90f1c7 found: updating existing resource
Preparing to update encounter/4ff392d6-cd50-4841-8cb2-86396c90f1c7
POST /ws/rest/v1/encounter/4ff392d6-cd50-4841-8cb2-86396c90f1c7 - 200 in 238ms
Successfully updated encounter/4ff392d6-cd50-4841-8cb2-86396c90f1c7

To get this new adapter version available in our local instance, do we need to reinstall the whole setup, or will any configuration update work?

Thank you again for your quick help :clap: :clap:

13

Hey @sohel , so glad it worked for you!

Re: getting them to appear in OpenFn/lightning, how are you running your local instance?

14

Thank you @taylordowns2000 !!
we are running our local instance using docker. The images we build locally from latest source.

15

Hello Team & @joe ,

Thank you all for fixing the resource URL in openmrs@5.0.3. We are now using that version and it seems now updating the correct resources as it finds during the time of upsert. But still another issue, we noticed that inside the encounter it is creating the new observations instead of updating the existing observations. Though it is showing updating the existing resources in log,

Preparing composed upsert on encounter
ADA GET /ws/rest/v1/encounter?patient=f1add10d-6851-43b1-b7d9-7236a06b478f&encounterType=7e10b3cb-e42f-11e5-8c3e-08002715d519&fromdate=2025-06-12T11%3A06%3A28.234&todate=2025-06-12T11%3A11%3A13.962&limit=1 - 200 in 99ms
ADA encounter/b52cf352-9540-43be-9340-0da05f22709a found: updating existing resource
ADA Preparing to update encounter/b52cf352-9540-43be-9340-0da05f22709a
ADA POST /ws/rest/v1/encounter/b52cf352-9540-43be-9340-0da05f22709a - 200 in 233ms
ADA Successfully updated encounter/b52cf352-9540-43be-9340-0da05f22709a

Do you have the similar issue or suggestions why this might be?

Thanks,
Sohel

16

We believe that if you repost the existing payload, it will add these as a new observation within the existing encounter in OpenMRS. May be to update observations in an existing encounter, need to update the encounter payload with the observation’s existing UUID and with its new value before repost.

17

Hi @sohel - yes I believe that’s how the OpenMRS REST API behaves as observations are considered a top-level resource (and not a subresource of encounters).

  • When you create or update an encounter, per the api docs it looks like you can include an obs array of new observations in the same payload
  • To update existing observations, you’ll need the observation records’ uuid to do so, and there even looks like there is a dedicated api endpoint (see api docs) for updating these resources
//example openfn job code to update an existing observation
update('obs/727124cd-191e-4073-a619-d3169c228374', {
  'value': 71
})

see related api docs: OpenMRS Docs