Getaktete Abrechnung für Azure-Container mit dem kommerziellen Marketplace-Metering-Dienst

Artikel
06/14/2024

Mit dem kommerziellen Marketplace-Metering-Dienst können Sie Azure Container-Angebote erstellen, die gemäß nicht standardmäßigen Einheiten in Rechnung gestellt werden. Bevor Sie das Angebot auf dem kommerziellen Marketplace veröffentlichen, definieren Sie die Abrechnungsdimensionen wie Bandbreite, Shards, Logfiles, Scans, verarbeitete E-Mails usw. Kunden zahlen dann gemäß ihrem Verbrauch dieser Dimensionen, mit Ihrer Anwendung, die Microsoft über die kommerzielle Marketplace-Metering-Dienst-API über abrechnende Ereignisse informiert, sobald sie auftreten.

Voraussetzungen für die getaktete Abrechnung

Damit ein Azure Container-Angebot getaktete Abrechnung verwenden kann, müssen Sie zuerst die lizenzierungsoptionen überprüfen, die im Angebot "Plan for Azure Container" beschrieben sind, und stellen Sie sicher, dass Sie über benutzerdefinierte Abrechnungsanforderungen verfügen, die nicht von einem der sechs vorhandenen vordefinierten Abrechnungsmodelle erfüllt sind.

Anschließend kann das Azure Container-Angebot in die kommerziellen Marketplace-Metering-Dienst-APIs integriert werden, um Microsoft über abrechnende Ereignisse zu informieren.

Wichtig

Ihre Anwendung muss die kommerziellen Marketplace-Metering-Dienst-APIs aufrufen. Derzeit gibt es keine Option, ihren gehosteten Dienst (außerhalb der Anwendung) zum Aufrufen der Meteringdienst-API zuzulassen.

Hinweis

Marketplace-Metering-Dienst ist nur für das benutzerdefinierte Abrechnungsmodell verfügbar und gilt nicht für das Abrechnungsmodell pro Benutzer.

Zusammenspiel von getakteter Abrechnung und Preisgestaltung

Das Verständnis der Angebotshierarchie ist wichtig, wenn es darum geht, das Angebot zusammen mit seinen Preismodellen zu definieren.

Jedes Angebot ist so konfiguriert, dass es entweder über Microsoft verkauft wird oder nicht. Sobald ein Angebot veröffentlicht wurde, kann diese Option nicht mehr geändert werden.
Jedes Angebot, das für den Verkauf über Microsoft konfiguriert ist, kann über einen oder mehrere Pläne verfügen.
Jedem Plan ist ein Preismodell zugeordnet: Nutzungsbasierter monatlicher Abrechnungsplan oder Bring your own license (BYOL). Für den nutzungsbasierten monatlichen Abrechnungsplan können Sie entweder kostenlos, eine von sechs vordefinierten Abrechnungsoptionen oder benutzerdefinierte Optionen auswählen.
Das Preismodell und die Preiseingabeoptionen können nach der Veröffentlichung nicht mehr aktualisiert werden.
Jeder Plan muss über einen vollständigen Preisplan verfügen.
Sie können sich für den Preis entscheiden, indem Sie benutzerdefinierte Dimensionen verwenden, um Ihre Kunden zu belasten, um Ihren Abrechnungsanforderungen gerecht zu werden. Jede Dimension stellt eine abrechnende Einheit dar, die Ihr Dienst mit der kommerziellen Marketplace-Metering-Dienst-API an Microsoft kommuniziert.

Wichtig

Sie müssen die Verwendung in Ihrem Code nachverfolgen und nur Nutzungsereignisse an Microsoft senden, damit der Kunde die Rechnung erhalten soll.

Hinweis

