Please note that while Dublin release is in development, the tutorial steps may be out-of-sync with the current code. TBC NEED STEPS FOR NEW SCHEMA-SERVICE COMPONENT HERE |
Add the following attributes between "inMaint" and "resourceVersion" in the Complex object:
<xml-element default-value="false" java-attribute="inMaint" name="in-maint" required="true" type="java.lang.Boolean"> <xml-element java-attribute="newAttributeForDemo" name="new-attribute-for-demo" required="true" type="java.lang.String"> |
---|
Do not try to add a new attribute with ‘xml-key=”true”’ because it creates complications when the key value is already set! Existing classes in the schema will already have an xml-key set. Compare with the "NewWidget" example below. As a new class in the schema, NewWidget must define a new attribute with the xml-key set. |
Save the file, and rebuild the libraries and microservices:
here's my example file: aai_oxm_v16.xmlShould result in BUILD SUCCESS
Sometimes you may be tempted to use "-DskipTests" in the mvn command line to save some time, but it is known that some kinds of schema mistakes are detected only at run-time, not compile-time, so running the tests is a good indicator. |
Run GenTester in the graphadmin repository:
$ (cd graphadmin/ && mvn -PrunAjsc -Dstart-class=org.onap.aai.schema.GenTester -Daai.schema.version=0.0.1-TEST-SNAPSHOT -DskipTests -Dcheckstyle.skip=true -DAJSC_HOME=$HOME/src/aai/graphadmin -DBUNDLECONFIG_DIR=src/main/resources) You should see the following output: ---- NOTE --- about to open graph (takes a little while)--------; -- loading schema into JanusGraph -- loading schema into JanusGraph -- Loading new schema elements into JanusGraph -- -- graph commit -- graph shutdown cd graphadmin/logs/createDBSchema/; grep 'complex-name' metrics.log 2018-12-06T04:43:18.061+0000|2018-12-06T04:43:42.960+0000|449b8583-54c1-42bf-8ada-5b75c52d7a13||main ||AAI|AAI-TOOLS|AAI|main|COMPLETE|0|||INFO||127.0.1.1|24899|localhost||org.onap.a ai.dbgen.SchemaGenerator||||||||co=DBGenTester:Creating PropertyKey: [complex-name], [String], [SINGLE] 2018-12-06T04:43:18.061+0000|2018-12-06T04:43:42.960+0000|449b8583-54c1-42bf-8ada-5b75c52d7a13||main ||AAI|AAI-TOOLS|AAI|main|COMPLETE|0|||INFO||127.0.1.1|24899|localhost||org.onap.a ai.dbgen.SchemaGenerator||||||||co=DBGenTester:Add index for PropertyKey: [complex-name] |
---|
Get an example cloud-region object, postman: Cloud-Region Example.postman_collection.json
You should see the new attributes on the example object, as highlighted in the red rectangle above
PUT your new object data to persist the new attributes. Use this postman collection during the next 2 steps as well.
Run PUT Cloud-Region - missing attr. This will try to PUT the object without the required attribute we defined in the schema, and the response will look like this:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> |
---|
Adding a new node type. First, add the container under the top-level inventory category. Adding "newWidgets" to "Network" so the URI will be "aai/v16/network/new-widgets/new-widget/{new-widget-name}"
<java-type name="Network"> |
---|
Set up the "NewWidgets" java type:
<java-type name="NewWidgets"> |
---|
Set up the NewWidget java type:
<java-type name="NewWidget"> |
---|
Save the file, and rebuild the libraries and microservices:
here's my example file: aai_oxm_v16.xmlRun GenTester in the graphadmin repository:
$ (cd graphadmin/ && mvn -PrunAjsc -Dstart-class=org.onap.aai.schema.GenTester -Daai.schema.version=0.0.1-TEST-SNAPSHOT -DskipTests -Dcheckstyle.skip=true -DAJSC_HOME=$HOME/src/aai/graphadmin -DBUNDLECONFIG_DIR=src/main/resources) # You should see the following output: ---- NOTE --- about to open graph (takes a little while)--------; -- loading schema into JanusGraph -- loading schema into JanusGraph -- Loading new schema elements into JanusGraph -- -- graph commit -- graph shutdown #You can check the logs to see if the graph elements were created successfully and grep for your propertycd logs/createDBSchema/; Creating PropertyKey: [new-widget-name], [String], [SINGLE] |
---|
Add a new EdgeRule, allowing an edge between the CloudRegion and NewWidget:
{ "from": "cloud-region", "to": "tenant", "label": "has", "direction": "OUT", "multiplicity": "One2Many", "contains-other-v": "${direction}", "delete-other-v": "NONE", "SVC-INFRA": "!${direction}", "prevent-delete": "${direction}" }, { "from": "cloud-region", "to": "new-widget", "label": "has", "direction": "OUT", "multiplicity": "One2Many", "contains-other-v": "NONE", "delete-other-v": "NONE", "SVC-INFRA": "NONE", "prevent-delete": "NONE" }, This means cloud-region connects to new-widget, edge label is "has", it's an OUT edge, one cloud region can have multiple edges to new-widgets, cloud-region does not contain new-widget, new-widget will not be deleted when the cloud-region connected to it is deleted, it is not SVC_INFRA type, and having an edge to a new-widget will not prevent deletion of the cloud-region. |
---|