Skip to main content

Tech Adapters

Tech Adapters (formerly known as Specific Provisioners or Infrastructure Templates), are microservices responsible for the validation and provisioning of components.

When the platform team wants to support a new technology, a new Tech Adapter microservice compliant with the Technology Adapter API must be created and registered. When a Data Product is successfully deployed all of its metadata (contained in its descriptor) are sent to the Marketplace, and are then available to all consumers; in the following section, we specify how additional fields returned by the Technology Adapter's result can be shown in the marketplace UI pages.

Technology Adapter API details​

The Provisioning Status returned by the provisioning methods of the Specific Provisioners contains a "free" field, where the Technology Adapter implementer can add additional details (like URLs, descriptions, etc). The structure of the status returned is similar to:

{
    "status": "RUNNING" | "COMPLETED" | "FAILED",
    "info": {
        "publicInfo": {},
        "privateInfo": {}
    }
}
warning

ATTENTION: WE SUGGEST TO PUT THE FIELD NAMES INSIDE publicInfo and privateInfo IN CAMEL OR SNAKE CASE. EVERY OTHER SEPARATOR WILL BE REPLACED WITH UNDERSCORES.

As you can see the info is a field that can contain different public and private details. Only details in the publicInfo object will be displayed to consumers in the Marketplace, while all the values put in the privateInfo will be stored in the deployed descriptor, but will not be shown in the Marketplace UI.

There is no limit to how many values can be set in those fields, but only the ones compliant with the following specification will be rendered in the "Technical Information" card of the Marketplace module. Invalid data is ignored and if there is no valid data to be shown, the "Technical Information" card will not be displayed.

The info must be an object that contains 2 objects: publicInfo and privateInfo. These objects can contain other objects, one for each field you want to represent. As already explained, only the valid ones from the publicInfo object will be displayed. Each object is related to a specific key of the publicInfo object and must contain the following fields: type, label and value. An optional href field is also supported for links. The values currently supported for the type field are string and date.

The following examples show how to write the field objects for each supported type:

String​

To show in the UI a string field with the label "MyString" and value "MyValue", just return the following "deployInfo" object:

{
    ...
    "info": {
        "publicInfo": {
            "aString": {
                "type": "string",
                "label": "MyString",
                "value": "MyValue"
            }
        },
        "privateInfo": {}
    }
}

To show in the UI an anchor field with the label "MyLink" and value "MyValue" that once clicked forwards the user to "http://my.remote.url", just return the following "deployInfo" object:

{
    ...
    "info": {
        "publicInfo": {
            "aLink": {
                "type": "string",
                "label": "MyLink",
                "value": "MyValue",
                "href": "http://my.remote.url"
            }
        },
        "privateInfo": {}
    }
}

As you can see, there is no need to specify a different type, since the clickable link rendering depends on the presence of the optional href field.

Date​

To show in the UI a date field with the label "MyDate", just return the following "deployInfo" object:

{
    ...
    "info": {
        "publicInfo": {
            "aDate": {
                "type": "date",
                "label": "MyDate",
                "value": "2011-12-03T10:15:30Z" // ISO UTC INSTANT
            }
        },
        "privateInfo": {}
    }
}

The value must be in ISO UTC instant format: yyyy-MM-ddThh:mm:ssZ.