...
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 rule, 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.
...
Getting Started with the DSL API
To execute a DSL query, a client will perform a PUT on the dsl endpoint and include a payload that includes the dsl query to be run. The version dictates which release's REST API version the output will be based on.
An AID for these custom queries is available on our AID page.
|
When calling the dsl API, the client must specify the output format as a query string. DSL API supports all formats that are supported by custom query API.
Output Formats
count
Provides
...
a count of the objects returned in the query.
Expand | |
---|---|
|
id
Provides an array of objects containing resource-type (A&AI's node type; i.e., generic-vnf) and a resource-link using the vertex ID from A&AI's graph.
Expand | |
---|---|
|
pathed
Provides an array of objects containing resource-type (A&AI's node type; i.e., generic-vnf) and a resource-link using the A&AI REST API pathed URIs.
Expand | |
---|---|
|
resource
Provides the each object in the results array in the same format as A&AI's REST API with depth = 1 (first level children and cousin relationships).
Expand | |
---|---|
|
resource_and_url
Provides each object in the results array in the same format as A&AI's REST API with depth = 1 (first level children and cousin relationships) plus the pathed url for the result object in A&AI.
Expand | |
---|---|
|
simple
Provides each result object in a simplified format. The node-type, graph vertex id, pathed url, object properties, and directly related objects in the graph are all returned. Both direct parent/child objects and cousin objects are included in the related-to array.
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.
|
graphson
Provides the results using the graphson standard.
Expand | |
---|---|
|
Optional Query Parameters
Depth
You can pass a depth query parameter on the resource or resource_and_url formats to indicate what level of child objects you want returned. By default the output will be depth = 1 (first level children).
|
Nodes Only
You can pass a nodes only query parameter to have the output only contain the object properties with no relationships. By default the output will be of depth = 1 (first level children and cousin relationships).
|
Subgraph
You can pass a subgraph query parameter that determines the behavior of the output. By default, a query returns all of the objects from the query and all of their relationships. Using subgraph=prune returns all of the objects from the query and only the edges between those objects. Using subgraph=star returns all of the objects from the query plus all of the objects they relate to.
|
Payload
Typically the dsl payload will include a "dsl" portion that includes the dsl query to be run.
|
DSL Query Format
Syntax
Symbol | Examples | Description |
---|---|---|
[] | [node1, node2] | Used for creating a union between nodes. |
() | node('property','filter') node(> node-filter) | Used for filtering the current node. Can be used with properties or filtering by related nodes, and multiple filters can be applied at once. |
* | node* node*('property','filter') | Used to return the current node, assuming it meets any filters. |
> | node1 > node2 | Used to traverse between nodes |
DSL Requirements and Best Practices
Requirements
- 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
Examples
Node Query(filter based on properties or negation)
Give me a vertex that have the given properties
|
Give me a vertex that do not have the given properties
|
Traversal Query
Traverse through cousin and children
|
Where Query(Filter based on a traversal or a subtraversal)
|
Union Query
|
...
Viewtracker Report |
---|