Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device.
Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
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.
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.
PUT /aai/v$/dsl?format={format}
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.
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.
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.
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. {
"results": [
...,
{
"id": "14147624",
"node-type": "complex",
"url": "https://aai.onap:8443/aai/v16/cloud-infrastructure/complexes/complex/EXAMPLE_COMPLEX_ID",
"properties": {
...
"physical-location-id": "EXAMPLE_COMPLEX_ID",
...
},
"related-to": [
{
"id": "2134056",
"node-type": "pserver",
"url": "https://aai.onap:8443/aai/v16/cloud-infrastructure/pservers/pserver/EXAMPLE_PSERVER"
},
{
"id": "2158632",
"node-type": "pserver",
"url": "https://aai.onap:8443/aai/v16/cloud-infrastructure/pservers/pserver/EXAMPLE_PSERVER2"
},...
]
},...
]
}
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).
PUT /aai/v$/query?format={resource OR resource_and_url}&depth=0
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).
PUT /aai/v$/query?format={format}&nodesOnly=true
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.
PUT /aai/v$/query?format={format}&subgraph={subgraph}
Payload
Typically the dsl payload will include a "dsl" portion that includes the dsl query to be run.
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