Skip to main content

Template registration

The Builder must be able to save all the infrastructure and use case template metadata in order to bind them to a specific policy.

The main idea is to register a template in two main cases:

  1. Every time a new use case template is registered;
  2. Every time a new infrastructure template is created;

Use Case Template registration​

In order to register a Use Case Template, you need to add it inside the Builder. The template must be registered in YAML format and needs to have the following fields, at least:

  1. useCaseTemplateId: is the main identifier of your use case template and must comply with the format urn:dmb:utm:${name}:${version}, e.g.: urn:dmb:utm:aws-cdp-outputport-impala-template:0.0.0
  2. name: is the name displayed in witboost UI.
  3. description: few words of what your template does.
  4. version: the version of the Use Case Template. It must match the same version specified in useCaseTemplateId
  5. infrastructureTemplateId: is the identifier of the infrastructure template that your use case template refers to. It must comply to format urn:dmb:itm:${name}:${version}, e.g.: urn:dmb:itm:aws-cdp-outputport-impala-provisioner:1
info

Remember: all URNs are treated as case-insensitive values, except for infrastructureTemplateId. This is deprecated, in the future it will be all case-insensitive.

These fields are all mandatory because they can discriminate an infrastructure template from a use case one. Please check createYourOwnTemplate.md file for further details about the required format for fields useCaseTemplateId, infrastructureTemplateId and version. If such requirements are not fulfilled, the registration procedure will output a validation error

Once a template is registered, periodically witboost update its metadata. So, you can change everything inside the YAML template (except for the useCaseTemplateId).

Infrastructure Template registration​

Infrastructure templates can be registered via UI (recommended) or API.

Infrastructure Templates (from now on "Tech Adapters") can be registered through the Administration > Extension Manager page. This section allows you to manage and extend the capabilities of your system by integrating technology-specific adapters and linking them with appropriate infrastructure templates.

To create a new Tech Adapter, click the "Add Tech Adapter" button. Extension Manager page

A Tech Adapter is a representation of a specific integration with a particular technology (e.g., AWS, Azure, Kubernetes). When creating a Tech Adapter, you can link it to a specific technology that it supports. All available technologies can be managed in the Technologies tab, where you can view, add, or edit technology definitions. Add Tech Adapter

After creating a Tech Adapter, click on the adapter name to enter its detail page. Here, you can associate different environments and their corresponding URLs by clicking on the "Register URL" button.

In this step, you’ll need to:

  • Select the environment (e.g., development, staging, production) where the infrastructure template will be deployed.

  • Specify the URL of the Tech Adapter that corresponds to the selected environment.

This mapping ensures that the system correctly routes integration requests to the appropriate endpoint based on the deployment environment.

Add Tech Adapter URL

Register an Infrastructure Template via API​

In order to register a Tech Adapter, you need to make an HTTP request to the Builder endpoint which is POST /register and for the request body, we need to specify some scenarios:

  • We register an infrastructure template with URLs.
  • We register an infrastructure template without URLs.

In the first case, we need to pass an object with the following fields:

  1. id: is the identifier of your infrastructure template, it must also contain the version, e.g. 'urn:dmb:itm:aws-cdp-outputport-impala-provisioner:1'.
  2. name: is the name chosen by the user to simplify its recognition.
  3. description: few words of what your template does.
  4. version: version of the infrastructure template.
  5. environment: the environment in which the infrastructure template is deployed.
  6. url: the url of the Tech Adapter related to a specific environment.

In the second case, we need to pass an object with the following fields:

  1. id: is the identifier of your infrastructure template, it must also contain the version, e.g. 'urn:dmb:itm:aws-cdp-outputport-impala-provisioner:1'.
  2. name: is the name chosen by the user to simplify its recognition.
  3. description: few words of what your template does.
  4. version: version of the infrastructure template.

Since the registration is performed by an API, it can also be called by a CI/CD.

In order to update the existing metadata of a specific infrastructure template, you just need to recall the same API with the same infrastructure template Id but with different values. For example:

There already is a registration for an infrastructure template with the following data:

id: 'urn:dmb:itm:aws-cdp-outputport-impala-provisioner:1'
name: 'Impala template'
description: 'This is a template for Impala'
version: 0.0.0
environment: 'dev'
url: 'https://impala-template.com'

But you noticed that there was a mistake in the technology used for this template and you want to update the name, the description and the URL, so you need to call /register API but with the following data:

id: 'urn:dmb:itm:aws-cdp-outputport-impala-provisioner:1'
name: 'CDP template'
description: 'This is a template for CDP'
version: 0.0.0
environment: 'dev'
url: 'https://cpd-template.com'

The API will notice that you are trying to update an existing infrastructure template and it will do it.