Skip to main content

Data Source

Follow the instructions below to create a new data flow that ingests data from an Azure DevOps source in Nexla.
azure_devops_api.png

Azure DevOps

Create a New Data Flow​

  1. To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Then, select the desired flow type from the list, and click the Create button.

  2. Select the Azure DevOps connector tile from the list of available connectors. Then, select the credential that will be used to connect to the Azure DevOps instance, and click Next; or, create a new Azure DevOps credential for use in this flow.

  3. In Nexla, Azure DevOps data sources can be created using pre-built endpoint templates, which expedite source setup for common Azure DevOps endpoints. Each template is designed specifically for the corresponding Azure DevOps endpoint, making source configuration easy and efficient.
    • To configure this source using a template, follow the instructions in Configure Using a Template.

    Azure DevOps sources can also be configured manually, allowing you to ingest data from Azure DevOps endpoints not included in the pre-built templates or apply further customizations to exactly suit your needs.
    • To configure this source manually, follow the instructions in Configure Manually.

Configure Using a Template​

Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common Azure DevOps endpoints. Each template is designed specifically for the corresponding Azure DevOps endpoint, making data source setup easy and efficient.

Endpoint Settings​

  • Select the endpoint from which this source will fetch data from the Endpoint pulldown menu. Available endpoint templates are listed in the expandable boxes below. Click on an endpoint to see more information about it and how to configure your data source for this endpoint.

    Get Object By ID: Work Item Tracking

    This endpoint retrieves the details for a specific Work Item Tracking object by its ID. Use this endpoint when you need to access detailed information about a specific work item, such as a task, bug, user story, or other work item type.

    • Enter the name of your Azure DevOps organization in the Organization field. This is the organization name that appears in your Azure DevOps URL (e.g., if your URL is https://dev.azure.com/MyOrg, enter MyOrg).
    • Enter the name of your Azure DevOps project in the Project field. This is the project name within your organization.
    • Select the type of Work Item Tracking object you want to retrieve from the WIT Object dropdown menu. Available options include work item types such as workitems, queries, fields, and other WIT object types.
    • Enter the ID of the specific object you want to retrieve in the ID field. This should be the numeric ID of the work item or object you want to access.
    • Enter the API version in the API Version field. This should be the Azure DevOps REST API version you want to use (e.g., 7.0, 7.1). The API version determines which features and response formats are available.
    • The endpoint uses GET requests to the Azure DevOps Work Item Tracking API endpoint (https://dev.azure.com/{organization}/{project}/_apis/wit/{wit_object}/{id}) with the specified API version query parameter.
    • The endpoint will return the complete details of the specified work item or object. The response data is returned at the root level of the JSON response ($), containing all fields and properties of the work item.

    This endpoint requires a valid organization name, project name, WIT object type, and object ID. The endpoint does not use pagination and returns a single object. The endpoint requires Basic Authentication with a Personal Access Token, which is handled automatically by your credential configuration. For detailed information about the Work Item Tracking API, including available object types, API versions, and response formats, see the Azure DevOps Work Item Tracking API documentation.

    WIQL - Query by Wiql

    This endpoint executes a Work Item Query Language (WIQL) query to retrieve work items that match the specified query criteria. Use this endpoint when you need to retrieve multiple work items based on custom query conditions, such as filtering by status, assignee, or other work item fields.

    • Enter the name of your Azure DevOps organization in the Organization field. This is the organization name that appears in your Azure DevOps URL.
    • Enter the name of your Azure DevOps project in the Project field. This is the project name within your organization.
    • Enter the name of your Azure DevOps team in the Team field. This is the team name within your project.
    • Enter your WIQL query in the WIQL field. WIQL is a SQL-like query language for querying work items. For example, SELECT [System.Id] FROM WorkItems WHERE [System.State] = 'Active' retrieves all active work items.
    • Enter the API version in the API Version field. This should be the Azure DevOps REST API version you want to use (e.g., 7.0, 7.1).
    • The endpoint uses POST requests to the Azure DevOps WIQL API endpoint (https://dev.azure.com/{organization}/{project}/{team}/_apis/wit/wiql) with the WIQL query in the request body as JSON ({"query": "{your_wiql_query}"}).
    • The endpoint will return the results of the WIQL query, including work item IDs and references. The response data is returned at the root level of the JSON response ($), containing query results and work item references.

    This endpoint requires a valid WIQL query string. WIQL syntax is similar to SQL and allows you to filter, sort, and select work items based on various criteria. The endpoint uses POST requests with the query in the request body. The endpoint requires Basic Authentication with a Personal Access Token, which is handled automatically by your credential configuration. For detailed information about WIQL syntax, query examples, and the WIQL API, see the Azure DevOps WIQL API documentation.

    List all records : Work

    This endpoint retrieves a list of all records of a selected Work object type from your Azure DevOps project. Use this endpoint when you need to access all items of a specific work type, such as all iterations, team days off, or other work-related objects.

    • Enter the name of your Azure DevOps organization in the Organization field. This is the organization name that appears in your Azure DevOps URL.
    • Enter the name of your Azure DevOps project in the Project field. This is the project name within your organization.
    • Enter the name of your Azure DevOps team in the Team field. This is the team name within your project.
    • Select the type of Work object you want to retrieve from the Work Object dropdown menu. Available options include teamsettings, iterations, teamdays off, and other work object types.
    • Enter the API version in the API Version field. This should be the Azure DevOps REST API version you want to use (e.g., 7.0, 7.1).
    • The endpoint uses GET requests to the Azure DevOps Work API endpoint (https://dev.azure.com/{organization}/{project}/{team}/_apis/work/{work_object}) with the specified API version query parameter.
    • The endpoint will return all records of the selected work object type. The response data is extracted from the value array in the API response ($.value[*]), with each record processed individually.

    This endpoint retrieves all records of the specified work object type. The endpoint does not use pagination and returns all available records in a single request. The endpoint requires Basic Authentication with a Personal Access Token, which is handled automatically by your credential configuration. For detailed information about the Work API, including available work object types, API versions, and response formats, see the Azure DevOps Work API documentation.

    Get Object By ID: Work

    This endpoint retrieves the details for a specific Work object by its ID. Use this endpoint when you need to access detailed information about a specific work object, such as a team iteration or team days off entry.

    • Enter the name of your Azure DevOps organization in the Organization field. This is the organization name that appears in your Azure DevOps URL.
    • Enter the name of your Azure DevOps project in the Project field. This is the project name within your organization.
    • Enter the name of your Azure DevOps team in the Team field. This is the team name within your project.
    • Select the type of Work object you want to retrieve from the Work Object dropdown menu. Available options include teamsettings, iterations, teamdays off, and other work object types.
    • Enter the ID of the specific object you want to retrieve in the ID field. This should be the ID of the work object you want to access.
    • Enter the API version in the API Version field. This should be the Azure DevOps REST API version you want to use (e.g., 7.0, 7.1).
    • The endpoint uses GET requests to the Azure DevOps Work API endpoint (https://dev.azure.com/{organization}/{project}/{team}/_apis/work/{work_object}/{id}) with the specified API version query parameter.
    • The endpoint will return the complete details of the specified work object. The response data is extracted from the value array in the API response ($.value[*]), containing all fields and properties of the work object.

    This endpoint requires a valid organization name, project name, team name, work object type, and object ID. The endpoint does not use pagination and returns a single object or array of related objects. The endpoint requires Basic Authentication with a Personal Access Token, which is handled automatically by your credential configuration. For detailed information about the Work API, including available object types, API versions, and response formats, see the Azure DevOps Work API documentation.

    List all records : Core

    This endpoint retrieves a list of all records of a selected Core object type from your Azure DevOps organization. Use this endpoint when you need to access organization-level data, such as all projects, teams, or other core objects.

    • Enter the name of your Azure DevOps organization in the Organization field. This is the organization name that appears in your Azure DevOps URL.
    • Select the type of Core object you want to retrieve from the Core Object dropdown menu. Available options include projects, teams, processes, and other core object types.
    • Enter the API version in the API Version field. This should be the Azure DevOps REST API version you want to use (e.g., 7.0, 7.1).
    • The endpoint uses GET requests to the Azure DevOps Core API endpoint (https://dev.azure.com/{organization}/_apis/{core_object}) with the specified API version query parameter.
    • The endpoint will return all records of the selected core object type. The response data is extracted from the value array in the API response ($.value[*]), with each record processed individually.

    This endpoint retrieves all records of the specified core object type at the organization level. The endpoint does not use pagination and returns all available records in a single request. The endpoint requires Basic Authentication with a Personal Access Token, which is handled automatically by your credential configuration. For detailed information about the Core API, including available core object types, API versions, and response formats, see the Azure DevOps Core API documentation.

Endpoint Testing​

Once the selected endpoint template has been configured, Nexla can retrieve a sample of the data that will be fetched according to the current settings. This allows users to verify that the source is configured correctly before saving.

  • To test the current endpoint configuration, click the Test button to the right of the endpoint selection menu. Sample data will be fetched & displayed in the Endpoint Test Result panel on the right.

  • If the sample data is not as expected, review the selected endpoint and associated settings, and make any necessary adjustments. Then, click the Test button again, and check the sample data to ensure that the correct information is displayed.

Configure Manually​

Azure DevOps data sources can be manually configured to ingest data from any valid Azure DevOps REST API endpoint. Manual configuration provides maximum flexibility for accessing endpoints not covered by pre-built templates or when you need custom API configurations.

With manual configuration, you can also create more complex Azure DevOps sources, such as sources that use chained API calls to fetch data from multiple endpoints or sources that require custom authentication headers or request parameters.

API Method​

  1. To manually configure this source, select the Advanced tab at the top of the configuration screen.

  2. Select the API method that will be used for calls to the Azure DevOps API from the Method pulldown menu. The Azure DevOps REST API primarily uses GET and POST requests. The most common methods are:

    • GET: For retrieving data from the API (most common for Azure DevOps)
    • POST: For creating resources or executing queries (e.g., WIQL queries)
    • PUT: For updating existing data
    • PATCH: For partial updates to existing data
    • DELETE: For removing data

API Endpoint URL​

  1. Enter the URL of the Azure DevOps REST API endpoint from which this source will fetch data in the Set API URL field. This should be the complete URL including the protocol (https://) and any required path parameters. Azure DevOps REST API endpoints follow the pattern https://dev.azure.com/{organization}/{project}/{team}/_apis/{api_path}?api-version={version} where {organization} is your organization name, {project} is your project name (optional for organization-level APIs), {team} is your team name (optional), {api_path} is the specific API path, and {version} is the API version.

Ensure the API endpoint URL is correct and accessible with your current credentials. Azure DevOps REST API endpoints require Basic Authentication with a Personal Access Token, which is handled automatically by your credential configuration. You can test the endpoint using the Test button after configuring the URL. For detailed information about Azure DevOps REST API endpoints, available APIs, and API versions, see the Azure DevOps REST API documentation.

Path to Data​

Optional

If only a subset of the data that will be returned by API endpoint is needed, you can designate the part(s) of the response that should be included in the Nexset(s) produced from this source by specifying the path to the relevant data within the response. This is particularly useful when API responses contain metadata, pagination information, or other data that you don't need for your analysis.

For example, when a request call is used to fetch a list of items, the API will typically return an array of records, along with metadata, in the response. By entering the path to the relevant data, you can configure Nexla to treat each element of the returned array as a record.

Path to Data is essential when API responses have nested structures. Without specifying the correct path, Nexla might not be able to properly parse and organize your data into usable records.

  • To specify which data should be treated as relevant in responses from this source, enter the path to the relevant data in the Set Path to Data in Response field.

    • For responses in JSON format enter the JSON path that points to the object or array that should be treated as relevant data. JSON paths use dot notation (e.g., $.value[*] to access an array of items within a response object).

    • For responses in XML format, enter the XPath that points to the object/array containing relevant data. XPath uses slash notation (e.g., /response/data/item to access item elements within a data element).

    Path to Data Example:

    If the API response is in JSON format and includes a top-level object with an array named value that contains the relevant data, the path to the response would be entered as $.value[*].

Autogenerate Path Suggestions​

Nexla can also autogenerate data path suggestions based on the response from the API endpoint. These suggested paths can be used as-is or modified to exactly suit your needs.

  • To use this feature, click the Test button next to the Set API URL field to fetch a sample response from the API endpoint. Suggested data paths generated based on the content & format of the response will be displayed in the Suggestions box below the Set Path to Data in Response field.

  • Click on a suggestion to automatically populate the Set Path to Data in Response field with the corresponding path. The populated path can be modified directly within the field if further customization is needed.

    PathSuggestions.png

Metadata​

If metadata is included in the response but is located outside of the defined path to relevant data, you can configure Nexla to include this data as common metadata in each record. This is useful when you want to preserve important contextual information that applies to all records but isn't part of the main data array.

For example, when a request call is used to fetch a list of items, the API response will typically include an array of records along with metadata such as total count, pagination information, or request timestamps. In this case, if you have specified the path to the relevant data but metadata of interest is located in a different part of the response, you can specify a path to this metadata to include it with each record in the generated Nexset(s).

Metadata paths are particularly useful for preserving API response context like request IDs, timestamps, or summary statistics that apply to all records in the response.

  • To specify the location of metadata that should be included with each record, enter the path to the relevant metadata in the Path to Metadata in Response field.

    • For responses in JSON format, enter the JSON path to the object or array that contains the metadata, and for responses in XML format, enter the XPath.

Request Headers​

Optional

  • If Nexla should include any additional request headers in API calls to this source, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (e.g., header1:value1,header2:value2). Additional headers are often required for API versioning, content type specifications, or custom authentication requirements.

    You do not need to include any headers already present in the credentials. Common headers like Authorization, Content-Type, and Accept are typically handled automatically by Nexla based on your credential configuration. Azure DevOps REST API requests require Basic Authentication with a Personal Access Token, which is handled automatically by your credential configuration.

Endpoint Testing​

After configuring all settings for the selected endpoint, Nexla can retrieve a sample of the data that will be fetched according to the current configuration. This allows users to verify that the source is configured correctly before saving.

  • To test the current endpoint configuration, click the Test button to the right of the endpoint selection menu. Sample data will be fetched & displayed in the Endpoint Test Result panel on the right.

  • If the sample data is not as expected, review the selected endpoint and associated settings, and make any necessary adjustments. Then, click the Test button again, and check the sample data to ensure that the correct information is displayed.

Save & Activate the Source​

  1. Once all of the relevant steps in the above sections have been completed, click the Create button in the upper right corner of the screen to save and create the new Azure DevOps data source. Nexla will now begin ingesting data from the configured endpoint and will organize any data that it finds into one or more Nexsets.