Azure Parameter Description
Parameter Name | DataType | Optional | Default | Description | Example/Values | Available since Version |
|---|---|---|---|---|---|---|
type | String | no | Definition of Content Service type. | azureblobstorev2 | ||
connectionstring | String | no | Azure Connection String. | DefaultEndpointsProtocol=https;AccountName=<azurename>;AccountKey=<tiacore/UA==>;EndpointSuffix=core.windows.net | 2.0.8 | |
container | String | no | Azure Container Name. | 2.0.8 | ||
contrepinpath | Boolean | yes | true | Root folder starts with Repository Syntax. | true/false | 2.0.8 |
cleanversions | Boolean | yes | true | true = deletes all previous versions for "UPDATE" and "DELETE" operations in buckets with versioning. false = all versions still persist. | true/false | 1.9.0 |
calculatestreamhash | Boolean | yes | true | After successful encryption, the hash values are recalculated. | true/false | 2.0.8 |
invalidcharacters | String | yes | This parameter can be used to define additional characters that require the name to be encoded for Azure. | <user>, z.B. \uFFFE\uFFF9\uFFF0 | 2.0.8 | |
region | String | yes | azure | Selection of the region for the creation of a new container. | azure, germany, us, china | 2.0.8 |
minparallelsize | Num | yes | 4194304 | Limit for upload in bytes for parallel upload with multiple threads. | 2.0.8 | |
maxconcurrency | Num | yes | 2 | Maximum amount of threads for parallel uploads. | 2.0.8 | |
blocksize | Num | yes | 4194304 | Blocksize in Bytes for parallel upload. | 2.0.8 | |
singleuploadsize | Num | yes | 4194304 | Chunk size for parallel upload in bytes. | 2.0.8 |
Configuration example Main examples
<Repo>.contentservice.azureblobstorev2.type = <Repo>.contentservice.azureblobstorev2.connectionstring = <Repo>.contentservice.azureblobstorev2.container = <Repo>.contentservice.azureblobstorev2.contrepinpath = true <Repo>.contentservice.azureblobstorev2.cleanversions = true <Repo>.contentservice.azureblobstorev2.calculatestreamhash = true <Repo>.contentservice.azureblobstorev2.invalidcharacters= <Repo>.contentservice.azureblobstorev2.region = azure <Repo>.contentservice.azureblobstorev2.minparallelsize = 4194304 <Repo>.contentservice.azureblobstorev2.maxconcurrency = 2 <Repo>.contentservice.azureblobstorev2.blocksize = 4194304 <Repo>.contentservice.azureblobstorev2.singleuploadsize = 4194304
Azure Versioning Blob Container
The Azure configuration described below (versioned blob container) supports object individual retention as well as legal hold functionality.
To use this feature, it is necessary to create a container with the "version-level immutability" option. See: https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-policy-configure-version-scope?tabs=azure-portal
This can be enabled in the Azure StorageAccount in a manually creation process of a container or via a corresponding configuration in tia Core, which is described below.
If the container creation is to be done by tia core, the following parameters must be added to the repository.cfg.
Parameter Name | DataType | Optional | Default | Description | Example/Values | Available since Version |
|---|---|---|---|---|---|---|
allowcreatecontainer | Boolean | yes | false | If the container does not exist, it will be created by the application. | true/false | 2.0.8 |
enableversioning | Boolean | yes | true | If the application (tia Core) is authorized to create containers and this parameter is additional enabled, the property "Enable ImmutableVersioning" is set. The following customizing is mandatory for this > https://kgs-software.atlassian.net/wiki/spaces/WIKI/pages/1665826820/Azure#%5BinlineExtension%5DAzure-mit-versionierten-Blobs | true/false | 2.0.8 |
management.clientId | String | yes | Azure credentials to automatically create containers with the "Enable ImmutableVersioning" setting enabled.https://github.com/IBM/IBMDeveloper-recipes/blob/main/how-to-procure-tenant-id-client-id-and-client-secret-key-to-connect-to-microsoft-azure-data-lake-storage-gen2/index.md | 2.0.8 | ||
management.clientSecret | String | yes | 2.0.8 | |||
management.tentantId | String | yes | 2.0.8 | |||
management.subcriptionId | String | yes | 2.0.8 | |||
management.resourceGroupName | String | yes | 2.0.8 | |||
management.accountName | String | yes | 2.0.8 |
Configuration example immutability policies
<Repo>.contentservice.azureblobstorev2.allowcreatecontainer=false <Repo>.contentservice.azureblobstorev2.enableversioning=true <Repo>.contentservice.azureblobstorev2.management.tenantId= <Repo>.contentservice.azureblobstorev2.management.clientSecret= <Repo>.contentservice.azureblobstorev2.management.clientId= <Repo>.contentservice.azureblobstorev2.management.subcriptionId= <Repo>.contentservice.azureblobstorev2.management.resourceGroupName= <Repo>.contentservice.azureblobstorev2.management.accountName=
Access is allowed by Access Keys or Shared Access Signature Keys. It is important that tia core can access Object and the container itself. More permissions are required when tia core should create containers.
To be aware of the limits e.g. for memory and data throughput per storage account, the following article is recommended: https://learn.microsoft.com/en-us/azure/storage/common/scalability-targets-standard-account?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.json
Container naming convention:
Container naming
A container name must be a valid DNS name and comply with the following naming rules:
Container names must begin or end with a letter or number and may contain only letters, numbers, and hyphens (-).
Each hyphen (-) must be immediately preceded and followed by a letter or number; in addition, multiple hyphens may not directly follow each other.
The container name must contain lowercase letters only.
Container names must be between 3 and 63 characters long.
Quelle: https://docs.microsoft.com/de-de/rest/api/storageservices/naming-and-referencing-containers--blobs--and-metadata / https://learn.microsoft.com/en-us/rest/api/storageservices/naming-and-referencing-containers--blobs--and-metadata