Facturation limitée pour les conteneurs Azure à l’aide du service de contrôle de la Place de marché commerciale

Article
06/14/2024

Avec le service de contrôle de la Place de marché commerciale, vous pouvez créer des offres Azure Container facturées en fonction d’unités non standard. Avant de publier l’offre sur la Place de marché commerciale, vous définissez les dimensions de facturation telles que la bande passante, les partitions, les fichiers journaux, les analyses, les e-mails traités, etc. Les clients paient ensuite en fonction de leur consommation de ces dimensions, avec votre application informant Microsoft via l’API de service de contrôle de la place de marché commerciale des événements facturables au fur et à mesure qu’elles se produisent.

Prérequis pour la facturation à la consommation

Pour qu’une offre De conteneur Azure utilise la facturation limitée, vous devez d’abord passer en revue les options de licence décrites dans Plan pour l’offre conteneur Azure et vous assurer que vous avez des besoins de facturation personnalisés qui ne sont pas satisfaits par l’un des six modèles de facturation prédéfinis existants.

L’offre Azure Container peut ensuite s’intégrer aux API de service de contrôle de la Place de marché commerciale pour informer Microsoft des événements facturables.

Important

Votre application devra appeler les API de service de contrôle de la Place de marché commerciale. Actuellement, il n’existe pas d’option permettant à votre service hébergé (en dehors de l’application) d’appeler l’API du service de contrôle.

Remarque

Le service de contrôle de la Place de marché est disponible uniquement pour le modèle de facturation personnalisé et ne s’applique pas au modèle de facturation par utilisateur.

Comment la facturation à la consommation s’adapte à la tarification

Comprendre la hiérarchie d’offres est importante quand il s’agit de définir l’offre avec ses modèles tarifaires.

Chaque offre est configurée pour vendre via Microsoft ou non. Une fois qu’une offre est publiée, cette option ne peut pas être modifiée.
Chaque offre, configurée pour vendre via Microsoft, peut avoir un ou plusieurs plans.
Chaque plan a un modèle de tarification associé à celui-ci : plan facturé mensuel basé sur l’utilisation ou ByOL (Apportez votre propre licence). Pour le plan de facturation mensuel basé sur l’utilisation, vous pouvez choisir gratuitement, l’une des six options de facturation prédéfinies ou personnalisées.
Le modèle de tarification et les options d’entrée de prix ne peuvent pas être mis à jour une fois publiés.
Chaque plan doit avoir un plan tarifaire complet.
Vous pouvez choisir de prix à l’aide de dimensions personnalisées pour facturer vos clients afin de répondre à vos besoins de facturation. Chaque dimension représente une unité facturable que votre service communique à Microsoft à l’aide de l’API de service de contrôle de la Place de marché commerciale.

Important

Vous devez suivre l’utilisation dans votre code et envoyer uniquement des événements d’utilisation à Microsoft pour l’utilisation que vous souhaitez que le client facture.

Remarque

Les offres sont facturées aux clients dans la devise du contrat client, en utilisant le prix du marché local qui a été publié au moment de la création de l’offre. Le montant payé par les clients et reçu par les éditeurs de logiciels indépendants dépend des taux de change au moment où le client effectue la transaction pour l’offre. En savoir plus sur la Procédure de conversion des devises.

Exemples d’options de tarification personnalisées

Par exemple, Contoso est un éditeur dont l’adresse IP se trouve dans sa logique de partitionnement pour son application Kubernetes. Contoso souhaite facturer ses clients en fonction du nombre de partitions utilisées. Ils explorent également d’autres options de facturation à prix compétitif et pratique. Contoso est inscrit en tant qu’éditeur dans l’Espace partenaires pour le programme de la Place de marché commerciale et souhaite publier des offres conteneur auprès des clients Azure. Il existe quatre plans associés à Contoso, décrits ci-dessous :

Frais par partitions utilisées par heure, par exemple, 1 000 $/shard/hour
Modélisation d’un paiement unique ou d’une facturation périodique : Supposons que Contoso souhaite facturer à un client 449 $ /mo pour l’utilisation de jusqu’à 100 fichiers journaux à partir de son application. La logique d’application de Contoso effectue le suivi de l’événement d’utilisation pour le mois et déclenche un frais à la fin du mois pour l’utilisation des 100 fichiers journaux.
Modélisation de la facturation hiérarchisé : Supposons que Contoso souhaite facturer 449 $ /mo pour jusqu’à 100 partitions, puis hiérarchiser les tarifs pour tout dépassement. Leur logique d’application effectuerait le suivi de l’utilisation pour le mois, segmentez l’utilisation en conséquence et signalez-la à l’aide des API de contrôle ci-dessous à la fin de la période :
Facturation multidimensionnelle : Contoso peut également utiliser le contrôle personnalisé pour répondre à ses besoins en matière de facturation avancée à l’aide de plusieurs dimensions

En fonction du plan sélectionné, un client Azure obtenant l’offre de conteneur Contoso est facturé en fonction de son utilisation. Contoso compte l’utilisation sans envoyer d’événements d’utilisation à Microsoft. Soit lorsque les clients consomment une quantité adéquate, soit périodiquement, Contoso signale l’utilisation. Les clients n’ont pas à modifier les plans ni à faire quoi que ce soit différent. Contoso mesure l’utilisation et commence à émettre des événements d’utilisation à Microsoft pour facturer l’utilisation de dépassement à l’aide de l’API de service de contrôle de la Place de marché commerciale. Microsoft facture à son tour au client l’utilisation spécifiée par l’éditeur dans les dimensions personnalisées. La facturation est effectuée au prochain cycle de facturation mensuel.

Dimensions de facturation

Chaque dimension de facturation définit une unité personnalisée par laquelle l’ISV peut émettre des événements d’utilisation. Les dimensions de facturation sont également utilisées pour communiquer avec le client sur la façon dont ils seront facturés pour l’utilisation du logiciel. Elles sont définies comme suit :

ID : identificateur immuable référencé lors de l’émission d’événements d’utilisation.
Nom d’affichage : nom d’affichage associé à la dimension, par exemple, « messages SMS envoyés ».
Unité de mesure : description de l’unité de facturation, par exemple, « par SMS » ou « par 100 e-mails ».
Prix par unité en USD : prix d’une unité de dimension. Il peut être égal à 0.

Important

Vous devez suivre l’utilisation dans votre code d’application et envoyer des événements d’utilisation à Microsoft en fonction de vos besoins de facturation.

Les dimensions de facturation sont partagées entre tous les plans d’une offre. Certains attributs s’appliquent à la dimension dans tous les plans, et les autres attributs sont spécifiques à un plan.

Les attributs qui définissent la dimension proprement dite sont partagés entre tous les plans d’une offre. Avant de publier l’offre, une modification apportée à ces attributs à partir du contexte d’un plan affecte la définition de dimension dans tous les plans. Une fois que vous avez publié l’offre, ces attributs ne sont plus modifiables. Ces attributs sont :

id
Nom d’affichage
Unité de mesure

Les autres attributs d’une dimension sont spécifiques à chaque plan et peuvent avoir des valeurs différentes d’un plan à l’autre. Avant de publier le plan, vous pouvez modifier ces valeurs, et seul ce plan sera affecté. Une fois que vous avez publié le plan, ces attributs ne sont plus modifiables. Ces attributs sont :

Prix unitaire en USD

Les dimensions ont également un concept spécial appelé « activé » :

Activé indique que ce plan participe à cette dimension. Si vous créez un plan qui n’envoie pas d’événements d’utilisation en fonction de cette dimension, vous pouvez laisser cette option désactivée. En outre, toutes les nouvelles dimensions ajoutées après la publication initiale d’un plan apparaissent comme « Non activées » sur le plan déjà publié. Une dimension désactivée ne s’affiche pas dans les listes de dimensions d’un plan vu par les clients.

Remarque

Les scénarios suivants sont explicitement pris en charge :

Vous pouvez ajouter une nouvelle dimension à un nouveau plan. La nouvelle dimension ne sera pas activée pour les plans déjà publiés.

Définition du prix de la dimension par unité par marché pris en charge

Comme d’autres tarifs basés sur l’utilisation, les prix de dimension de facturation peuvent être définis par pays ou région pris en charge. Vous devez utiliser la fonctionnalité de tarification d’importation et d’exportation de données dans l’Espace partenaires conformément à la description ci-dessous.

Définissez les dimensions souhaitées et marquez les marchés pris en charge.
Exportez ces données dans un fichier.
Ajoutez les prix appropriés par pays/région et importez le fichier dans l’Espace partenaires.

L’interface utilisateur du compteur change pour refléter que les prix de la dimension ne peuvent être affichés que dans le fichier.

Plan privé

Comme les plans de facturation prédéfinis basés sur l’utilisation, un plan avec des dimensions personnalisées peut être défini comme plan privé, accessible uniquement par l’audience définie du plan.

Contraintes

Comportement du verrouillage

Une dimension utilisée avec le service de mesure de la consommation de la Place de marché commerciale représentant une indication de la manière dont un client paye pour le service, tous les détails d’une dimension ne sont plus modifiables après que vous l’avez publiée. Il est important que vos dimensions soient entièrement définies pour un plan avant la publication.

Une fois qu’une offre est publiée avec une dimension, les détails au niveau de l’offre pour cette dimension ne peuvent plus être modifiés :

id
Nom d’affichage
Unité de mesure

Une fois qu’un plan est publié, ce détail au niveau du plan ne peut plus être modifié :

Indique si la dimension est activée pour le plan

Limites supérieures

Le nombre maximal de dimensions pouvant être configurées pour une même offre est de 30 dimensions uniques.

Facturation à l’usage d’Azure Container

Les API de facturation à la consommation doivent être utilisées lorsque le serveur de publication crée des dimensions de contrôle personnalisées pour une offre à publier dans l’Espace partenaires. L’intégration avec les API de facturation à la consommation est requise pour toute offre achetée ayant un ou plusieurs plans avec des dimensions personnalisées pour émettre des événements d’utilisation.

Important

Pour plus d’informations sur la création de dimensions de contrôle personnalisées pour Kubernetes Apps, consultez Créer une offre de conteneur Azure.

Application de la note TLS 1.2

La version 1.2 de TLS a été mise en œuvre en tant que version minimale pour les communications HTTPs. Veillez à utiliser cette version de TLS dans votre code. Tls version 1.0 et 1.1 sont déconseillées et les tentatives de connexion sont refusées.

Événement d’utilisation unique avec facturation à la consommation

L’API d’événement d’utilisation doit être appelée par le serveur de publication pour émettre des événements par rapport à une ressource active (souscrite) pour le plan acheté par le client. L’événement d’utilisation est émis séparément pour chaque dimension personnalisée du plan défini par le serveur de publication liée à l’offre.

Un seul événement d’utilisation peut être émis pour chaque heure d’un jour calendaire par ressource et dimension. Si plusieurs unités sont consommées au cours d’une heure, accumulez toutes les unités consommées dans l’heure, puis émettez-les en un seul événement. Les événements d’utilisation peuvent être émis uniquement au cours des dernières 24 heures. Si vous émettez un événement d’utilisation à tout moment entre 8:00 et 8:59:59 (et qu’il est accepté) et envoyez un autre événement pour la même journée entre 8:00 et 8:59:59, il est rejeté en tant que doublon.

POST : https://marketplaceapi.microsoft.com/api/usageEvent?api-version=<ApiVersion>

Paramètres de requête :

Paramètre	Recommandation
`ApiVersion`	Utilisez 2018-08-31.

En-têtes de demande :

Content-Type	Utilisez `application/json`.
`x-ms-requestid`	Valeur de chaîne unique pour le suivi de la requête du client, de préférence un GUID. Si cette valeur n’est pas fournie, une valeur est générée et fournie dans les en-têtes de réponse.
`x-ms-correlationid`	Valeur de chaîne unique pour l’opération sur le client. Ce paramètre sert à corréler tous les événements de l’opération client avec les événements côté serveur. Si cette valeur n’est pas fournie, une valeur est générée et fournie dans les en-têtes de réponse.
`authorization`	Jeton d’accès unique qui identifie le serveur ISV qui effectue cet appel d’API. Le format est `"Bearer <access_token>"` le moment où la valeur du jeton est récupérée par l’éditeur, comme expliqué dans l’application Kubernetes dans les stratégies d’authentification.

Exemple de corps de la demande :

{
  "resourceUri": "<ARM resource URI of the Kubernetes app instance>", // unique identifier of the resource against which usage is emitted. 
  "quantity": 5.0, // how many units were consumed for the date and hour specified in effectiveStartTime, must be greater than 0 or a double integer
  "dimension": "dim1", // custom dimension identifier
  "effectiveStartTime": "2018-12-01T08:30:14", // time in UTC when the usage event occurred, from now and until 24 hours back
  "planId": "plan1", // id of the plan purchased for the offer
}

Remarque

Pour les applications Kubernetes, il s’agit resourceUri de l’URI de ressource ARM de l’instance d’application Kubernetes.

Réponses

Code : 200
OK. L’émission d’utilisation a été acceptée et enregistrée côté Microsoft en vue d’un traitement et d’une facturation supplémentaires.

Exemple de charge utile de réponse :

{
  "usageEventId": <guid>, // unique identifier associated with the usage event in Microsoft records
  "status": "Accepted" // this is the only value in case of single usage event
  "messageTime": "2020-01-12T13:19:35.3458658Z", // time in UTC this event was accepted
  "resourceUri": "<ARM resource URI of the Kubernetes app instance>", // unique identifier of the resource against which usage is emitted. For SaaS it's the subscriptionId.
  "quantity": 5.0, // amount of emitted units as recorded by Microsoft
  "dimension": "dim1", // custom dimension identifier
  "effectiveStartTime": "2018-12-01T08:30:14", // time in UTC when the usage event occurred, as sent by the ISV
  "planId": "plan1", // id of the plan purchased for the offer
}

Code : 400
Demande incorrecte.

Données de requête manquantes ou non valides fournies.
effectiveStartTime est supérieur à 24 heures dans le passé. L’événement a expiré.

Exemple de charge utile de réponse :

{
  "message": "One or more errors have occurred.",
  "target": "usageEventRequest",
  "details": [
    {
      "message": "The resourceUri is required.",
      "target": "ResourceUri",
      "code": "BadArgument"
    }
  ],
  "code": "BadArgument"
}

Code : 400
Demande incorrecte.

L’URI de ressource est déjà inscrit précédemment, vous devez attendre 24 heures avant d’envoyer l’utilisation.

Exemple de charge utile de réponse :

{
  "message": "One or more errors have occurred.",
  "target": "usageEventRequest",
  "details": [
    {
      "message": "Invalid usage state.",
      "target": "ResourceUri",
      "code": "BadArgument"
    }
  ],
  "code": "BadArgument"
}

Code : 403

Interdit. Le jeton d’autorisation n’est pas fourni, n’est pas valide ou a expiré.

Code : 409
Conflit. Un événement d’utilisation a déjà été signalé pour l’ID de ressource, la date d’utilisation effective et l’heure spécifiés.

Exemple de charge utile de réponse :

{
  "additionalInfo": {
    "acceptedMessage": {
      "usageEventId": "<guid>", //unique identifier associated with the usage event in Microsoft records
      "status": "Duplicate",
      "messageTime": "2020-01-12T13:19:35.3458658Z",
      "resourceUri": "<ARM resource URI of the Kubernetes app instance>", //unique identifier of the resource against which usage is emitted.
      "quantity": 1.0,
      "dimension": "dim1",
      "effectiveStartTime": "2020-01-12T11:03:28.14Z",
      "planId": "plan1"
    }
  },
  "message": "This usage event already exist.",
  "code": "Conflict"
}

Événement d’utilisation en lot avec facturation à la consommation

L’API d’événement d’utilisation par lot vous permet d’émettre des événements d’utilisation pour plusieurs ressources achetées en même temps. Il vous permet également d’émettre plusieurs événements d’utilisation pour la même ressource tant qu’ils sont pour des heures de calendrier différentes. Le nombre maximal d’événements dans un lot unique est de 25.

POST : https://marketplaceapi.microsoft.com/api/batchUsageEvent?api-version=<ApiVersion>

Paramètres de requête :

Paramètre	Recommandation
`ApiVersion`	Utilisez 2018-08-31.

En-têtes de demande :

Content-Type	Utilisez `application/json`.
`x-ms-requestid`	Valeur de chaîne unique pour le suivi de la requête du client, de préférence un GUID. Si cette valeur n’est pas fournie, une valeur est générée et fournie dans les en-têtes de réponse.
`x-ms-correlationid`	Valeur de chaîne unique pour l’opération sur le client. Ce paramètre sert à corréler tous les événements de l’opération client avec les événements côté serveur. Si cette valeur n’est pas fournie, est générée et fournie dans les en-têtes de réponse.
`authorization`	Jeton d’accès unique qui identifie le serveur ISV qui effectue cet appel d’API. Le format est `Bearer <access_token>` le moment où la valeur du jeton est récupérée par l’éditeur, comme expliqué dans l’application Kubernetes dans les stratégies d’authentification.

Remarque

Dans le corps de la demande, l’identificateur de ressource pour les applications Kubernetes est resourceUri.

Exemple de corps de requête pour les applications Kubernetes :

{
  "request": [ // list of usage events for the same or different resources of the publisher
    { // first event
      "resourceUri": "<ARM resource URI of the Kubernetes app instance>", // Unique identifier of the resource against which usage is emitted. 
      "quantity": 5.0, // how many units were consumed for the date and hour specified in effectiveStartTime, must be greater than 0 or a double integer
      "dimension": "dim1", //Custom dimension identifier
      "effectiveStartTime": "2018-12-01T08:30:14",//Time in UTC when the usage event occurred, from now and until 24 hours back
      "planId": "plan1", // id of the plan purchased for the offer
    },
    { // next event
      "resourceUri": "<ARM resource URI of the Kubernetes app instance>", 
      "quantity": 39.0, 
      "dimension": "email", 
      "effectiveStartTime": "2018-11-01T23:33:10
      "planId": "gold", // id of the plan purchased for the offer
    }
  ]
}

Réponses

Code : 200
OK. L’émission d’utilisation en lot a été acceptée et enregistrée côté Microsoft en vue d’un traitement et d’une facturation supplémentaires. La liste de réponses est retournée avec l’état de chaque événement individuel dans le lot. Vous devez itérer au sein de la charge utile de réponse pour comprendre les réponses pour chaque événement d’utilisation individuel envoyé dans le cadre de l’événement de traitement par lots.

Exemple de charge utile de réponse :

{
  "count": 2, // number of records in the response
  "result": [
    { // first response
      "usageEventId": "<guid>", // unique identifier associated with the usage event in Microsoft records
      "status": "Accepted" // see list of possible statuses below,
      "messageTime": "2020-01-12T13:19:35.3458658Z", // Time in UTC this event was accepted by Microsoft,
      "resourceUri": "<ARM resource URI of the Kubernetes app instance>", // unique identifier of the resource against which usage is emitted.
      "quantity": 5.0, // amount of emitted units as recorded by Microsoft 
      "dimension": "dim1", // custom dimension identifier
      "effectiveStartTime": "2018-12-01T08:30:14",// time in UTC when the usage event occurred, as sent by the ISV
      "planId": "plan1", // id of the plan purchased for the offer
    },
    { // second response
      "status": "Duplicate",
      "messageTime": "0001-01-01T00:00:00",
      "error": {
        "additionalInfo": {
          "acceptedMessage": {
            "usageEventId": "<guid>",
            "status": "Duplicate",
            "messageTime": "2020-01-12T13:19:35.3458658Z",
            "resourceUri": "<ARM resource URI of the Kubernetes app instance>",
            "quantity": 1.0,
            "dimension": "email",
            "effectiveStartTime": "2020-01-12T11:03:28.14Z",
            "planId": "gold"
          }
        },
        "message": "This usage event already exist.",
        "code": "Conflict"
      },
      "resourceId": "<guid2>",
      "quantity": 1.0,
      "dimension": "email",
      "effectiveStartTime": "2020-01-12T11:03:28.14Z",
      "planId": "gold"
    }
  ]
}

Description du code d’état référencé dans la réponse de l’API BatchUsageEvent :

Code d’état	Description
`Accepted`	Accepté.
`Expired`	Utilisation expirée.
`Duplicate`	Utilisation dupliquée fournie.
`Error`	Code d’erreur.
`ResourceNotFound`	La ressource d’utilisation fournie n’est pas valide.
`ResourceNotAuthorized`	Vous n’êtes pas autorisé à fournir l’utilisation de cette ressource.
`ResourceNotActive`	La ressource est suspendue ou n’a jamais été activée.
`InvalidDimension`	La dimension pour laquelle l’utilisation est transmise n’est pas valide pour cette offre/ce plan.
`InvalidQuantity`	La quantité passée est inférieure ou égale à 0.
`BadArgument`	L’entrée est manquante ou incorrecte.