Angebote werden den Kunden in ihrer Vertragswährung zu dem lokalen Marktpreis in Rechnung gestellt, der zum Zeitpunkt der Angebotserstellung veröffentlicht wurde. Der von Kunden und an ISVs gezahlte Betrag hängt vom aktuellen Wechselkurs ab, zu dem der Kunde das Angebot abwickelt. Weitere Informationen finden Sie unter So rechnen wir Währungen um.

Beispiel für benutzerdefinierte Preisoptionen

Beispielsweise ist Contoso ein Herausgeber, dessen IP-Adresse sich in ihrer Shardinglogik für ihre Kubernetes-Anwendung befindet. Contoso möchte ihre Kunden basierend auf der Anzahl der verwendeten Shards in Rechnung stellen. Sie erkunden auch andere günstige und wettbewerbsfähige Abrechnungsoptionen. Contoso ist als Herausgeber im Partner Center für das kommerzielle Marketplace-Programm registriert und möchte Containerangebote für Azure-Kunden veröffentlichen. Es sind vier Pläne mit Contoso verknüpft, die unten beschrieben sind:

Gebühr pro verwendeter Shards pro Stunde, z. B. $1.000/Shard/Stunde
Modellieren einer einmaligen Zahlung oder wiederkehrender Abrechnung: Angenommen, Contoso möchte einen Kunden für die Nutzung von bis zu 100 Protokolldateien aus ihrer Anwendung in Rechnung stellen. Die Anwendungslogik von Contoso verfolgt das Nutzungsereignis für den Monat und löst eine Gebühr am Monatsende für die Nutzung von 100 Protokolldateien aus.
Modellierung der gestaffelten Abrechnung: Angenommen, Contoso möchte 449 USD /Mo für bis zu 100 Shards berechnen und dann die Preise für jede Überlastung gestaffelt. Ihre Anwendungslogik würde die Nutzung für den Monat nachverfolgen, die Nutzung entsprechend segmentieren und mit den unten aufgeführten Metering-APIs am Ende des Zeitraums melden:
Mehrdimensionale Abrechnung: Contoso kann auch benutzerdefinierte Meter verwenden, um ihre Anforderungen für die erweiterte Abrechnung mit mehreren Dimensionen zu erfüllen.

Basierend auf dem ausgewählten Plan wird ein Azure-Kunde, der das Contoso Container-Angebot erhält, basierend auf seiner Nutzung belastet. Contoso zählt die Verwendung ohne Senden von Verwendungsereignissen an Microsoft. Wenn Kunden einen angemessenen Betrag oder regelmäßig verbrauchen, meldet Contoso die Nutzung. Kunden müssen keine Pläne ändern oder etwas anderes tun. Contoso misst die Verwendung und startet mit dem Senden von Nutzungsereignissen an Microsoft, um die Überlastungsnutzung mithilfe der kommerziellen Marketplace-Metering-Dienst-API zu laden. Microsoft berechnet dem Kunden wiederum die Nutzung, wie vom Herausgeber in den benutzerdefinierten Dimensionen angegeben. Die Abrechnung erfolgt am nächsten monatlichen Abrechnungszeitraum.

Abrechnungsdimensionen

Jede Abrechnungsdimension definiert eine benutzerdefinierte Einheit, mit der ein unabhängiger Softwarehersteller Nutzungsereignisse senden kann. Abrechnungsdimensionen werden auch verwendet, um dem Kunden mitzuteilen, wie sie für die Verwendung der Software in Rechnung gestellt werden. Sie sind wie folgt definiert:

Kennung: Die unveränderliche Dimensionskennung, auf die bei der Ausgabe von Nutzungsereignissen verwiesen wird
Anzeigename: Der Anzeigename, der der Dimension zugeordnet ist, z. B. „Gesendete SMS“
Maßeinheit: Die Beschreibung der Abrechnungseinheit, z. B. „pro SMS“ oder „pro 100 E-Mails“
Preis pro Einheit in USD: der Preis für eine Einheit der Dimension. Kann 0 (Null) entsprechen.

Wichtig

Sie müssen die Verwendung im Anwendungscode nachverfolgen und Nutzungsereignisse basierend auf Ihren Abrechnungsanforderungen an Microsoft senden.

Abrechnungsdimensionen werden in allen Plänen für ein Angebot verwendet. Manche Attribute gelten für die Dimension über alle Pläne hinweg, andere Attribute sind dagegen planspezifisch.

Die Attribute, die die Dimension selbst definieren, werden übergreifend für alle Pläne zu einem Angebot genutzt. Bevor Sie das Angebot veröffentlichen, wirkt sich eine Änderung an diesen Attributen aus dem Kontext eines Plans auf die Dimensiondefinition in allen Plänen aus. Sobald Sie das Angebot veröffentlicht haben, können diese Attribute nicht mehr bearbeitet werden. Zu diesen Attributen zählen folgende:

Kennung
Anzeigenname
Einheit

Die anderen Attribute einer Dimension sind planspezifisch und können von Plan zu Plan unterschiedliche Werte haben. Bevor Sie den Plan veröffentlichen, können Sie diese Werte bearbeiten, und nur dieser Plan ist betroffen. Nachdem Sie den Plan veröffentlicht haben, können diese Attribute nicht mehr bearbeitet werden. Zu diesen Attributen zählen folgende:

Preis pro Einheit in USD

Dimensionen haben auch ein spezielles Konzept namens "enabled":

Aktiviert gibt an, dass dieser Plan Teil dieser Dimension ist. Wenn Sie einen neuen Plan erstellen, der keine Nutzungsereignisse basierend auf dieser Dimension sendet, sollten Sie diese Option möglicherweise deaktiviert lassen. Außerdem werden alle neuen Dimensionen, die nach der ersten Veröffentlichung eines Plans hinzugefügt wurden, für den bereits veröffentlichten Plan als „nicht aktiviert“ angezeigt. Eine deaktivierte Dimension wird in keiner Liste der Dimensionen für einen Plan angezeigt, der von Kunden angezeigt wird.

Hinweis

Folgende Szenarien werden explizit unterstützt:

Sie können einem neuen Plan eine neue Dimension hinzufügen. Die neue Dimension wird nicht für bereits veröffentlichte Pläne aktiviert.

Festlegen des Dimensionspreises pro Einheit und unterstütztem Markt

Wie bei anderen nutzungsbasierten Preisen können die Abrechnungsdimensionspreise pro unterstütztem Land oder region festgelegt werden. Sie müssen dafür das Feature zum Importieren und Exportieren von Preisdaten in Partner Center wie folgt verwenden.

Definieren Sie die gewünschten Dimensionen, und markieren Sie, welche Märkte unterstützt werden sollen.
Exportieren Sie diese Daten in eine Datei.
Fügen Sie die korrekten Preise pro Land oder Region ein, und importieren Sie die Datei in Partner Center.

Die Benutzeroberfläche der Zähler ändert sich, um widerzuspiegeln, dass die Preise der Dimension nur in der Datei zu sehen sind.

Privater Tarif

Wie bei den vordefinierten nutzungsbasierten Abrechnungsplänen kann ein Plan mit benutzerdefinierten Dimensionen als privater Plan festgelegt werden, auf den nur die definierte Zielgruppe des Plans zugreifen kann.

Einschränkungen

Sperrverhalten

Da eine Dimension, die mit dem kommerziellen Marktplatz-Metering-Service verwendet wird, eine Vorstellung davon vermittelt, wie ein Kunde für den Service bezahlen wird, sind alle Details für eine Dimension nicht mehr editierbar, nachdem Sie sie veröffentlicht haben. Daher ist es wichtig, dass Sie Ihre Dimensionen vor der Veröffentlichung vollständig für einen Plan definiert wurden.

Sobald ein Angebot mit einer Dimension veröffentlicht wurde, können die Details der Angebotsebene für diese Dimension nicht mehr geändert werden:

Kennung
Anzeigenname
Einheit

Sobald ein Plan veröffentlicht wurde, kann dieses Detail auf Planebene nicht mehr geändert werden:

Ob die Dimension für den Plan aktiviert ist oder nicht

Obergrenzen

Für ein einzelnes Angebot können maximal 30 individuelle Dimensionen konfiguriert werden.

Getaktete Abrechnung für Azure-Container

Die APIs für getaktete Abrechnung sollten verwendet werden, wenn der Herausgeber benutzerdefinierte Messungsdimensionen für ein Angebot erstellt, das im Partner Center veröffentlicht werden soll. Für alle erworbenen Angebote, die über einen oder mehrere Pläne mit benutzerdefinierten Dimensionen zur Ausgabe von Nutzungsereignissen verfügen, ist eine Integration in die APIs für getaktete Abrechnung erforderlich.

Wichtig

Weitere Informationen zum Erstellen von benutzerdefinierten Meteringdimensionen für Kubernetes-Apps finden Sie unter Erstellen eines Azure-Containerangebots.

Erzwingen der TLS 1.2-Notiz

Die TLS-Version 1.2 wird als Mindestversion für die HTTPS-Kommunikation erzwungen. Stellen Sie sicher, dass Sie diese TLS-Version in Ihrem Code verwenden. TLS Version 1.0 und 1.1 sind veraltet, und Verbindungsversuche werden abgelehnt.

Einzelnes Nutzungsereignis für getaktete Abrechnung

Die API für Nutzungsereignisse sollte vom Herausgeber aufgerufen werden, um Nutzungsereignisse für eine aktive Ressource (abonniert) für den vom jeweiligen Kunden erworbenen Plan auszugeben. Das Nutzungsereignis wird für jede benutzerdefinierte Dimension des Plans, die vom Herausgeber bei Veröffentlichung des Angebots definiert wurde, separat ausgegeben.

Für jede Stunde eines Kalendertags kann pro Ressource und Dimension nur ein Nutzungsereignis ausgegeben werden. Wenn mehr als eine Einheit in einer Stunde verwendet wird, sammeln Sie alle in dieser Stunde verwendeten Einheiten, und geben Sie diese dann in einem einzelnen Ereignis aus. Nutzungsereignisse können nur für die letzten 24 Stunden ausgegeben werden. Wenn Sie ein Nutzungsereignis jederzeit zwischen 8:00 und 8:59:59 (und es akzeptiert) ausgeben und ein anderes Ereignis für den gleichen Tag zwischen 8:00 und 8:59:59 senden, wird es als Duplikat abgelehnt.

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

Abfrageparameter:

Parameter	Empfehlung
`ApiVersion`	Verwenden Sie 2018-08-31.

Anforderungsheader:

Inhaltstyp	Verwenden Sie `application/json`
`x-ms-requestid`	Eindeutiger Zeichenfolgenwert für die Nachverfolgung der Anforderung vom Client, vorzugsweise eine GUID. Wenn dieser Wert nicht angegeben wird, wird ein Wert generiert und in den Antwortheadern bereitgestellt.
`x-ms-correlationid`	Eindeutiger Zeichenfolgenwert für den Vorgang auf dem Client. Dieser Parameter korreliert alle Ereignisse des Clientvorgangs mit serverseitigen Ereignissen. Wenn dieser Wert nicht angegeben wird, wird ein Wert generiert und in den Antwortheadern bereitgestellt.
`authorization`	Ein eindeutiges Zugriffstoken, das den ISV identifiziert, der diesen API-Aufruf sendet. Das Format ist `"Bearer <access_token>"` , wenn der Tokenwert vom Herausgeber abgerufen wird, wie in der Kubernetes-Anwendung in Authentifizierungsstrategien erläutert.

Beispiel für Anforderungstext:

{
  "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
}

Hinweis

