Hi Stavros, Your postman collection looks good to me.
Regarding the CFS service-instance to RFS service-instance relationship: in the AAI EdgeRules, these are considered as "cousins", since they are not sub-object relationships, but they are connected via the relationship-list. If you include the "relationship-label", then the relationship reads as "CFS service-instance is ComposedOf RFS service-instance". In this case "composed of" does have the connotation of a "containment", but in other EdgeRules, they are clearly peers (e.g. "links to", "bridges to", etc). Regarding the EdgeRule data: As explained here: https://lists.onap.org/g/onap-discuss/message/15607 In the EdgeRules, the relationship-label and relationship-data does not need to be specified on-create in most cases, since the system will use the default EdgeRule with the label based on the classes of the pair of objects and the data is derived from the related-link specified (it becomes necessary to specify data on-create if there are multiple EdgeRules available and you want a non-default value). Be careful here, since the EdgeRule is "service-instance to service-instance" and the relationship is "one-to-many", you will need to care which service-instance is on the "one" side and which service-instance is on the "many" side e.g. it would be wrong to have "RFS service-instance is ComposedOf CFS service-instance" and it would be apparent when you attempt to add too many relationships to the "one" side. Your data is correct, so no need to change it, but it could be simplified if you choose, e.g. { "service-instance-id": "012c7471-4e57-4ff2-9f45-03f4d20c50d4", "resource-version": "1551110120949", "relationship-list": { "relationship": [ { "related-to": "service-instance", "related-link": "/aai/v14/business/customers/customer/137dd565-18b9-4b00-a8d7-b9b16a2ef417/service-subscriptions/service-subscription/BBS-CFS/service-instances/service-instance/2ff21296-00f9-4cd4-9498-f5a357079f1b" }, { "related-to": "pnf", "related-link": "/aai/v14/network/pnfs/pnf/pnf-example-name" } ] } } Regarding your other email: As explained here: https://lists.onap.org/g/onap-discuss/message/15296 The PATCH is used on specific attributes that are clearly "owned" by the client project, e.g. SO or SDNC, and it only affects the attributes named in the request body. The PUT is expected to be a full replacement of the object, so the request body needs to be complete. See here for the caveats: https://onap.readthedocs.io/en/casablanca/submodules/aai/aai-common.git/docs/AAI%20REST%20API%20Documentation/AAIRESTAPI_CASABLANCA.html#a-warning-about-put-and-lists So, for example, if you have a service-instance relationship-list with pnf and service-instance, then the PUT on service-instance needs to specify both at the same time, otherwise you will lose data. If you do want to piece together the relationship one at a time, please look at this: https://onap.readthedocs.io/en/casablanca/submodules/aai/aai-common.git/docs/AAI%20REST%20API%20Documentation/AAIRESTAPI_CASABLANCA.html#the-relationship-list where the /relationship-list/relationship is treated as a sub-object. In this case, I would suggest the following procedure: - Create the CFS service-instance without relationships - Create the RFS service-instance without relationships - Create the PNF without relationships - Create the /relationship-list/relationship sub-object on CFS service-instance to link the RFS service-instance - Create the /relationship-list/relationship sub-object on RFS service-instance to link the PNF - Repeat steps above as required for each RFS service-instance and PNF - GET the CFS service-instance with depth=all and confirm the relationship-list contains multiple RFS and PNF relationships Doing it this way means you do not need to maintain a big list of objects in the relationship-list of the CFS. Regarding the depth parameter, you might want to try the GET from the customer level to see the variation in the output e.g. GET https://{{aai}}/aai/v14/business/customers/customer/137dd565-18b9-4b00-a8d7-b9b16a2ef417?depth=1 GET https://{{aai}}/aai/v14/business/customers/customer/137dd565-18b9-4b00-a8d7-b9b16a2ef417?depth=2 GET https://{{aai}}/aai/v14/business/customers/customer/137dd565-18b9-4b00-a8d7-b9b16a2ef417?depth=3 GET https://{{aai}}/aai/v14/business/customers/customer/137dd565-18b9-4b00-a8d7-b9b16a2ef417?depth=all The number of sub-object relationships needs to be deep enough for the increased depth to matter. The other way it might vary is if you use the "nodes" query with "format=simple" query parameter. In that case the "related-to" section should also show more objects that are more distantly related e.g. GET https://{{aai}}/aai/v14/nodes/service-instances?format=simple&depth=1 GET https://{{aai}}/aai/v14/nodes/service-instances?format=simple&depth=2 GET https://{{aai}}/aai/v14/nodes/service-instances?format=simple&depth=3 See example output: https://onap.readthedocs.io/en/casablanca/submodules/aai/aai-common.git/docs/AAI%20REST%20API%20Documentation/AAIRESTAPI_CASABLANCA.html#simple Keong From: Kanarakis, Stavros (Nokia - GR/Athens) [mailto:[email protected]] Sent: Tuesday, 26 February 2019 04:33 To: [email protected] Cc: Keong Lim <[email protected]> Subject: A&AI setup Hi team, I have tried to replicate today how our BBS use case will be in the A&AI (at least from a service-instances and PNF relationships perspective ... because these are the pieces that BBS micro-service needs to perform its job). I am sharing the POSTMAN automation scripts in case you want to experiment. You must import the Collection JSON file into POSTMAN and then execute it via the Runner utility after changing appropriately the external configuration that must be given as input (bbs-aai.json) What the automated script does inside A&AI is * Creates a customer * Create two subscriptions. One for BBS-CFS and another for BBS-Access * Creates the BBS-CFS service instance (puts also metadata into it) * Creates the BBS-Access service instance (also creates some metadata into it) and connects it at the same time with the BBS-CFS service instance * Creates the PNF and also at the same time connects it with BBS-Access service instance. New UUIDs are automatically generated by the script. You can see how all pieces are connected by then running this REST API call towards A&AI. GET https://{{aai}}/aai/v14/business/customers/customer/{{global-customer-id}}/service-subscriptions?depth=all<https://%7b%7baai%7d%7d/aai/v14/business/customers/customer/%7b%7bglobal-customer-id%7d%7d/service-subscriptions?depth=all> One issue that is not yet clear is if nested services share a parent-child relationship with the enclosed service instances or they are just connected between them as peers. Maybe Keong can shed some light here. Below is the output of the above GET command showing sample related objects from my A&AI instance { "service-subscription": [ { "service-type": "BBS-CFS4", "resource-version": "1551115284732", "service-instances": { "service-instance": [ { "service-instance-id": "506ba850-9c03-4f98-8bab-2f684a89fafb", "resource-version": "1551115287151", "orchestration-status": "assigned", "relationship-list": { "relationship": [ { "related-to": "service-instance", "relationship-label": "org.onap.relationships.inventory.ComposedOf", "related-link": "/aai/v14/business/customers/customer/cc9b148b-face-44bf-ab87-64ec9cf0d400/service-subscriptions/service-subscription/BBS-Access4/service-instances/service-instance/46233cbf-dac6-454a-928a-7dfb9b3b483c", "relationship-data": [ { "relationship-key": "customer.global-customer-id", "relationship-value": "cc9b148b-face-44bf-ab87-64ec9cf0d400" }, { "relationship-key": "service-subscription.service-type", "relationship-value": "BBS-Access4" }, { "relationship-key": "service-instance.service-instance-id", "relationship-value": "46233cbf-dac6-454a-928a-7dfb9b3b483c" } ], "related-to-property": [ { "property-key": "service-instance.service-instance-name" } ] } ] }, "metadata": { "metadatum": [ { "metaname": "cvlan", "metaval": "1005", "resource-version": "1551115287160" }, { "metaname": "svlan", "metaval": "100", "resource-version": "1551115287167" } ] } } ] } }, { "service-type": "BBS-Access4", "resource-version": "1551115285909", "service-instances": { "service-instance": [ { "service-instance-id": "46233cbf-dac6-454a-928a-7dfb9b3b483c", "resource-version": "1551115288582", "orchestration-status": "assigned", "relationship-list": { "relationship": [ { "related-to": "service-instance", "relationship-label": "org.onap.relationships.inventory.ComposedOf", "related-link": "/aai/v14/business/customers/customer/cc9b148b-face-44bf-ab87-64ec9cf0d400/service-subscriptions/service-subscription/BBS-CFS4/service-instances/service-instance/506ba850-9c03-4f98-8bab-2f684a89fafb", "relationship-data": [ { "relationship-key": "customer.global-customer-id", "relationship-value": "cc9b148b-face-44bf-ab87-64ec9cf0d400" }, { "relationship-key": "service-subscription.service-type", "relationship-value": "BBS-CFS4" }, { "relationship-key": "service-instance.service-instance-id", "relationship-value": "506ba850-9c03-4f98-8bab-2f684a89fafb" } ], "related-to-property": [ { "property-key": "service-instance.service-instance-name" } ] }, { "related-to": "pnf", "relationship-label": "org.onap.relationships.inventory.ComposedOf", "related-link": "/aai/v14/network/pnfs/pnf/pnf-4", "relationship-data": [ { "relationship-key": "pnf.pnf-name", "relationship-value": "pnf-4" } ] } ] }, "metadata": { "metadatum": [ { "metaname": "oltName", "metaval": "olt1", "resource-version": "1551115288602" } ] } } ] } } ] } Best Regards Stavros -------------------------------------------------------- Kanarakis Stavros R&D Software Engineer E-mail : [email protected]<mailto:[email protected]> Cell Phone : +30 6985 16 26 25 My NokiaEDU Achievements<http://nok.it/k6mUjn> BBA E2E SDAN @Athens Fixed Networks NOKIA -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15731): https://lists.onap.org/g/onap-discuss/message/15731 Mute This Topic: https://lists.onap.org/mt/30062910/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
