OData for developers
ALM Octane supports OData (Open Data Protocol), the OASIS REST-based standard for accessing data. You can use OData to extend and improve reporting capabilities, above and beyond the functionality provided by ALM Octane dashboard widgets.
This overview describes the use cases for developers to use the OData standard to access ALM Octane.
For OData version 4.0 support, download and install the Microsoft Power Query for Excel add-in.
Caution: Tableau’s support for OData is limited. For example, Tableau's OData support currently does not include the $expand interactive query argument, which ALM Octane uses extensively for cross entity reporting. Consider using a different reporting or business intelligence tool.
Developers can retrieve ALM Octane data over OData in the following ways:
|Directly, by querying with an API client||
|By designing applications to integrate with ALM Octane over OData||
Request that the site admin or space admin activate basic authentication for each space with the SUPPORTS_BASIC_AUTHENTICATION_FOR_ODATA configuration parameter. This enables ODATA integrations to connect to ALM Octane using Basic Authentication. For details, see Configuration parameters.
If ALM Octane is configured for SSO authentication, create API keys for working with OData integration.
The ALM Octane server base URI for accessing ALM Octane data using OData is:
Troubleshooting: If ALM Octane does not respond successfully to an OData consumer request, it might be because the base URL used to refer to ALM Octane is different than expected. Consider modifying ODATA_USE_SERVER_BASE_URL and SERVER_BASE_URL as described under Setting configuration parameters with the REST API or Configuration parameters.
Tip: You can restrict the expansion depth and control the OData behavior for private, non-selectable fields. For details, see the ODATA_* site parameters in Configuration parameters.
The section describes how to access ALM Octane data using OData with a REST client.
To work with OData, review the prerequisites for basic authentication under Prerequisites, and then authenticate with basic authentication.
Caution: Activating basic authentication enables external systems to access ALM Octane using this authentication method, not just OData.
You can authenticate with either:
Your user name and password.
An API access key.
For details, see Basic authentication.
Tip: When working with basic authentication, on each successful authentication, ALM Octane includes the LWSSO_COOKIE_KEY cookie in the response. We recommend that you send the LWSSO_COOKIE_KEY cookie with each subsequent OData request for enhanced performance. For details, see the information about the LWSSO_COOKIE_KEY under the topic Authenticating.
You can use OData to retrieve ALM Octane data, but you cannot update (POST, PUT, DELETE) ALM Octane data. Only GET operations are supported.
By default, a maximum of 1000 items are returned.
Example: To see all defects:
A history log is created when a new item is created or when you click Save after changing item fields. Each history log can contain one or more history records.
You can use OData calls to retrieve an audit of the history through the history_records entity. The OData history_records entity is parsed and derived from the history_log entity.
To enable the fetching of history records, you need to set the EXPAND_HISTORY_RECORDS parameter to true. For details, see Configuration parameters.
When using the $skip option with the history_records entity, you must include two additional parameters: $originalSkip and $innerOffset to indicate which history record and the offset within the record:
- originalSkip. How many history logs to skip.
- innerOffset. How many records to skip within the specified history log.
These parameters are calculated on the server side, and they are automatically added to the "next" link in a response, if a next page exists. Manually changing these parameters in the link, could result in inconsistent data fetching.
Note: The history_records API call is limited to fetching up to 10,000 history logs. If your results exceed this amount, you will receive a warning asking you to filter the request. You can filter by time/date, by entity_ID, by user_id, by action or by entity_type.
The actual number of history records may exceed 10,000, as long as the history logs do not exceed that amount. Each history log contains one or more history records, where all history records for a specific time interval are combined together, but parsed separately.
The following example skips to record 3 within history record 1084:
You can use OData options and operators to further refine your results.
This version of ALM Octane currently supports the following URI conventions:
$select, $search, $filter, $orderby, $top, $count, $paging, $skip, $format, $expand, $link & $count, and returning the raw value.
Note: When using the $skip option with the history_records entity, add two additional parameters: $originalSkip and $innerOffset. For details, see Specify an offset within history records - OData (technical preview).
Logical operators: eq, ne, gt, ge, lt, le, and, or, not, ( ). -
Filtering with logical operators on entities that have associations is not always supported.
How do I know if I can filter an entity with logical operators?
You cannot filter entities involved in associations with a multiplicity of *.
Check the OData $metadata file to look for the entity's associations.
The following OData metadata excerpt demonstrates that runs and releases have an association:
String functions: bool substringof, bool endswith, bool startwith
|Return all defects with the selected fields||
|Return defect 6001 with all its fields||
|Return all defects by name in descending order||
|Return all defects assigned to any sprint||
|Return all suite runs that have linked defects||
|Return all the defects created after 2017-08-23||
|Return all defects with assigned teams||