Für Kubernetes-Apps ist der resourceUri ARM-Ressourcen-URI der Kubernetes-App-Instanz.

Antworten

Code: 200
OK. Die Nutzungsausgabe wurde auf Microsoft-Seite zur weiteren Verarbeitung und Abrechnung akzeptiert und aufgezeichnet.

Beispiel einer Antwortnutzlast:

{
  "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
Ungültige Anforderung.

Es wurden fehlende oder ungültige Anforderungsdaten bereitgestellt.
effectiveStartTime liegt mehr als 24 Stunden in der Vergangenheit. Das Ereignis ist abgelaufen.

Beispiel einer Antwortnutzlast:

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

Code: 400
Ungültige Anforderung.

Der Ressourcen-URI ist bereits zuvor registriert, muss 24 Stunden warten, bevor die Verwendung übermittelt wird.

Beispiel einer Antwortnutzlast:

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

Code: 403

Unzulässig. Das Autorisierungstoken wurde nicht angegeben, ist ungültig oder abgelaufen.

Code: 409
Konflikt. Es wurde bereits erfolgreich ein Nutzungsereignis für die angegebene Ressourcen-ID sowie Datum und Stunde der Nutzung gemeldet.

Beispiel einer Antwortnutzlast:

{
  "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"
}

Batchnutzungsereignis für getaktete Abrechnung

Mit der API für Batchnutzungsereignisse können Sie Nutzungsereignisse gleichzeitig für mehr als eine erworbene Ressource ausgeben. Außerdem können Sie mehrere Verwendungsereignisse für dieselbe Ressource ausgeben, solange sie sich für unterschiedliche Kalenderstunden befinden. Die maximale Anzahl von Ereignissen in einem einzelnen Batch beträgt 25.

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

Abfrageparameter:

Parameter	Empfehlung
`ApiVersion`	Verwenden Sie 2018-08-31.

Anforderungsheader:

Inhaltstyp	Verwenden Sie `application/json`
`x-ms-requestid`	Eindeutiger Zeichenfolgenwert für die Nachverfolgung der Anforderung vom Client, vorzugsweise eine GUID. Wenn dieser Wert nicht angegeben wird, wird ein Wert generiert und in den Antwortheadern bereitgestellt.
`x-ms-correlationid`	Eindeutiger Zeichenfolgenwert für den Vorgang auf dem Client. Dieser Parameter korreliert alle Ereignisse des Clientvorgangs mit serverseitigen Ereignissen. Wenn dieser Wert nicht angegeben wird, wird er generiert und in den Antwortheadern bereitgestellt.
`authorization`	Ein eindeutiges Zugriffstoken, das den ISV identifiziert, der diesen API-Aufruf sendet. Das Format ist `Bearer <access_token>` , wenn der Tokenwert vom Herausgeber abgerufen wird, wie in der Kubernetes-Anwendung in Authentifizierungsstrategien erläutert.

Hinweis

Im Anforderungstext ist resourceUrider Ressourcenbezeichner für Kubernetes-Apps .

Anforderungstextbeispiel für Kubernetes-Apps:

{
  "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
    }
  ]
}

Antworten

Code: 200
OK. Die Batchnutzungsausgabe wurde auf Microsoft-Seite zur weiteren Verarbeitung und Abrechnung akzeptiert und aufgezeichnet. Die Antwortliste wird mit dem Status für jedes einzelne Ereignis im Batch zurückgegeben. Sie sollten die Antwortnutzlast durchlaufen, um die Antworten für jedes einzelne Nutzungsereignis zu verstehen, das als Teil des Batchereignisses gesendet wird.

Beispiel einer Antwortnutzlast:

{
  "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"
    }
  ]
}

Beschreibung des Statuscodes, der in der BatchUsageEvent-API-Antwort angegeben ist:

