This page will serve as a reference for how to use the A&AI DSL API and commonly used DSL queries.
Before You Start!
It's important that you engage the AAI team before running any adhoc DSL queries. The current process is to have the AAI team vet the DSL queries to make sure the traversal used is optimal and does not cause performance issues in A&AI. As edge rules and schema may change, it is important for clients to communicate the DSL queries that they use. It's important that, at the very least, we know who is using which queries so we can be cautious of changes in the future. And we can help you find the best way to get the data you need.
Table of Contents
Getting Started with the DSL API
...
| Expand | |
|---|---|
|
...
| Expand | |
|---|---|
Walking back through relationships in the simple format:Let's say you got back a large tree of output in the simple format and need to go through the list of objects to understand their relationships. For example, the output returned vnfs, vservers, pservers and complexes but you want to only look at the results of a particular complex. First, we'll find the JSON object for the complex by looking at the result objects for one with "node-type": "complex" and "physical-location-id": (the CLLI of the location you want to filter on) within the "properties" object. Next you would check the "related-to" object array for objects with "node-type": "pserver", take the "id"s and search for objects with those IDs in the results object array. You can keep crawling through the results in this way until you reach the objects you need. You can use this method for any property you want to filter on.
|
...
- Start Node in the DSL Query should include filtered properties that are keys or indexed properties. These come from a special property in oxm (DslStartNodeProperties). The below will error out
- cloud-region*
- pserver('prov-status','PROV')
- ERR.5.4.6149 : DSL Error while processing the query :Non indexed keys sent. Valid keys for cloud-region cloud-owner,cloud-region-id,cloud-type
- There should be atleast one return node type specified. If the user does not specify a "*" or store('x') on any node type it errors out
- generic-vnf('vnf-type','SW')('equipment-role','UCPE') > service-instance > service-subscription
- ERR.5.4.6152: No nodes marked for output
- Check if a valid edge exists between the node types specified and labels
- ERR.5.4.6107: No EdgeRule found for passed nodeTypes: cloud-region, l-interface
- ERR.5.4.6107: No rules found for EdgeRuleQuery with filter params node type: cloud-region, node type: complex, label: org.onap.relationships.inventory.Belongs, type: TREE, isPrivate: false
- Check for redundant edges to prevent the possibility of loops to occur from a DSL query.
A > B, B > C, C > A- ERR.5.4.6151: Validation error :Loop Validation failed
- ERR.5.4.6151: Validation error :Loop Validation failed
- Check if the dsl has a max type of vertices returned or traversed - if beyond that then the client should use CQ
- ERR.5.4.6151: Validation error :NodeCount Validation failed"
- Syntax Errors are caught at the grammar level
- ERR.5.4.6153: DSL Syntax Error while processing the query
- ERR.5.4.6153: DSL Syntax Error while processing the query
- Lower Timeouts for DSL Queries
- DSL Queries have a lower timeout than custom queries or any other APIs in resources or traversal to prevent the client from running adhoc queries
- DSL Queries have a lower timeout than custom queries or any other APIs in resources or traversal to prevent the client from running adhoc queries
- aa
Best Practices
- Verify if the DSL traversal is optimal. Run .profile() on the underlying gremlin query
- If available always use keys or unique indexes in the start node or any node in the query
- Frequently used DSL queries should be encouraged to be converted to custom-queries since the start-node in a custom query has a URI
- Run the format=count and verify if the traversal can be reversed to get the optimal query
...