Page History

...

1. The solution must provide the foundational layer for consuming dynamic schema changes in the future
2. AAI schema service must support the ability to centrally persist (build-time) and serve (run-time) schema via REST
3. AAI schema service must support the ability to centrally persist (build-time) and serve (run-time) custom queries via REST - removing the custom query definitions from the traversal service and making the schema service responsible for them.
4. AAI schema service must support the ability to provide a complete schema as one document even if persisted via multiple files
5. AAI schema service must support the ability to provide a list of documents stored
6. AAI schema service must support the ability to provide an individual document
7. AAI schema service must support the ability to provide associations/grouping between documents (needs more clarity)
   1. OXM and Edgerules paired by version [v11, v12, v13]
   2. Grouped by usecase w/ multiple OXM files
8. AAI schema service must continue to support clients that consume the schema via XSDs and POJOs as build-time artifacts
   1. MSO uses this, and would have to update configuration for the location
   2. Followup item: Check with SEs on who is consuming the XSDs
9. AAI schema service must start before the Client AAI microservices that depend on itare configured to depend on the Schema Service will wait for the AAI Schema Service instance to start
10. AAI must support the option to load the schema files in a development mode (loading locally)
11. Client AAI microservices that currently depend on aai-common / aai-schema artifact at build time must use the AAI schema service REST API as its source for OXM schema files and edge rules Client AAI microservices must support an fallback mechanism that can be optionally triggered at microservice start-timerules (if configured to do so)

12. Epic for effort: 

    Jira
    server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key AAI-1859

    
    

...

1. A mS called Schema Service will hold and load all the schema (OXM and edge rules)  at start up 
2. The Schema Service will hold and load the custom query document at start up
3. The Schema Service will provide REST  endpoints via GETs such as  /aai/schema-service/{api-version}. Consumer mS, such as resource, traversal should use the updated ingest library to make REST calls to the Schema Service
4. The REST endpoint for providing the schema will support a "format" query parameter which will describe what format it is requested in eg. GET /aai/schema-service/v1/nodes?version={version}&format=OXM
5. The REST endpoints such as /aai/schema-service/v1/nodes?version={version} and /aai/schema-service/v1/edgerules?version={version} will provide a complete schema from multiple files
6. The REST endpoint such as /aai/schema-service/v1/list will provide the list of documents stored 
7. The REST endpoint such as /aai/schema-service/v1/nodes?version={version}, /aai/schema-service/v1/edgerules?version={version} and /aai/schema-service/v1/stored-query will provide the individual document
8. The REST endpoint will provide the associations between documents via query parameter "version"
9. The schema jar will continue to be provided as an artifact for consumers of XSD and POJOs 
10. HEAT environment and OOM environment will need to be addressed for Requirement #9

Future enhancements:

1. AAI should support the ability to consume new schema dynamically, without downtime (eg. when distributed by SDC)
2. AAI should support the ability to notify consumers of schema when new updates are available
3. AAI should support an interface to validate proposed schema changes
4. AAI should support the ability to provide the schema via flexible document formats (OXM, TOSCA etc.)

...