We’ve hit some issues in terms of testing the save clinical data workflow, and would like to discuss it.
Basically, we found that,
(a) an XDS.b Message with no content is enriched, sent to the SHR from the mediator, and parsed.
(b) an XDS.b Message with content is validated via each registry, and the mediator log says that the enriched message is send to the SHR, but its not.
We listened using tcpdump on the mediator, and can confirm that the XDS.b message is not actually being sent from the mediator to the SHR.
Apparently the mediator fails to fire any of the requests to any of the registries when we send it the XDS.b message with content. This is despite it saying that it does in the logs. We determined that it is not by capturing outbound traffic on the registries from the IOL box which hosted the mediator. When we tried with the empty message it showed traffic to the registries, as expected.
I’m currently using an XDS.b message that Justin generated and shared with me. This message seems to be fine in every way… (http://pastebin.com/ekw6z4LF).
···
On Wed, May 6, 2015 at 2:43 PM, Suranga Kasthurirathne surangak@openmrs.org wrote:
Hi everyone,
We’ve hit some issues in terms of testing the save clinical data workflow, and would like to discuss it.
Basically, we found that,
(a) an XDS.b Message with no content is enriched, sent to the SHR from the mediator, and parsed.
(b) an XDS.b Message with content is validated via each registry, and the mediator log says that the enriched message is send to the SHR, but its not.
We listened using tcpdump on the mediator, and can confirm that the XDS.b message is not actually being sent from the mediator to the SHR.
Hannes and I have left you guys some comment on the Skype chat that we have been using, however, in summary this is what we have said and some additional comments:
It seems there are some duplicate document errors in the SHR logs, remember that each time you send a message you MUST change BOTH the XDSDocumentEntry.uniqueId AND the XDSSubmissionSet.uniqueId
I also see in the SHR logs a NullPointerException where it seems like a document was sent where the ExtrinsicObject element’s id attribute doesn’t match the Document element’s id attribute. That’s something to watch for.
The reason you are not seeing orchestrations in the console is that the mediator reports these back to the OpenHIM-core. So if the SHR send a bad response back to the mediator or the mediator itself fails then its possible for these to be lost (even if they do actually occur).
To us it seems unlikely that the mediator isn’t sending out request when it logs that it does so, although it may be possible. We think that the problem probably lies in the SHR so it would be useful to watch those logs closely when sending requests.
We also note that the mediator is using 99.9% cpu, this is unusual and we haven’t seen this happen in our environments, perhaps a restart would get the CPU usage under control?
I think at this stage it would be good for Hannes and I to have direct access to the servers so we can tail the logs when you run messages this afternoon. I have dug up my details. But perhaps you could add Hannes’ public key to. @Hannes, could you send Ryan Yates your public key?
Hope we can figure out more this afternoon.
Cheers,
Ryan
···
On Wed, May 6, 2015 at 9:04 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:
Hi all,
An update,
Apparently the mediator fails to fire any of the requests to any of the registries when we send it the XDS.b message with content. This is despite it saying that it does in the logs. We determined that it is not by capturing outbound traffic on the registries from the IOL box which hosted the mediator. When we tried with the empty message it showed traffic to the registries, as expected.
I’m currently using an XDS.b message that Justin generated and shared with me. This message seems to be fine in every way… (http://pastebin.com/ekw6z4LF).
–
You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.
On Wed, May 6, 2015 at 2:43 PM, Suranga Kasthurirathne surangak@openmrs.org wrote:
Hi everyone,
We’ve hit some issues in terms of testing the save clinical data workflow, and would like to discuss it.
Basically, we found that,
(a) an XDS.b Message with no content is enriched, sent to the SHR from the mediator, and parsed.
(b) an XDS.b Message with content is validated via each registry, and the mediator log says that the enriched message is send to the SHR, but its not.
We listened using tcpdump on the mediator, and can confirm that the XDS.b message is not actually being sent from the mediator to the SHR.
Thanks for this analysis Ryan – very much appreciated.
Ryan Y – can we grant Ryan/Hannes access to the machines?
···
On Wed, May 6, 2015 at 9:04 PM, Suranga Kasthurirathne surangakas@gmail.com wrote:
Hi all,
An update,
Apparently the mediator fails to fire any of the requests to any of the registries when we send it the XDS.b message with content. This is despite it saying that it does in the logs. We determined that it is not by capturing outbound traffic on the registries
from the IOL box which hosted the mediator. When we tried with the empty message it showed traffic to the registries, as expected.
I’m currently using an XDS.b message that Justin generated and shared with me. This message seems to be fine in every way… (http://pastebin.com/ekw6z4LF).
–
You received this message because you are subscribed to the Google Groups “OpenHIE Sandbox” group.