Examples of retrieving metadata
This section provides examples of how to access the metadata for entities and fields to work with the ALM Octane REST API.
Get metadata for the user story entity
Request
GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/metadata/entities?query="name EQ 'story'"
Response
{ "data": [ { "features": [ { "methods": [ "DELETE", "POST", "GET", "PUT" ], "name": "rest", "url": "stories" }, { "name": "mailing", "url": "mails" }, { "name": "phases" }, { "name": "subtype_of", "type": "work_item" }, { "parent_types": [ "feature", "work_item_root" ], "max_depth": 4, "root": { "type": "work_item_root", "id": "1001" }, "name": "hierarchy", "child_types": [] }, { "name": "user_defined_fields" }, { "name": "business_rules" }, { "name": "comments", }, { "name": "attachments", } ], "name": "story", "description": null, "label": "Story", "type": "entity_metadata" } ], "total_count": 1 }
Explanation of the response
Let's look at this example on the workspace level. You can see from this example that:
Get field metadata for pipelines
Here is an example on the workspace level for pipelines.
Request
GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/metadata/fields?query="entity_name EQ 'pipeline'"
Explanation of results
Description | Metadata |
---|---|
Pipeline fields include ID, pipeline name, creation time, the root job for the pipeline, version stamp, author, and current release. | "name": "id", "name": "name", "name": "creation_time", "name": "version_stamp", "name": "author", "name": "last_modified", "name": "current_release", |
You can see information about each pipeline field, including (but not limited to):
|
{ "entity_name": "pipeline", "description": "", "label": "Creation time", "name": "creation_time", "field_type": "date_time", }, |
Indication that the field references an entity collection. See also: Reference.
|
"field_type_data": { "multiple": false, "targets": [ { "type": ""workspace_user" } ] }, |
If a field supports sanitization. REST API output sanitization removes or encodes data returned by requests. This reduces security risks. See also: Sanitization. Valid sanitization types are:
|
{ "sanitization": "NONE" }, |
If the field supports additional functionality / features, such as tracking for history purposes. In this case, the functionality is called auditable. | "field_features": [ { "name": "auditable" } ], |
If a field is final. A value can be supplied to a field only upon creation of an entity. Then the field becomes read-only. The Author field is a good candidate for setting final to true. See also: Final |
{
"final": true
},
|
You can determine if a pipeline field:
|
{ "filterable": true, "editable": false, "label": "Creation time", "sortable": true, "is_user_defined": false, "required": false, "accessible_via_business_rules": true, "unique": false, "name": "creation_time", "groupable": false, "visible_in_ui": true }, |
Know which fields are required for an entity
When creating a new entity using the REST API, it is helpful to know in advance which fields are mandatory. Use the required attribute.
GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/metadata/fields?query="entity_name EQ 'defect'; required EQ 'true'"
See which fields are not returned by default on GET operations
To see a list of fields that are not returned by default, query the field metadata to check the returned_by_default attribute:
GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/metadata/fields?query="returned_by_default EQ false"
Get the allowed values for entity fields
Some entities are associated with lists. For example, runs are associated with statuses. Other entities, such as stories, defects, and requirements, are associated with phases.
Skipped might be a valid status for an automated test run, but not for a manual test run.
In Design might be a valid phase for a requirement, but not for a defect.
When creating a new entity, you must provide the correct status or phase, as these are mandatory fields.
This topic explains how to get the values that are relevant for your entity using field metadata and the list_node resource collection. The list_node resource collection contains all list values and maps them to their relevant entities.
Get valid values for a manual test run's statuses
Using the field metadata, we can see all fields and their properties for manual runs:
GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/metadata/fields?query="entity_name EQ ^run_manual^"
We see two status fields for manual test runs:
-
list_node.native_status, whose description is "The run's status, such as Planned, Passed, Failed, Not completed or Blocked."
-
list_node.run_status, whose description is "The aggregated status of the run, such as Passed, Failed, or Requires attention." This status is used to summarize native statuses for analysis purposes, such as in the Dashboard.
The values for both of these statuses are stored as target references to list nodes, using the logical_name attribute.
list_node.native_status
"field_type_data": { "multiple": false, "targets": [ { "logical_name": "list_node.run_native_status", "type": "list_node" } ] },
list_node.run_status
"field_type_data": { "multiple": false, "targets": [ { "logical_name": "list_node.run_status", "type": "list_node" } ] },
To see the allowed values for the manual run native status, let's look in the list_nodes resource collection for the statuses based on the logical name prefix list_node.run_native_status. We use the wildcard * to list all statuses with this prefix.
GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>list_nodes?query="logical_name EQ ^list_node.run_native_status*^"
We now see the allowed statuses for manual runs, which we can assign, for example, when POSTing a new manual test run using the REST API. The statuses are passed, failed, blocked, skipped, completed, and planned (plus one root list_node).
See comments for an entity
For performance optimization, when GETting entities, comments are not included in the response. To see comments, you have to explicitly request them using the fields clause.
GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/defects&fields=comments
Get deprecated API resources for a specific version
After upgrading to a new version of ALM Octane, you might want to see a list of resources that have been deprecated. In preparation for when deprecated these resources are no longer supported, you might want to update your code to refer to the corresponding alias instead.
To see deprecated resources, query on the deprecated field and specify the version number to which you just upgraded.
Example for deprecated resources:
GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/metadata/fields?query="deprecated EQ ^12.55.8^"
Tip: To see the alias for a deprecated resource, use the interactive API client. For details, see Interactive API client.
See also: