Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Découvrez comment créer des types de données définis par l’utilisateur(-trice) dans Bicep. Pour connaître les types de données définis par le système, consultez Types de données. L’utilisation des types de données définis par l’utilisateur permet d’activer automatiquement la génération de code dans la version 2.0 du langage de programmation.
Bicep CLI version 0.12.X ou ultérieure est nécessaire pour utiliser cette fonctionnalité.
La règle linter use-user-defined-types encourage l’utilisation de types de données définis par l’utilisateur au lieu des types génériques object ou array types.
Définir des types
Utilisez l’instruction pour créer des types de données définis par l’utilisateur type . Vous pouvez également utiliser des expressions de type à certains lieux pour définir des types personnalisés.
@<decorator>(<argument>)
type <user-defined-data-type-name> = <type-expression>
L’élément décoratif @allowed n’est autorisé que sur les instructions param. Pour déclarer un type avec un ensemble de valeurs prédéfinies dans une type, utilisez la syntaxe de type union.
Les expressions de type valides sont les suivantes :
Références symboliques
Les références symboliques sont des identificateurs qui font référence à un type ambiant (comme string ou int) ou à un symbole de type défini par l’utilisateur déclaré dans une type instruction.
// Bicep data type reference
type myStringType = string
// user-defined type reference
type myOtherStringType = myStringType
Littéraux primitifs
Les littéraux primitifs, dont les chaînes, les entiers et les booléens, sont des expressions type valides. Exemple :
// a string type with three allowed values.
type myStringLiteralType = 'bicep' | 'arm' | 'azure'
// an integer type with one allowed value
type myIntLiteralType = 10
// an boolean type with one allowed value
type myBoolLiteralType = true
Types de tableau
Vous pouvez déclarer des types de tableaux en ajoutant [] à n’importe quelle expression de type valide. Exemple :
// A string type array
type myStrStringsType1 = string[]
// A string type array with three allowed values
type myStrStringsType2 = ('a' | 'b' | 'c')[]
type myIntArrayOfArraysType = int[][]
// A mixed-type array with four allowed values
type myMixedTypeArrayType = ('fizz' | 42 | {an: 'object'} | null)[]
Types d’union
Un type union vous permet de créer un type combiné constitué d’un ensemble de sous-types. Une valeur correspond au type s’il correspond à l’un des sous-types. Utilisez l’opérateur pipe (|) pour séparer les différents types de membres. Bicep convertit les types d'union en contraintes de valeurs autorisées ; par conséquent, seuls les littéraux sont autorisés en tant que membres. Les unions peuvent comporter n’importe quel nombre d’expressions type littérales.
type directions = 'east' | 'south' | 'west' | 'north'
type obj = {
level: 'bronze' | 'silver' | 'gold'
}
Vous pouvez déclarer des types d’union en ligne, et un membre peut être une référence à un autre symbole de type littéral.
Unions de type mixte
Les types de membres n’ont pas besoin d’être le même type de littéral. Une union peut combiner des littéraux de type chaîne de caractères, entier, booléen, objet et null.
type mixedType = 'fizz' | 42 | { an: 'object' } | null
Note
L’opérateur | est également utilisé dans plusieurs scénarios connexes documentés ailleurs dans cet article :
- Pour créer un tableau dont les éléments sont contraints aux membres de l’union, consultez les types de tableau.
- Pour associer l’opérateur
|au décorateur@discriminator()et créer une union discriminée, consultez le type de données « union étiquetée ». - Lorsque vous utilisez des types dérivés de ressources, leurs équivalents étendus sont exprimés sous forme d’unions.
Types d’objets
Les types d’objets contiennent zéro ou plusieurs propriétés entre crochets bouclés :
type storageAccountConfigType = {
name: string
sku: string
}
Chaque propriété d’un objet est constituée d’une clé et d’une valeur séparées par deux points :. La clé peut être n’importe quelle chaîne et les valeurs non identifiantes sont placées entre guillemets. La valeur peut être n’importe quel type d’expression.
Les propriétés sont requises, sauf si elles ont un marqueur d'option ? après la valeur de propriété. Par exemple, la propriété sku dans l’exemple suivant est facultative :
type storageAccountConfigType = {
name: string
sku: string?
}
Vous pouvez utiliser des éléments décoratifs sur des propriétés. Vous pouvez utiliser un astérisque (*) pour que toutes les valeurs soient soumises à une contrainte. Vous pouvez définir plus de propriétés à l’aide de *. Cet exemple crée un objet qui nécessite une clé de type int appelée id. Toutes les autres entrées de l’objet doivent être des valeurs de chaînes contenant au moins 10 caractères.
type obj = {
@description('The object ID')
id: int
@description('Additional properties')
@minLength(10)
*: string
}
L’exemple suivant montre comment utiliser la syntaxe de type union pour répertorier un ensemble de valeurs prédéfinies :
type directions = 'east' | 'south' | 'west' | 'north'
type obj = {
level: 'bronze' | 'silver' | 'gold'
}
Récursivité
Les types d’objets peuvent utiliser la récursivité directe ou indirecte si au moins une étape du chemin d’accès au point de récursivité est facultative. Par exemple, la définition myObjectType dans l’exemple suivant est valide, car la propriété directement récursive recursiveProp est facultative :
type myObjectType = {
stringProp: string
recursiveProp: myObjectType?
}
La définition de type suivante n’est pas valide, car aucune de level1, level2, level3, level4ou level5 n’est facultative.
type invalidRecursiveObjectType = {
level1: {
level2: {
level3: {
level4: {
level5: invalidRecursiveObjectType
}
}
}
}
}
Opérateurs unaires
Utilisez les opérateurs unaires Bicep avec des littéraux entiers et booléens ou des références à des symboles de type littéral entier ou booléen.
type negativeIntLiteral = -10
type negatedIntReference = -negativeIntLiteral
type negatedBoolLiteral = !true
type negatedBoolReference = !negatedBoolLiteral
Les unions peuvent comporter n’importe quel nombre d’expressions type littérales. Bicep traduit les types d’union en contrainte de valeur autorisée. Seuls les littéraux sont donc autorisés en tant que membres.
type oneOfSeveralObjects = {
foo: 'bar'
} | {
fizz: 'buzz'
} | {
snap: 'crackle'
}
type mixedTypeArray = ('fizz' | 42 | {an: 'object'} | null)[]
Utilisez des expressions de type dans l’instruction type . Vous pouvez également utiliser des expressions de type pour créer des types de données définis par l’utilisateur, comme indiqué dans les emplacements suivants.
Comme clause type d’une
paraminstruction. Exemple :param storageAccountConfig { name: string sku: string }Suivant le
:dans une propriété type d’objet. Exemple :param storageAccountConfig { name: string properties: { sku: string } } = { name: 'store$(uniqueString(resourceGroup().id)))' properties: { sku: 'Standard_LRS' } }Précédant le
[]dans une expression type tableau. Exemple :param mixedTypeArray ('fizz' | 42 | {an: 'object'} | null)[]
Un fichier Bicep classique pour la création d’un compte de stockage ressemble à ceci :
param location string = resourceGroup().location
param storageAccountName string
@allowed([
'Standard_LRS'
'Standard_GRS'
])
param storageAccountSKU string = 'Standard_LRS'
resource storageAccount 'Microsoft.Storage/storageAccounts@2025-06-01' = {
name: storageAccountName
location: location
sku: {
name: storageAccountSKU
}
kind: 'StorageV2'
}
Les types de données définis par l’utilisateur peuvent ressembler à ce qui suit :
param location string = resourceGroup().location
type storageAccountSkuType = 'Standard_LRS' | 'Standard_GRS'
type storageAccountConfigType = {
name: string
sku: storageAccountSkuType
}
param storageAccountConfig storageAccountConfigType
resource storageAccount 'Microsoft.Storage/storageAccounts@2025-06-01' = {
name: storageAccountConfig.name
location: location
sku: {
name: storageAccountConfig.sku
}
kind: 'StorageV2'
}
Utiliser des éléments décoratifs
Écrivez des décorateurs au format @expression et placez-les au-dessus des déclarations du type de données défini par l’utilisateur. Le tableau suivant présente les éléments décoratifs disponibles pour les types de données définis par l’utilisateur.
| Élément décoratif | S’applique à | Raisonnement | Descriptif |
|---|---|---|---|
| description | all | ficelle | Fournissez des descriptions pour le type de données défini par l’utilisateur. |
| discriminant | objet | ficelle | Utilisez cet élément décoratif pour vous assurer que la sous-classe appropriée est identifiée et gérée. |
| export | all | Aucun | Indique que le type de données défini par l’utilisateur est disponible pour l’importation par un autre fichier Bicep. |
| maxLength | tableau, chaîne | int | La longueur maximale pour les types de données de chaîne et de tableau. La valeur est inclusive. |
| maxValue | int | int | La valeur maximale pour les types de données entiers. Cette valeur est inclusive. |
| métadonnées | all | objet | La propriétés personnalisées à appliquer aux types de données. Ils peuvent inclure une propriété de description équivalente à l’élément décoratif de description. |
| minLength | tableau, chaîne | int | La longueur minimale pour les types de données de chaîne et de tableau. La valeur est inclusive. |
| minValue | int | int | La valeur minimale pour les types de données entiers. Cette valeur est inclusive. |
| scellé | objet | Aucun | Faire passer BCP089 d’un avertissement à une erreur lorsque le nom d’une propriété d’un type de données défini par l’utilisateur est probablement une faute de frappe. Pour plus d’informations, consultez Élever le niveau d’erreur. |
| sûr | string, objet | Aucun | Marque les types comme sécurisés. La valeur d’un type sécurisé n’est pas enregistrée dans l’historique de déploiement et n’est pas journalisée. Pour plus d’informations, consultez Sécuriser les chaînes et les objets. |
Les éléments décoratifs se trouvent dans l’espace de noms sys. Si vous devez différencier un élément décoratif d'un autre élément portant le même nom, faites précéder l’élément décoratif de sys. Par exemple, si votre fichier Bicep comprend une variable appelée description, vous devez ajouter l’espace de noms sys lorsque vous utilisez l’élément décoratif description.
Discriminant
Consultez Type de données d’union étiquetée.
Descriptif
Ajoutez une description au type de données défini par l’utilisateur. Vous pouvez utiliser des éléments décoratifs sur des propriétés. Exemple :
@description('Define a new object type.')
type obj = {
@description('The object ID')
id: int
@description('Additional properties')
@minLength(10)
*: string
}
Vous pouvez utiliser le texte mis en forme Markdown pour le texte de description.
Exporter
Utilisez @export() pour partager le type de données défini par l’utilisateur avec d’autres fichiers Bicep. Pour plus d’informations, consultez Exporter des variables, des types et des fonctions.
Contraintes d’entier
Définissez les valeurs minimales et maximales pour le type entier. Vous pouvez définir une contrainte ou les deux.
@minValue(1)
@maxValue(12)
type month int
Contraintes de longueur
Spécifiez des longueurs minimales et maximales pour les types de chaîne et de tableau. Vous pouvez définir une contrainte ou les deux. Pour les chaînes, la longueur indique le nombre de caractères. Pour les tableaux, la longueur indique le nombre d’éléments dans le tableau.
L’exemple suivant présente deux types. Un type destiné à un nom de compte de stockage qui doit compter 3 à 24 caractères. Un autre type est un tableau qui doit comprendre1 à 5 éléments.
@minLength(3)
@maxLength(24)
type storageAccountName string
@minLength(1)
@maxLength(5)
type appNames array
Métadonnées
Si vous avez des propriétés personnalisées que vous souhaitez appliquer à un type de données défini par l’utilisateur, ajoutez un élément décoratif de métadonnées. Dans les métadonnées, définissez un objet avec des noms et valeurs personnalisés. L’objet que vous définissez pour les métadonnées peut contenir des propriétés de n’importe quel nom et type.
Utilisez ce décorateur pour consigner des informations sur le type de données qu’il n’est pas pertinent d’ajouter dans la description.
@description('Configuration values that are applied when the application starts.')
@metadata({
source: 'database'
contact: 'Web team'
})
type settings object
Lorsque vous fournissez un décorateur @metadata() avec une propriété en conflit avec un autre décorateur, la propriété conflictuelle dans la valeur @metadata() est redondante et est remplacée. Pour plus d’informations, consultez Aucune métadonnée en conflit.
Scellé
Consultez Élever le niveau d’erreur.
Types sécurisés
Vous pouvez marquer une chaîne ou un type de données défini par l’utilisateur comme étant sécurisé. La valeur d’un type sécurisé n’est pas enregistrée dans l’historique de déploiement et n’est pas journalisée.
@secure()
type demoPassword string
@secure()
type demoSecretObject object
Élever le niveau d’erreur
Par défaut, la déclaration d’un type d’objet dans Bicep lui permet d’accepter d’autres propriétés de n’importe quel type. Par exemple, le Bicep suivant est valide, mais déclenche un avertissement de [BCP089] : The property "otionalProperty" is not allowed on objects of type "{ property: string, optionalProperty: null | string }". Did you mean "optionalProperty"? :
type anObject = {
property: string
optionalProperty: string?
}
param aParameter anObject = {
property: 'value'
otionalProperty: 'value'
}
L’avertissement vous informe que le type anObject n’inclut pas de propriété appelée otionalProperty. Bien qu’aucune erreur ne se produise lors du déploiement, le compilateur Bicep suppose que otionalProperty est une faute de frappe et que vous aviez l’intention d’utiliser optionalProperty, mais que vous l’avez mal orthographié. Bicep vous alerte en cas d’incohérence.
Pour réaffecter ces avertissements aux erreurs, appliquez le décorateur @sealed() au type d’objet :
@sealed()
type anObject = {
property: string
optionalProperty?: string
}
Vous obtenez les mêmes résultats en appliquant le décorateur @sealed() à la déclaration param :
type anObject = {
property: string
optionalProperty: string?
}
@sealed()
param aParameter anObject = {
property: 'value'
otionalProperty: 'value'
}
Le moteur de déploiement Azure Resource Manager vérifie également les types sealed pour d’autres propriétés. La fourniture de propriétés supplémentaires pour les paramètres sealed entraîne une erreur de validation qui entraîne l’échec du déploiement. Exemple :
@sealed()
type anObject = {
property: string
}
param aParameter anObject = {
property: 'value'
optionalProperty: 'value'
}
Type de données union étiqueté
Pour déclarer un type de données d’union étiqueté personnalisé dans un fichier Bicep, vous pouvez placer un élément décoratif discriminator au-dessus d’une déclaration de type défini par l’utilisateur.
Bicep CLI version 0.21.X ou ultérieure est nécessaire pour utiliser cet élément décoratif. L’exemple suivant montre comment déclarer un type de données union étiqueté :
type FooConfig = {
type: 'foo'
value: int
}
type BarConfig = {
type: 'bar'
value: bool
}
@discriminator('type')
type ServiceConfig = FooConfig | BarConfig | { type: 'baz', *: string }
param serviceConfig ServiceConfig = { type: 'bar', value: true }
output config object = serviceConfig
Pour plus d’informations, consultez Type de données union étiqueté personnalisé.
Types dérivés de ressources
Bicep vous permet de dériver des types directement à partir des schémas de ressources Azure à l’aide des constructions resourceInput<> et resourceOutput<>. En utilisant des types dérivés de ressources, vous pouvez vérifier les paramètres et les variables par rapport à une partie d’un corps de ressource au lieu d’utiliser un type personnalisé. Pour utiliser ces constructions, vous devez Bicep CLI version 0.34.1 ou ultérieure.
Les modèles peuvent réutiliser les types de ressources où qu’un type soit attendu.
resourceInput<'type@version'>
-
resourceInput<>: représente les propriétés accessibles en écriture d’un type de ressource, en supprimant toutes les propriétés marquées comme ReadOnly dans le schéma du modèle ARM. Il utilise le type que vous devez fournir à la déclaration de la ressource.
resourceOutput<'type@version'>
-
resourceOutput<>: représente les propriétés lisibles d’un type de ressource, en supprimant toutes les propriétés marquées comme WriteOnly dans le schéma de modèle ARM. Il correspond au type de valeur retourné après l’approvisionnement de la ressource.
Vous pouvez appliquer resourceInput<> ou resourceOutput<> extraire uniquement une partie d’un schéma de ressource. Par exemple, pour taper une variable ou un paramètre en fonction uniquement du kind ou properties d’un compte de stockage :
type accountKind = resourceInput<'Microsoft.Storage/storageAccounts@2024-01-01'>.kind
L’exemple précédent équivaut à :
type accountKind = 'BlobStorage' | 'BlockBlobStorage' | 'FileStorage' | 'Storage' | 'StorageV2'
L’exemple suivant montre comment utiliser resourceInput<> pour créer un paramètre typé en fonction de la properties ressource d’un compte de stockage. Cette approche définit un paramètre qui correspond aux propriétés accessibles en écriture d’un compte de stockage, tels que accessTier, minimumTlsVersionet d’autres propriétés :
// Typed parameter using the .properties path of a storage account
param storageAccountProps resourceInput<'Microsoft.Storage/storageAccounts@2023-01-01'>.properties = {
accessTier: 'Hot'
minimumTlsVersion: 'TLS1_2'
allowBlobPublicAccess: false
supportsHttpsTrafficOnly: true
}
// Resource declaration using the typed parameter
resource storageAccount 'Microsoft.Storage/storageAccounts@2025-06-01' = {
name: 'mystorageacct123'
location: resourceGroup().location
sku: {
name: 'Standard_LRS'
}
kind: 'StorageV2'
properties: storageAccountProps
}
L’exemple suivant montre comment utiliser resourceOutput<> pour créer une sortie typée basée sur la ressource primaryEndPoints d’un compte de stockage.
output storageEndpoints resourceOutput<'Microsoft.Storage/storageAccounts@2024-01-01'>.properties.primaryEndpoints = ...
Contrairement aux types de données définis par l'utilisateur, Bicep vérifie les types dérivés des ressources lorsque vous modifiez ou compilez un fichier, mais le service ARM ne les vérifie pas.
Contenu connexe
Pour une liste des types de dates Bicep, consultez Types de données.