Getaktete Abrechnung für Azure-Container mit dem kommerziellen Marketplace-Metering-Dienst
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.
effectiveStartTimeliegt 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.
Nächste Schritte
- 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.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter: https://aka.ms/ContentUserFeedback.
Einreichen und Feedback anzeigen für