Statuscode	Beschreibung
`Accepted`	Akzeptiert:
`Expired`	Abgelaufene Nutzung.
`Duplicate`	Doppelte Nutzung angegeben.
`Error`	Fehlercode
`ResourceNotFound`	Die angegebene Nutzungsressource ist ungültig.
`ResourceNotAuthorized`	Sie sind nicht berechtigt, die Verwendung für diese Ressource bereitzustellen.
`ResourceNotActive`	Die Ressource wird angehalten oder wurde nie aktiviert.
`InvalidDimension`	Die Dimension, für die die Nutzung übergeben wird, ist für dieses Angebot bzw. diesen Plan ungültig.
`InvalidQuantity`	Die übergebene Menge ist kleiner oder gleich 0 (null).
`BadArgument`	Die Eingabe fehlt oder ist falsch formatiert.

Code: 400
Ungültige Anforderung. Der Batch enthielt mehr als 25 Nutzungsereignisse.

Code: 403
Unzulässig. Das Autorisierungstoken wurde nicht angegeben, ist ungültig oder abgelaufen.

Getaktete Abrechnung für das Abrufen von Nutzungsereignissen

Sie können die API für Nutzungsereignisse aufrufen, um die Liste der Nutzungsereignisse abzurufen. ISVs können diese API verwenden, um die Nutzungsereignisse anzuzeigen, die für einen bestimmten konfigurierbaren Zeitraum gesendet wurden, und welchen Status diese Ereignisse zum Zeitpunkt des Aufrufs der API aufweisen.

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

Abfrageparameter:

Parameter	Empfehlung
ApiVersion	Verwenden Sie 2018-08-31.
usageStartDate	Ein DateTime-Wert im ISO 8601-Format. Beispiel: „2020-12-03T15:00“ oder „2020-12-03“
UsageEndDate (optional)	Ein DateTime-Wert im ISO 8601-Format. Standard = Aktuelles Datum
offerId (optional)	Standard = alle verfügbar
planId (optional)	Standard = alle verfügbar
dimension (optional)	Standard = alle verfügbar
azureSubscriptionId (optional)	Standard = alle verfügbar
reconStatus (optional)	Standard = alle verfügbar

Mögliche Werte von reconStatus:

ReconStatus	Beschreibung
Gesendet	Noch nicht von Partner Center Analytics verarbeitet
Zulässig	Mit Partner Center Analytics abgeglichen
Rejected (Abgelehnt)	In der Pipeline abgelehnt. Wenden Sie sich an den Microsoft-Support, um die Ursache zu untersuchen.
Konflikt	MarketplaceAPI- und Partner Center Analytics-Mengen sind beide nicht übereinstimmend.
TestHeaders	Abonnement, das mit Testheadern aufgelistet wird und daher nicht in Partner Center Analytics aufgeführt ist
DryRun	Übermittelt mit SessionMode=DryRun und daher nicht in Partner Center aufgeführt

Anforderungsheader:

Inhaltstyp	Verwendung von „application/json“
x-ms-requestid	Eindeutiger Zeichenfolgenwert (vorzugsweise eine GUID) für die Nachverfolgung der Anforderung vom Client. Wenn dieser Wert nicht angegeben wird, wird ein Wert generiert und in den Antwortheadern bereitgestellt.
x-ms-correlationid	Eindeutiger Zeichenfolgenwert für den Vorgang auf dem Client. Dieser Parameter korreliert alle Ereignisse des Clientvorgangs mit serverseitigen Ereignissen. Wenn dieser Wert nicht angegeben wird, wird ein Wert generiert und in den Antwortheadern bereitgestellt.
Autorisierung	Ein eindeutiges Zugriffstoken, das den ISV identifiziert, der diesen API-Aufruf sendet. Das Format ist `Bearer <access_token>`, wenn der Tokenwert vom Herausgeber abgerufen wird. - Kubernetes-Anwendung in Authentifizierungsstrategien

Antworten

Beispiele einer Antwortnutzlast:

Akzeptiert

[
  {
    "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
  }
]

Gesendet

[
  {
    "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
  }
]

Nichtübereinstimmung

[
  {
    "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
  }
]

Abgelehnt

[
  {
    "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
  }
]

Statuscodes

Code: 403 Verboten. Das Autorisierungstoken wurde nicht angegeben, ist ungültig oder abgelaufen.

Bewährte Methoden für Entwicklung und Test

Um die benutzerdefinierte Meteremissionen zu testen, implementieren Sie die Integration mit der Metering-API, erstellen Sie einen Plan für Ihr veröffentlichtes Kubernetes-Apps-Angebot mit benutzerdefinierten Dimensionen, die darin mit Nullpreis pro Einheit definiert sind. Veröffentlichen Sie dann dieses Angebot als Vorschauversion, sodass nur eingeschränkte Benutzer auf die Integration zugreifen und diese testen können.

Sie können auch einen privaten Plan für ein vorhandenes Liveangebot verwenden, um den Zugriff auf diesen Plan während des Tests auf eine begrenzte Zielgruppe zu beschränken.

Weitere Informationen zu Dienst-APIs für die getaktete Abrechnung finden Sie unter Häufig gestellte Fragen zu Marketplace-Dienst-APIs für die getaktete Abrechnung.

Support

Sollte eines der folgenden Probleme bei Ihnen auftreten, können Sie ein Supportticket erstellen:

Technische Probleme mit der Marketplace-Messungsdienst-API
Ein Problem, das aufgrund eines Fehlers auf Ihrer Seite eskaliert werden muss (z. B. falsches Verwendungsereignis)
Ein anderes Problem im Zusammenhang mit der getakteten Abrechnung

Um die Supportoptionen für Herausgeber zu verstehen und ein Supportticket für Microsoft zu öffnen, befolgen Sie die Anweisungen unter Support für das Programm „Kommerzieller Marketplace“ im Partner Center.

Freigeben über

Getaktete Abrechnung für Azure-Container mit dem kommerziellen Marketplace-Metering-Dienst

Voraussetzungen für die getaktete Abrechnung

Zusammenspiel von getakteter Abrechnung und Preisgestaltung

Beispiel für benutzerdefinierte Preisoptionen

Abrechnungsdimensionen

Festlegen des Dimensionspreises pro Einheit und unterstütztem Markt

Privater Tarif

Einschränkungen

Sperrverhalten

Obergrenzen

Getaktete Abrechnung für Azure-Container

Erzwingen der TLS 1.2-Notiz

Einzelnes Nutzungsereignis für getaktete Abrechnung

Antworten

Batchnutzungsereignis für getaktete Abrechnung

Antworten

Getaktete Abrechnung für das Abrufen von Nutzungsereignissen

Antworten

Bewährte Methoden für Entwicklung und Test

Support

Feedback

Zusätzliche Ressourcen

Freigeben über

Getaktete Abrechnung für Azure-Container mit dem kommerziellen Marketplace-Metering-Dienst

Voraussetzungen für die getaktete Abrechnung

Zusammenspiel von getakteter Abrechnung und Preisgestaltung

Beispiel für benutzerdefinierte Preisoptionen

Abrechnungsdimensionen

Festlegen des Dimensionspreises pro Einheit und unterstütztem Markt

Privater Tarif

Einschränkungen

Sperrverhalten

Obergrenzen

Getaktete Abrechnung für Azure-Container

Erzwingen der TLS 1.2-Notiz

Einzelnes Nutzungsereignis für getaktete Abrechnung

Antworten

Batchnutzungsereignis für getaktete Abrechnung

Antworten

Getaktete Abrechnung für das Abrufen von Nutzungsereignissen

Antworten

Bewährte Methoden für Entwicklung und Test

Zugehöriger Inhalt

Support

Feedback

Zusätzliche Ressourcen