Stream: implementers
Topic: Using the Java Validator in another process
Grahame Grieve (Jan 12 2018 at 22:27):
In the last few days, I've got around to something I've been meaning to for a while. I've set up the java validator so you can host it in another service, and use the services it has in a wider context. The way it works is
- put the jar in your class path
- Find the class org.hl7.fhir.r4.validation.NativeHostServices or org.hl7.fhir.dstu3.validation.NativeHostServices
- call init(path) where path refers to one of the definitions files from the main build (e.g. definitions.xml.zip) - required, do only once, do before anything else
- call load(path) where path refers to the igpack.zip produced by the ig publisher (do this once for each IG you care about)
- call connectToTxSvc(url) where the url is your terminology service of choice (can be http://tx.fhir.org/r4 or /r3)
now the jar is ready for action. There's 3 functions you can call (all are thread safe):
- validate - given a resource, validate it against all known rules
- convert - given a resource in a different version convert it to this version (if possible)
- unconvert - given a resource, convert it to a different version (if possible)
also, call "status" to get a json object that describes the internals of the jar (e.g. for server status)
The interface is optimised for JNI.
Grahame Grieve (Jan 12 2018 at 22:28):
let me know if this is something you're interested in , or if you want additional functions exposed
Oliver Egger (Jan 13 2018 at 13:35):
thanks a lot for that effort, i'm very interested in this.
Anand Mohan Tumuluri (Jan 16 2018 at 20:58):
Unfortunately this change breaks the command line use of the validator since it tries to validate references. Is there any flag to disable the reference resolution?
Grahame Grieve (Jan 17 2018 at 11:21):
I'm pretty sure this didn't break that.
Grahame Grieve (Jan 17 2018 at 11:22):
there's no parameter for that... I'll have to think about that
Michael Lawley (Feb 02 2018 at 04:50):
Is this library available via HAPI?
Also, what are the required capabilities of the external terminology service of choice?
Grahame Grieve (Feb 02 2018 at 05:12):
I don't know. @James Agnew has to include the new files in HAPI
Grahame Grieve (Feb 02 2018 at 05:12):
capabilities - thorough support for terminology operations including $validate and $expand
James Agnew (Feb 02 2018 at 10:31):
I don't really know what it would add for this to be available in HAPI. HAPI's existing wrapper and validation support chain framework have been providing the ability for you to keep a validator instance available for use in memory for a long time now.
Presumably the use case for this is more for JNI (which isn't really a design goal of HAPI's)?
Grahame Grieve (Feb 02 2018 at 10:31):
I think so
Grahame Grieve (Feb 02 2018 at 10:32):
still, maybe there's a role for other HAPI services inside a non-Java process?
James Agnew (Feb 02 2018 at 10:33):
Possibly... TBH I have never even touched the JNI stuff, I don't know much about how to do it well...
Jens Villadsen (Feb 02 2018 at 12:14):
As a choice of design, I would use the HAPI validator as a separate service and just invoke it using regular HTTP
Richard Ettema (Feb 02 2018 at 15:40):
Not sure if I'm missing something here, but this sounds like the $validate operation - http://build.fhir.org/resource-operations.html#validate.
Grahame Grieve (Feb 02 2018 at 15:42):
for me it's behind that operation
Brian Postlethwaite (Feb 02 2018 at 16:05):
Or calling it prior to submitting a resource internally with specific profile(s)
Last updated: Apr 12 2022 at 19:14 UTC
