Feature Request: Externalize start-up configuration for DSC in order to automatically connect to broker/other dsc/clearing house ect..

[stb1337]

As an dev ops engineer, I would like to have have an externalized configuration which can be overwritten during start up of the dsc docker container.

Within this externalized configuration it should be a able to pre-register:

• onboarding of source resources
• connecting to another dsc to exchange identifies/connector descriptions in order to exchange data after startup
• connecting to an broker after startup
• connecting to an clearing house after startup

The most important feature would be the first two points.

It would be very nice to be able to execute every OpenAPI interface after startup of the DSC just by providing environment variables during startup of the container.

This features are very important to be enabled for mass automatically deployment of DSC into cloud infrastructure without any manual post-configuration or create an own docker container/mechanism to interface with the OpenAPI.

Feel free to contact me anytime regarding this via my business address. (steffen.brunner01ÄTsapDÖTcom)

[seebi]

Question: Is the Policy Description part of the "onboarding of source resources"?

[seebi]

Same Question: Data Offers can be configured via source resources or is this separate

[ghost]

The onboarding process allows to register IDS catalog entities within the connector.

The (simplified) structure a DSC catalogs can be found in this tree:

catalog
└── offeredResources
     ├── resource
     │   ├── representations
     │   │   ├── representation
     │   │   │   └── artifacts
     │   │   │       ├── artifact
     │   │   │       └── ...
     │   │   └── ...
     │   └── contracts
     │       ├── contract
     │       │   └── contractRules
     │       │       ├── contractRule
     │       │       └── ...
     │       └── ...
     └── ...

[sebplorenz]

Talking about "onboarding of source resources", please provide an option to create a resource with a predefined UUID in DSC version 5. This was possible with version 4 of the DSC. Using setup scripts I was able to provision an initial resource configuration including resource UUIDs for a data provider DSC version 4. With the new API v5, a resource (created with POST /api/offers) is given an arbitrary UUID by the connector. But this is a problem if (for whatever reason) the database is lost. In this case there is no option to recreate the resource with the same uuid. And since the UUID of a resource is communicated to the outside as a permanent link all clients have to refetch the resource and recreate the contracts.

[ghost]

Talking about "onboarding of source resources", please provide an option to create a resource with a predefined UUID in DSC version 5. This was possible with version 4 of the DSC. Using setup scripts I was able to provision an initial resource configuration including resource UUIDs for a data provider DSC version 4. With the new API v5, a resource (created with POST /api/offers) is given an arbitrary UUID by the connector. But this is a problem if (for whatever reason) the database is lost. In this case there is no option to recreate the resource with the same uuid. And since the UUID of a resource is communicated to the outside as a permanent link all clients have to refetch the resource and recreate the contracts.

The assignment of predefined UUIDs to resources that are registered during bootstrapping is not supported. The Connector has sovereignty over the assignment of UUIDs and if this was changed, the user would have the obligation to ensure that all UUIDs are truly unique. To prevent the loss of the database, backups can be used.