# Retrieve Component BSIDs

Few DevOps mechanisms are available to streamline the work with Sealights' Integration Builds.

## Pulling the BSID dynamically from the component <a href="#pulling-the-bsid-dynamically-from-the-component" id="pulling-the-bsid-dynamically-from-the-component"></a>

When creating the Integration Build, you’ll query one by one the components deployed in the relevant (and common Testing Lab) to retrieve their BSID.

{% hint style="info" %}
This option is commonly used when working with containers and orchestration.
{% endhint %}

### Java built with Sealights plugins. <a href="#java-built-with-sealights-plugins" id="java-built-with-sealights-plugins"></a>

Sealights Maven and Gradle plugins allow to include resource text files to the artefact.

You can extract the `buildSessionId.txt` file from the Java artefact by using the following command:

{% code overflow="wrap" lineNumbers="true" %}
```
java xvf myapp.jar buildSessionId.txt
```
{% endcode %}

### Node/Javascript <a href="#node-javascript" id="node-javascript"></a>

You can extract the Build Session ID of your JS component from the instrumented files using the regular grep command:

{% code overflow="wrap" lineNumbers="true" %}
```
cat main.js | grep buildSessionId
```
{% endcode %}

The output is `"buildSessionId": "89b2477d-fed3-400d-b63f-f1ba133f5080",`

{% hint style="info" %}
Another solution is to copy the `buildSessionId` file into the instrumented folder when packaging it and read the content of this file to retrieve the unique ID when needed.\
This solution is often prefered when the application’s JS files are big.
{% endhint %}

## Storing the BSIDs of the components in a central place <a href="#storing-the-bsids-of-the-components-in-a-central-place" id="storing-the-bsids-of-the-components-in-a-central-place"></a>

A second common solution is to store the buildSessionID of every component in a central place (database, folder component-specific,…) and create the Integration Build from these IDs.

For example, you can use a dedicated Variable Group in AzureDevOps Library section like in the image below:

<figure><img src="https://4057366433-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAjqTCMRYvHhDgsdPLUnc%2Fuploads%2F68xDW8WvOoNmMC8WJd7W%2Fimage-20211020-085518.png?alt=media&#x26;token=1f55570b-e85b-4540-ab32-f03770216c8a" alt=""><figcaption></figcaption></figure>

&#x20;

## Using Sealights' Public API <a href="#using-sealights-public-api" id="using-sealights-public-api"></a>

### Resolving dynamically the components' details  <a href="#resolving-dynamically-the-components-details" id="resolving-dynamically-the-components-details"></a>

A third common solution is to use Sealights Public APIs to programmatically retrieve the BSID of every component using specific criteria (the last build, a specific build from a certain date, build matching a certain naming convention…).

Please refer to the Sealights API Reference page for more details, specifically about entry points like:

* `/sl-api/v1/slim-builds` (_Get Builds API_)
* or `/sl-api/v1/slim-builds/resolve` (_Resolve Builds API_).

### Capturing the list of all active agents from a specific environment <a href="#capturing-the-list-of-all-active-agents-from-a-specific-environment" id="capturing-the-list-of-all-active-agents-from-a-specific-environment"></a>

Another solution is to take a snapshot of your environment by capturing all the agents up and running from that specific environment at the creation of your Integration Build.\
This last solution relies on several technical assumptions and is a good starting point but not recommended as a persistent solution.

More details are shared in our dedicated documentation page:[#using-the-list-of-agents-currently-active-in-a-specific-environment](../json-file-listing-components#using-the-list-of-agents-currently-active-in-a-specific-environment "mention")
