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.

Using OData with ALM Octane overview

This overview describes the use cases for developers to use the OData standard to access ALM Octane.

ALM Octane supports OData version 4.0.

For OData version 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 is used 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: 

Access method Steps
Directly, by querying with an API client
By designing applications to integrate with ALM Octane over OData
  • Connect to ALM Octane's OData support using basic authentication. For details, see Basic authentication.

  • Use OData resources to work with ALM Octane data. For details, see the OData documentation.

    Note: Only GET requests are supported when working with OData.

Back to top

Prerequisites

  • 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.

Back to top

The ALM Octane server base URI

The ALM Octane server base URI for accessing ALM Octane data using OData is: 

<https://<server> /odata/v4/shared_spaces/<space_ID>/workspaces/<workspace_ID>/

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.

Back to top

Access ALM Octane data using OData with a REST client

The section describes how to access ALM Octane data using OData with a REST client.

Authenticating

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 Authentication.

Retrieving ALM Octane data

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: GET <base_URI>/defects

Specify an offset within history records - OData (technical preview)

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:

https://host.name.com/odata/v4/shared_spaces/1001/workspaces/1002/history_records?null&$skip=6000&originalSkip=1083&innerOffset=2

Back to top

OData options and operators

You can use OData options and operators to further refine your results.

This version of ALM Octane currently supports the following URI conventions:

Area Supported conventions
Options

$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).

$filter operators

Logical operators: eq, ne, gt, ge, lt, le, and, or, not, ( ). -

Filtering with logical operators on entities that have associations is not always supported.

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:

<Association Name="run_to_release">
 <End Type="OData.Octane.run" Multiplicity="*" Role="run->release"/>
 <End Type="OData.Octane.release" Multiplicity="1" Role="release->run"/>
</Association>

  • The release's multiplicity is 1, so you can filter the run entity for a specific release with logical operators. Only one release can be associated with a run.

  • The run's multiplicity is *, so you cannot filter the release entity for a specific run with logical operators. Many runs can be associated with a release.

Functions

String functions: bool substringof, bool endswith, bool startwith

URI examples

To... Use...
Return all defects with the selected fields /defects?$select=id,name,description
Return defect 6001 with all its fields /defects('6001')
Return all defects by name in descending order /defects?$orderby=name desc
Return all defects assigned to any sprint /defects?$filter=sprint ne null
Return all suite runs that have linked defects /suite_run?$filter=defect_indirect ne null&$expand=defect_indirect
Return all the defects created after 2017-08-23 /defects?$filter=creation_time ge datetimeoffset'2017-08-24T00:00:00Z'
Return all defects with assigned teams /defects?$filter=team ne null

Back to top

See also: