EES-5874 Create Search Function App

[leeoades]

New Azure Function App for Search

This PR contains a new function app created to handle new search processes.

Currently, there is only a single Azure Function called CreateSearchableReleaseDocument.

CreateSearchableReleaseDocument Function

This Azure Function is triggered by a new message on a source queue which contains details of a new Release version being published.
It consumes the message and makes a call to the ContentAPI to retrieve a ReleaseSearchViewModel. This contains a searchable HTML version of the release, plus associated metadata.
The function then creates a new Blob in the searchable documents container with this information.
Finally, the function publishes a message about the new Searchable Document to an output queue.

[benoutram]

Just letting you know there could be a problem here as I think Content API responses are serialised using Newtonsoft.Json, but this is using System.Text.Json. They are not always compatible but it might just be the fields involved here are working fine. I seem to remember there's a particular incompatibility around enums and this has been a problem for the Public API where the Admin (which also uses Newtonsoft.Json) consumes data from the Public API which uses System.Text.Json.

We want to migrate away from Newtonsoft.Json in favour of System.Text.Json, but we haven't completed this yet.

[leeoades]

That will be a configuration issue then. I'm hoping/praying that you're serialising the enums as their string label and not as some arbitrary number? There should be no compatibility issues as json serialisation is well defined and both implementations follow it. I'll double check to ensure the view model the API is producing is outputting the string.

[leeoades]

Actually, I've just checked and the view model does not have any enums on it.
I've also noticed your EnumToEnumValueJsonConverter. I'm sure this is a configuration setting and that we can set that instead. Let me see if I can find it...

[benoutram]

Yeah, mostly configuration issues that can either be resolved with out-of-the-box supported config or other workarounds.

There's a documented list of differences here in case you've not already seen it.

I think with enums it's easy to just add in the System.Text.Json string value converter, see enums-as-strings.

Our own EnumToEnumValueJsonConverter is doing something different. Thanks for pointing it out because that's where the incompatibility around enums came from for the Public API that I was thinking of, where we've also had to write our own System.Text.Json variant of that converter. There's also EnumToEnumLabelJsonConverter and the System.Text.Json variant of that.

'EnumToEnumValue' and 'EnumToEnumLabel' refer to getting the label or value from an EnumLabelValueAttribute annotated enum entry. E.g. GeographicLevel.LocalAuthority is annotated with a label of 'LocalAuthority' and value of 'LA'. With hindsight I think we probably regret this custom implementation! 😂

[EnumLabelValue("Local authority", "LA")]
LocalAuthority,

[leeoades]

Yikes. Well, for the view model that I am consuming, there are no such gremlins. And if we were to add an enum value to view model, I would represent it as a string through an explicit conversion and not rely on the serialiser. The dto can be unit tested also to ensure that the json is deserialised correctly.