Interceptor data sent back to the caller

[albvegli]

Using the interceptor I need to add more information to the returned afterSearch (bundle) data.
I have generated a new bundle but cannot send it to the caller. Everything I've tried to do doesn't change the packet sent to the caller.
How can I update the packet sent back to the caller?

[punktilious]

@albvegli thank you for opening this issue. Unfortunately the current code does not return the updated resource if it is changed by the interceptor. In FHIRRestHelper:

            // Invoke the 'afterSearch' interceptor methods.
            getInterceptorMgr().fireAfterSearchEvent(event);

            // Commit our transaction if we started one before.
            txn.commit();
            txn = null;

            return bundle;

We'll add this to our backlog. The team needs to discuss this to see if there are any implications for supporting this behavior. To make sure we properly consider your scenario, could you provide more detail on what changes your interceptor needs to make to the bundle?

[albvegli]

Thanks for the reply.
The aim is to add any consents relating to the patients involved to the selected resources (entry).
To do this, I perform searches within the procedure (search consents). These operations cause new calls to the interceptor. I solved this problem by manipulating the message header in order to recognize and discard the searches carried out from within the procedure. Perhaps it would also be good to provide a system to avoid these re-entries.

[punktilious]

Thanks. It's an interesting point you raise about interceptors invoking interactions which then cause nested calls to the interceptor. It seems like it would be possible to track this in the request context, which would make it a lot easier for an implementer (you) to understand where you are and react appropriately. I'll discuss with the team and get back to you.

[lmsurpre]

@albvegli how are you performing the search from within your interceptor?

I would have expected your interceptor to use event.getPersistenceImpl() to get the FHIRPersistence implementation from the FHIRPersistenceEvent.

Its a little tricky to set up the FHIRSearchContext, but it should be possible to invoke "FHIRPersistence.search" from your interceptor and avoid going all the way back out through the REST layer. If done this way, there is no "re-entry" because the interceptors are invoked outside of the persistence layer.

Let us know.

[albvegli]

Yes, I’m usig event.getPersistenceImpl().

Patient pat = null;
try {
FHIRRestHelper helper = new FHIRRestHelper(event.getPersistenceImpl(),searchHelper);
Resource resource = helper.doRead("Patient", id, false, false, null, null).getResource();
pat = (Patient) resource;
} catch (Exception e) {
e.printStackTrace();
}

I have now stopped developing this feature due to the inability to return additional information. If I need it later I will try to follow your advice.
Thank you.

[punktilious]

As @lmsurpre mentioned, you can use the persistence layer to perform the read directly:

    /**
     * Retrieves the most recent version of a FHIR Resource from the datastore.
     *
     * @param context the FHIRPersistenceContext instance associated with the current request
     * @param resourceType the resource type of the Resource instance to be retrieved
     * @param logicalId the logical id of the Resource instance to be retrieved
     * @return a SingleResourceResult with a ResourceResult populated from from the datastore and/or
     *         an OperationOutcome with hints, warnings, or errors related to the interaction
     * @throws FHIRPersistenceException
     * @implSpec Reading a non-existent resource will result in a SingleResourceResult with success=false and isDeleted=false
     * @implSpec Reading a deleted resource will result in a SingleResourceResult with both success=true and isDeleted=true
     */
    <T extends Resource> SingleResourceResult<T> read(FHIRPersistenceContext context, Class<T> resourceType, String logicalId)
            throws FHIRPersistenceException;

I've implemented the feature to allow the updated bundle to be returned. It's in review so hasn't been merged yet, but we hope to make it part of the next release (5.0.0).