Best Practice for an "alive" REST endpoint?

Development
,
1

We are building a PWA that connects to OpenMRS RESTfully. We’d like to display an alert if for some reason the server is down (or the network is down) and the client cannot contact OpenMRS.

We were thinking of having a simple REST endpoint that the client would poll at regular intervals (every 30 seconds?) and check if the server is alive.

Any thoughts on best practices on what that endpoint should be called? Any existing REST endpoints we might want to use? Issues if we added a simple endpoint to the REST module to accomplish this?

One thought we had was for the endpoint to return the current datetime and timezone so we also could accomplish this test with a single call:

Thanks! Mark

2

Hi @mogoodrich, is this to assess whether the OpenMRS instance is up & running?

3

@mksd that or any kind of network issue.

Our particular use case is that we were testing a new PWA we wrote in a rural clinic where we had tablets connecting to an OpenMRS instance running on laptop via an inexpensive portable router. It appeared that the laptop was frequently dropping from the network thought this wasn’t entirely apparent from looking at the laptop status.

We want to render a message similar to what Google Docs would display (if I remember correctly) if you are editing a document and for some reason drop off the Internet.

Thanks! Mark

4

I guess that the PWA should assume that it is offline when it cannot transact with its REST endpoints.

I’m assuming here that this PWA works with REST WS as its sole source of REST endpoints. So what we you’d want to know is that the REST WS module is started. That would be the most restrictive condition, as soon as this can’t be verified you have to assume that the PWA is offline. You can achieve this through the module resource. That would be the cURL (on localhost:8080) to start with:

curl -u user:pass --location
  "http://localhost:8080/openmrs/ws/rest/v1/module?limit=100&v=custom:(packageName,started,version)"

That is how we monitor that an OpenMRS instance is up & running as it should: we query the module resource and check that all modules that should be started are started.

5

Cool, thanks @mksd!

6

Actually, @mseaton just mentioned this one to me, which I think is what we want:

{code} mirebalais/ws/rest/v1/systeminformation {code}

… because it also gives us the system time, which is something else we are looking for…

1 Like
7

That’s an interesting one, thanks for the pointers @mseaton!

However one question: are the modules listed in "SystemInfo.title.moduleInformation" installed or started? I haven’t checked yet, but in any case this would be nice to know.

P.S. I couldn’t try on the OpenMRS demo just right now because for some reason it returns an invalid resource error.

8

@mksd i have reset the demo server. Can you try again?

1 Like
9

Yes, it’s working now @dkayiwa! Thank you.

10

Assuming it’s showing started modules, then this is a great resource!

But I can’t say I like the output format of the section "SystemInfo.title.moduleInformation". I would rather rely on artifact IDs than module names. I also see that for some reason a trailing space was left in the version, eg:

"Rest Web Services OMOD": "2.22.0.ba95a3 "
11

Just quickly looking at the implementation, this simply returns what is already returned by the AdministrationService.getSystemInformation() service method.

There are likely some improvements we can make to this - feel free to ticket if this is important to you. For the modules specifically, both of the issues you highlight above can be seen here:

It will return all loaded module ids, followed by a space, followed by text indicating it is not started if it is not started. This should likely be cleaned up a bit.

12

Thanks @mseaton.

I’ve been contemplating for a while the development of a monitoring tool for OpenMRS/Bahmni instances. When I’ll finally get down to it I will certainly want to revisit that resource.