Code : 400
Demande incorrecte. Le lot contenait plus de 25 événements d’utilisation.

Code : 403
Interdit. Le jeton d’autorisation n’est pas fourni, n’est pas valide ou a expiré.

Événements d’utilisation de la récupération de la facturation à l’usage

Vous pouvez appeler l’API des événements d’utilisation pour récupérer la liste des événements d’utilisation. Les éditeurs de logiciels indépendants peuvent utiliser cette API pour voir les événements d’utilisation qui ont été publiés pendant une période configurable donnée et l’état de ces événements au moment de l’appel de l’API.

GET : https://marketplaceapi.microsoft.com/api/usageEvents

Paramètres de requête :

Paramètre	Recommandation
ApiVersion	Utilisez 2018-08-31.
usageStartDate	DateTime au format ISO8601. Par exemple, 2020-12-03T15:00 ou 2020-12-03
UsageEndDate (facultatif)	DateTime au format ISO8601. Valeur par défaut = date du jour
offerId (facultatif)	Valeur par défaut = toute valeur disponible
planId (facultatif)	Valeur par défaut = toute valeur disponible
dimension (facultatif)	Valeur par défaut = toute valeur disponible
azureSubscriptionId (facultatif)	Valeur par défaut = toute valeur disponible
reconStatus (facultatif)	Valeur par défaut = toute valeur disponible

Valeurs possibles de reconStatus :

ReconStatus	Description
Envoyée	Pas encore traité par l’analytique de l’Espace partenaires
Acceptée	Mis en correspondance avec l’analytique de l’Espace partenaires
Rejeté	Rejeté dans le pipeline. Contactez le support Microsoft pour en savoir plus sur la cause.
Incompatibilité	Les quantités MarketplaceAPI et Partner Center Analytics ne sont pas égales à zéro, mais ne correspondent pas
TestHeaders	Abonnement listé avec des en-têtes de test et, par conséquent, absent de l’analytique de l’Espace partenaires
DryRun	Soumis avec SessionMode = DryRun, et par conséquent absent de l’analytique de l’Espace partenaires

En-têtes de demande :

Type de contenu	Utiliser application/json
x-ms-requestid	Valeur de chaîne unique (de préférence un GUID) pour le suivi de la demande du client. Si cette valeur n’est pas fournie, une valeur est générée et fournie dans les en-têtes de réponse.
x-ms-correlationid	Valeur de chaîne unique pour l’opération sur le client. Ce paramètre sert à corréler tous les événements de l’opération client avec les événements côté serveur. Si cette valeur n’est pas fournie, une valeur est générée et fournie dans les en-têtes de réponse.
autorisation	Jeton d’accès unique qui identifie le serveur ISV qui effectue cet appel d’API. Le format est `Bearer <access_token>` lorsque la valeur de jeton est récupérée par le serveur de publication. - Application Kubernetes dans les stratégies d’authentification

Réponses

Exemples de charge utile de réponse :

Accepté

[
  {
    "usageDate": "2020-11-30T00:00:00Z",
    "usageResourceId": "11111111-2222-3333-4444-555555555555",
    "dimension": "tokens",
    "planId": "silver",
    "planName": "Silver",
    "offerId": "mycooloffer",
    "offerName": "My Cool Offer",
    "offerType": "SaaS",
    "azureSubscriptionId": "12345678-9012-3456-7890-123456789012",
    "reconStatus": "Accepted",
    "submittedQuantity": 17.0,
    "processedQuantity": 17.0,
    "submittedCount": 17
  }
]

Envoyé

[
  {
    "usageDate": "2020-11-30T00:00:00Z",
    "usageResourceId": "11111111-2222-3333-4444-555555555555",
    "dimension": "tokens",
    "planId": "silver",
    "planName": "",
    "offerId": "mycooloffer",
    "offerName": "",
    "offerType": "SaaS",
    "azureSubscriptionId": "12345678-9012-3456-7890-123456789012",
    "reconStatus": "Submitted",
    "submittedQuantity": 17.0,
    "processedQuantity": 0.0,
    "submittedCount": 17
  }
]

