Reference Server Initial Release

[darnjo]

There are a number of things that need to be done on the reference server before it can be released to the public as a reference server.

DevOps

• Use the RESO Services URL for the reference JSON. This has been changed recently (resources were added to the format to describe the available models, which is also coming in DD 2.1).
  • There will an update shortly with some minor changes to definitions, URLs, and a couple of field names.
• Move over to full Docker configs with no build scripts and make sure the build process works on Windows, Mac, and Linux
  • Environment variables
  • Initializing the database
  • Starting the server
• Move env-default to sample.env (instructions for how to fill in the .env, with a .gitignore for .env)
• Log4J patches, Olingo updates, etc.
• Build process needs to generate a container using GitHub Actions and store it in DockerHub (or GitHub Registry, ECR)

Development Tasks

• Generate insert statements for the Field Resource.
  • DisplayNames should be used now, and DisplayName is deprecated - these are a little difficult because they're a nested JSON shape.
  • We may be able to store this information as JSON as long as it supports the Web API Core search operators of any(), all(), eq, ne, and in.
  • Current "Core.Description" items in the annotations will become the "Definition" field
  • The reference JSON file doesn't handle string enumerations well at the moment, the type will still be the FQN + lookupName (in the field definition), which will appear in the "lookups" array. And the type for the enumeration value will be Edm.String rather than Edm.Int32 as it is now.
• Add support for multi-valued enumerations. See Refactor Storage in Reference Server to Support String Lookups #24 and Add Server Support for Lookup Resource and String Enumerations #25
• We should try and adopt as much of the Model, Field, and Lookup structure outlined in the Dictionary and factor in the new changes here: [RCP-42] Model and Field Resources transport#76
  • We will need to support this format sometime within the next quarter.
  • RESO has to refactor everything on the backend of the Certification System and reference formats in order to support these changes, so there's no pressure to do it now, but it's a Q2-Q3 2023 goal.
• Finish Data Generator
  • A data generator exists to populate the reference server with test data for every resource and field in the Data Dictionary, along with realistic relationships between important items like ListAgentKey in the Property Resource and MemberKey in the Member Resource.
• Ensure Web API Core 2.0.0 and Data Dictionary 1.7 Tests Pass
  • Web API Core testing requires some data in the database with support for roughly 40 queries as outlined in the specification. See section on Certification.
  • Data Dictionary 1.7 metadata testing - this should pass because we generate the server from the reference documents.
  • Data Dictionary 1.7 data validation - this requires data in each resource and for sort by modification timestamp and timestamp comparison operators to work for each resource with timestamps present 100% of the time in the test data set.

Documentation

• Ensure documentation for how to set up the reference server locally (or by using the generated Docker containers from DockerHub) is up to date and includes instructions for how to run the data generator.
• Publish Postman Collections for the Web API showing standard queries on all resources.
• Documentation showing common queries, similar to what's in the Web API examples, on the reference server.