RESTWS-466 - Custom representation issue

Development
1

Hey,

I am currently facing RESTWS-466 ticket, which is about exception thrown by webservices.rest when asking for encounter’s provider’s prefferedName when prefferedName is not defined.

Firstly, I was trying to reproduce this bug. I’ve just picked some random encounter’s UUID on my local 2.6-SNAPSHOT Reference Application distro and sent this URL to server: rest/v1/encounter?patient=92e8860b-5669-459e-96c0-f7913a64e913&v=custom:(uuid,location:(uuid,name),encounterDatetime,encounterType:(uuid,name),provider:(uuid,preferredName))

It should return Encounter represented as in diagram below:

Untitled Diagram.png743×204 5.97 KB

Exception is thrown as expected. I’ve looked into Encounter model and noticed, that Provider object is not in Encounter directly, but it is contained in EncounterProviders array.

I’ve tweaked URL so it looked like that: rest/v1/encounter?patient=92e8860b-5669-459e-96c0-f7913a64e913&v=custom:(uuid,location:(uuid,name),encounterDatetime,encounterType:(uuid,name),encounterProviders:(provider))

Untitled Diagram2.png693×204 5.63 KB

That request’s response is returns correct custom Encounter, as defined in URL.

Next move, lets add custom representation of Provider to URL by changing provider to provider:(uuid)

Untitled Diagram3.png693×259 6.06 KB

Boom, Exception :frowning:

I’ve debugged some webservices.rest code and I spotted something weird in BaseDelegatingResource’s method getCustomRepresentationDescription(). This method parses custom representation properties from request URL String. Works nice, until there is no more than “2 levels of custom representation complexity” (IDK how to call that). For example:

custom:(patient:(gender)) - OK getCustomRepresentationDescription() is called twice.

  • adds patient property to encounter’s description
  • adds gender property to patient’s description

custom:(patient:(person:(gender))) - Exception getCustomRepresentationDescription() should be called 3 times.

  • adds patient property to description
  • adds perso (Yes, no ‘n’ letter) property to description
  • exception before it could be called 3rd time.

My question is: Is custom representation limited to “2 levels of complexity” or is it a bug?

Anyway, its weird that Provider object couldn’t be accessed directly from ‘Encounter’ (just as patient → gender). Any ideas why is it happening?

1 Like
2

No, custom representation is not limited to 2 levels of depth so it is a bug.

Also there’s a difference in an Encounter representation between OpenMRS platform versions.

For versions below 1.9, the following should work: rest/v1/encounter?patient=92e8860b-5669-459e-96c0-f7913a64e913&v=custom:(uuid,location:(uuid,name),encounterDatetime,encounterType:(uuid,name),provider:(uuid,preferredName))

For versions 1.9 and above, you need to use: rest/v1/encounter?patient=92e8860b-5669-459e-96c0-f7913a64e913&v=custom:(uuid,location:(uuid,name),encounterDatetime,encounterType:(uuid,name),encounterProviders:(provider:(uuid,preferredName)))

Basically in Platform 1.9 and above we added support for multiple providers.

Hope it helps!

1 Like
3

Thanks @raff for Your response, it was very helpful :slight_smile:

I’ve managed to fix depth of custom representation bug: URL: localhost:8080/openmrs/ws/rest/v1/encounter?patient=751c107c-adb5-44c0-88d9-6c38c2f24956&v=custom:(encounterProviders:(provider:(person:(uuid,preferredName:(display,uuid)))))

Screenshot from 2016-12-05 15-43-33.png1527×376 31.5 KB

:sunglasses:
Note that its not possible to get `prefferedName` directly from `provider`.

Now I’m trying to reproduce bug by making prefferedName of provider person to null, but its not so easy (REST gets angry about changing preferredName to null). Any tips on how to break preferredName?

4

Person must have at least one non-voided name so it is not possible for preferredName to be null…

It was possible to get prefferedName directly from provider in versions of OpenMRS below 1.9 as the field simply contained a person. Provider can’t be null either.

In other words if you fixed the depth issue then you can consider the issue to be fixed as it was most likely the case…

5

I’ve created pull request :slight_smile: -> HERE <- Thanks for help @raff :slight_smile: