FHIR Chat · handling transactions · hapi

Stream: hapi

Topic: handling transactions


view this post on Zulip Jens Villadsen (Dec 11 2019 at 15:40):

Through FHIR transactions it is possible to execute methods not exposed in the resource provider. If you eg. have removed the option to POST patients, it is still possible to do POST on a Patient resource in the transaction bundle as FHIR transactions is HAPI directly uses the underlying dao. Is this the intended behaviour? @James Agnew

view this post on Zulip Jens Villadsen (Dec 11 2019 at 15:41):

It seems a bit weird because if I try to create the Patient using ordinary creation using POST, the RestfulServer class will not allow it as it cannot find the proper binding. Could an interceptor that inspected the capability statement and whitelisted the operations be a proper solution?

view this post on Zulip James Agnew (Dec 11 2019 at 15:54):

We don't support the ability to remove functionality from the JPA server,
this is something you added isn't it?

The supported way to block operations completely from the JPA server is to
use the AuthorizationInterceptor.

An alternate might be for you to add an interceptor that looks at
transaction bundles and does some validation for whatever logic you want.

view this post on Zulip Jens Villadsen (Dec 11 2019 at 18:25):

We don't support the ability to remove functionality from the JPA server,
this is something you added isn't it?

Yes, this is contained in https://github.com/jamesagnew/hapi-fhir/pull/1574 in order for us to define fine grained control over what is supported and what isn't supported.

Now, besides using the JPA server capabilities, we have also added business validation rules inside our Resource Providers. We also (naturally) have an implementation of the authorization interceptor that authorizes according to our business rules - this is ofcourse invoked when running transactions as any other interceptor.

For us to support the current implementation of transaction that is going directly to the dao's probably requires us to rewrite all business validation logic that is currently carried out inside Resource Providers and instead put that logic inside the interceptors in the proper pointcuts, as the interceptors are still invoked when using the daos.

This is a bit of a surprise, but I understand the logic behind the design. I would therefore highly recommend that the documentation should be updated to state that putting business logic into resource providers when using the HAPI JPA is NOT be recommended if transactions should be supported.

Sounds reasonable?

view this post on Zulip James Agnew (Dec 12 2019 at 14:18):

Yup, makes sense to me. PRs welcome.

view this post on Zulip Jose Costa Teixeira (May 14 2020 at 15:05):

basic question - does hapi handle transactions ? Can I post one and watch the resources being created/deleted?

view this post on Zulip Jens Villadsen (May 14 2020 at 15:35):

yes

view this post on Zulip Jens Villadsen (May 14 2020 at 15:36):

assuming you are using a vanilla HAPI FHIR JPA setup

view this post on Zulip Jose Costa Teixeira (May 14 2020 at 15:37):

thanks


Last updated: Apr 12 2022 at 19:14 UTC