Décalage

[
  {
    "usageDate": "2020-11-30T00:00:00Z",
    "usageResourceId": "11111111-2222-3333-4444-555555555555",
    "dimension": "tokens",
    "planId": "silver",
    "planName": "Silver",
    "offerId": "mycooloffer",
    "offerName": "My Cool Offer",
    "offerType": "SaaS",
    "azureSubscriptionId": "12345678-9012-3456-7890-123456789012",
    "reconStatus": "Mismatch",
    "submittedQuantity": 17.0,
    "processedQuantity": 16.0,
    "submittedCount": 17
  }
]

Rejeté

[
  {
    "usageDate": "2020-11-30T00:00:00Z",
    "usageResourceId": "11111111-2222-3333-4444-555555555555",
    "dimension": "tokens",
    "planId": "silver",
    "planName": "",
    "offerId": "mycooloffer",
    "offerName": "",
    "offerType": "SaaS",
    "azureSubscriptionId": "12345678-9012-3456-7890-123456789012",
    "reconStatus": "Rejected",
    "submittedQuantity": 17.0,
    "processedQuantity": 0.0,
    "submittedCount": 17
  }
]

Codes d’état

Code : 403 Interdit. Le jeton d’autorisation n’est pas fourni, n’est pas valide ou a expiré.

Bonnes pratiques en matière de développement et de test

Pour tester l’émission de compteur personnalisée, implémentez l’intégration à l’API de contrôle, créez un plan pour votre offre Kubernetes Apps publiée avec des dimensions personnalisées définies dans celle-ci avec un prix zéro par unité. Puis publiez cette offre en version préliminaire afin que seuls les utilisateurs limités puissent accéder à l’intégration et la tester.

Vous pouvez également utiliser un plan privé pour une offre live existante afin de limiter l’accès à ce plan pendant le test à un public limité.

Pour plus d’informations sur les API de service de mesure, consultez FAQ sur l’API de service de mesure de la Place de marché.

Obtenir du support

Si vous rencontrez l’un des problèmes suivants, vous pouvez ouvrir un ticket de support.

Problèmes techniques liés à l’API du service de mesure de la consommation de la Place de marché.
Un problème qui doit être remonté en raison d’une erreur ou d’un bogue de votre côté (par exemple événement d’utilisation incorrect).
Tout autre problème lié à la facturation à la consommation.

Pour comprendre les options du serveur de publication et ouvrir un ticket de support auprès de Microsoft, suivez les instructions de la section Support technique pour le programme Place de marché commerciale dans l’Espace partenaires.

Partager via

Facturation limitée pour les conteneurs Azure à l’aide du service de contrôle de la Place de marché commerciale

Prérequis pour la facturation à la consommation

Comment la facturation à la consommation s’adapte à la tarification

Exemples d’options de tarification personnalisées

Dimensions de facturation

Définition du prix de la dimension par unité par marché pris en charge

Plan privé

Contraintes

Comportement du verrouillage

Limites supérieures

Facturation à l’usage d’Azure Container

Application de la note TLS 1.2

Événement d’utilisation unique avec facturation à la consommation

Réponses

Événement d’utilisation en lot avec facturation à la consommation

Réponses

Événements d’utilisation de la récupération de la facturation à l’usage

Réponses

Bonnes pratiques en matière de développement et de test

Obtenir du support

Commentaires

Ressources supplémentaires

Partager via

Facturation limitée pour les conteneurs Azure à l’aide du service de contrôle de la Place de marché commerciale

Prérequis pour la facturation à la consommation

Comment la facturation à la consommation s’adapte à la tarification

Exemples d’options de tarification personnalisées

Dimensions de facturation

Définition du prix de la dimension par unité par marché pris en charge

Plan privé

Contraintes

Comportement du verrouillage

Limites supérieures

Facturation à l’usage d’Azure Container

Application de la note TLS 1.2

Événement d’utilisation unique avec facturation à la consommation

Réponses

Événement d’utilisation en lot avec facturation à la consommation

Réponses

Événements d’utilisation de la récupération de la facturation à l’usage

Réponses

Bonnes pratiques en matière de développement et de test

Contenu connexe

Obtenir du support

Commentaires

Ressources supplémentaires