Modify IServiceListener interface to distinguish pre/post storage event

[Keathley3M]

I may not be alone in the need to modify the resource based on external systems. In order to do this with the highest performance possible (e.g. making external calls only when necessary), the ideal place would be right before the storage call is made. Right now the closest implementation of this is the way IServiceListener is used in FhirService, but it only response with the Inform method after the resource is saved.

Can a similar pattern be used to "inform" before the storage call?

https://github.com/furore-fhir/spark/blob/master/src/Spark.Engine/Service/IServiceListener.cs

https://github.com/furore-fhir/spark/blob/master/src/Spark.Engine/Service/FhirService.cs

private void Store(Interaction interaction)
{
    // New interface method here!

    fhirStore.Add(interaction);

    //CK: try the new indexing service.
    if (_indexService != null)
    {
        _indexService.Process(interaction);
    }

    else if (fhirIndex != null)
    {
        //TODO: If IndexService is working correctly, remove the reference to fhirIndex.
        fhirIndex.Process(interaction);
    }


    if (serviceListener != null)
    {
        Uri location = localhost.GetAbsoluteUri(interaction.Key);
        // todo: what we want is not to send localhost to the listener, but to add the Resource.Base. But that is not an option in the current infrastructure.
        // It would modify interaction.Resource, while 
        serviceListener.Inform(location, interaction);
    }
}

[mharthoorn]

Definitely! We have had several ideas in this area already. It's worthwile to pursue further. I will put it on the nearterm roadmap.

[mharthoorn]

We are also considering to move to ASP.NET core and allow you to add your own custom FHIR middleware.

[Keathley3M]

The middleware approach (owin etc.) was another road we were potentially going down if there was no other recourse. I can definitely see the abstraction of pure request/response tuning being a great one-size-fits-all solution for those who wish to stay outside of the spark/fhir lifecycle.

Thanks for the quick response.

[mharthoorn]

We did quite a bit of refactoring here. Let's check how this changes this request.