Fakturace účtovaná podle měrného využití kontejnerů Azure pomocí služby měření komerčního marketplace

Pomocí služby měření komerčního marketplace můžete vytvořit nabídky kontejnerů Azure, které se účtují podle nestandardních jednotek. Před publikováním nabídky na komerční marketplace definujete dimenze fakturace, jako je šířka pásma, horizontální oddíly, soubory protokolů, skenování, zpracovávané e-maily atd. Zákazníci pak platí podle jejich spotřeby těchto dimenzí a vaše aplikace informuje Microsoft prostřednictvím rozhraní API služby měření komerčního marketplace o fakturovatelných událostech, jak k nim dojde.

Požadavky na fakturaci účtované podle měrného využití

Pokud chcete, aby nabídka kontejneru Azure používala fakturaci účtovanou podle měřených dat, musíte si nejprve projít možnosti licencování uvedené v části Plán pro kontejner Azure a ujistit se, že máte vlastní potřeby fakturace, které nejsou splněné jedním ze šesti existujících předdefinovaných fakturačních modelů.

Nabídka kontejneru Azure se pak může integrovat s rozhraními API služby měření komerčního marketplace a informovat Microsoft o fakturovatelných událostech.

Důležité

Vaše aplikace bude muset volat rozhraní API služby měření komerčního marketplace. V současné době není k dispozici možnost povolit hostované službě (mimo aplikaci) volání rozhraní API služby měření.

Poznámka:

Služba měření marketplace je dostupná jenom pro vlastní fakturační model a nevztahuje se na model fakturace jednotlivých uživatelů.

Jak je fakturace na základě měření v souladu s cenami

Pochopení hierarchie nabídek je důležité, pokud jde o definování nabídky spolu s jeho cenovými modely.

• Každá nabídka je nakonfigurovaná tak, aby prodala buď prostřednictvím Microsoftu, nebo ne. Po publikování nabídky se tato možnost nedá změnit.
• Každá nabídka nakonfigurovaná k prodeji prostřednictvím Microsoftu může mít jeden nebo více plánů.
• Každý plán má přidružený cenový model: měsíční fakturovaný plán založený na využití nebo používání vlastní licence (BYOL). V případě měsíčního fakturačního plánu založeného na využití můžete zvolit bezplatnou možnost, jednu ze šesti předdefinovaných možností fakturace nebo vlastní.
• Po publikování nelze aktualizovat cenový model a možnosti vstupu cen.
• Každý plán musí mít úplný cenový plán.
• Pokud chcete zákazníkům účtovat poplatky, abyste mohli vyhovět vašim potřebám fakturace, můžete si vybrat cenu pomocí vlastních dimenzí. Každá dimenze představuje fakturovatelnou jednotku, kterou vaše služba komunikuje s Microsoftem pomocí rozhraní API služby měření komerčního marketplace.

Důležité

Musíte mít přehled o využití v kódu a odesílat do Microsoftu jenom události využití pro využití, které chcete zákazníkovi fakturovat.

Poznámka:

Nabídky se budou účtovat zákazníkům v měně smlouvy se zákazníky s použitím místní tržní ceny publikované v okamžiku vytvoření nabídky. Částka, kterou zákazníci platí a že nezávislí výrobci softwaru platí, závisí na kurzech cizích měn v okamžiku, kdy zákazník vymění nabídku. Přečtěte si další informace o tom, jak převést měnu.

Ukázkové vlastní cenové možnosti

Contoso je například vydavatel, jehož IP adresa je v logice horizontálního dělení pro aplikaci Kubernetes. Společnost Contoso chce účtovat své zákazníky na základě počtu použitých horizontálních oddílů. Také se seznamují s dalšími pohodlnými a konkurenčními cenami cenových možností fakturace. Společnost Contoso je zaregistrovaná jako vydavatel v Partnerském centru pro program komerčního marketplace a chce publikovat nabídky kontejnerů zákazníkům Azure. K Contoso jsou přidružené čtyři plány, které jsou popsané níže:

• Poplatek za horizontální oddíly použité za hodinu, například 1 000 USD za shard/hodinu

  

• Modelování jednorázové platby nebo opakované fakturace: Řekněme, že Společnost Contoso chce zákazníkovi účtovat 449 USD za využití až 100 souborů protokolu ze své aplikace. Logika aplikace společnosti Contoso sleduje událost využití pro měsíc a aktivuje poplatky na konci měsíce za využití 100 souborů protokolu.

  

• Modeling tiered billing: Řekněme, že Contoso chce účtovat 449 USD za více než 100 horizontálních oddílů a následně vrstvit ceny za nadlimitní využití. Logika aplikace by na konci období sledovala využití za měsíc, odpovídajícím způsobem segmentovala využití a hlásila ho pomocí následujících rozhraní API pro měření:

  

• Multidimenzionální fakturace: Společnost Contoso může také použít vlastní měření, aby vyhovovala potřebám pokročilé fakturace s využitím více dimenzí.

  

Na základě vybraného plánu se zákazníkovi Azure, který získá nabídku kontejneru Contoso, účtuje na základě využití. Společnost Contoso spočítá využití bez odesílání událostí využití do Microsoftu. Buď když zákazníci spotřebovávají odpovídající částku, nebo pravidelně, společnost Contoso hlásí využití. Zákazníci nemusí měnit plány ani dělat nic jiného. Společnost Contoso měří využití a začne do Microsoftu generovat události využití pro účtování nadlimitního využití pomocí rozhraní API služby měření komerčního marketplace. Microsoft zase účtuje zákazníkovi za využití podle specifikace vydavatele ve vlastních dimenzích. Fakturace se provádí v dalším měsíčním fakturačním období.

Dimenze fakturace

Každá dimenze fakturace definuje vlastní jednotku, pomocí které může výrobce softwaru generovat události využití. Dimenze fakturace se také používají ke komunikaci se zákazníkem o tom, jak se bude fakturovat za používání softwaru. Jsou definovány takto:

• ID: neměnný identifikátor dimenze odkazovaný při generování událostí využití.
• Zobrazovaný název: zobrazovaný název přidružený k dimenzi, například "odeslané textové zprávy".
• Měrná jednotka: popis fakturační jednotky, například "za textovou zprávu" nebo "na 100 e-mailů".
• Cena za jednotku v USD: cena za jednu jednotku dimenze. Může to být 0.

Důležité

Na základě vašich potřeb fakturace musíte sledovat využití v kódu aplikace a odesílat události využití Do Microsoftu.

Dimenze fakturace se sdílejí napříč všemi plány nabídky. Některé atributy se vztahují na dimenzi napříč všemi plány a další atributy jsou specifické pro plán.

Atributy, které definují samotnou dimenzi, se sdílejí napříč všemi plány nabídky. Před publikováním nabídky ovlivní změna těchto atributů z kontextu libovolného plánu definici dimenze ve všech plánech. Jakmile nabídku publikujete, nebudou už tyto atributy možné upravovat. Jsou to tyto atributy:

• ID
• Zobrazovaný název
• Měrná jednotka

Ostatní atributy dimenze jsou specifické pro každý plán a můžou mít různé hodnoty od plánu k plánování. Než plán publikujete, můžete tyto hodnoty upravit a ovlivní to jenom tento plán. Jakmile plán publikujete, nebudou už tyto atributy možné upravovat. Jsou to tyto atributy:

• Cena za jednotku v USD

Dimenze mají také speciální koncept s názvem "enabled":

• Povoleno označuje, že se tento plán účastní této dimenze. Pokud vytváříte nový plán, který neodesílá události využití na základě této dimenze, můžete tuto možnost ponechat nezaškrtnutou. Všechny nové dimenze přidané po prvním publikování plánu se také zobrazí jako "nepovoleno" u již publikovaného plánu. Zakázaná dimenze se nezobrazí v žádných seznamech dimenzí pro plán, který vidí zákazníci.

Poznámka:

Explicitně se podporují následující scénáře:

• Do nového plánu můžete přidat novou dimenzi. Nová dimenze nebude povolena pro žádné již publikované plány.

Nastavení ceny dimenze na jednotku na podporovaný trh

Stejně jako u jiných cen založených na využití je možné nastavit ceny dimenzí fakturace pro každou podporovanou zemi nebo oblast. V Partnerském centru musíte použít funkci importu a exportu cenových dat, jak je znázorněno níže.

1. Definujte požadované rozměry a označte, které trhy jsou podporovány.
2. Export těchto dat do souboru.
3. Přidejte správné ceny za zemi nebo oblast a importujte soubor v Partnerském centru.

Uživatelské rozhraní měřiče se mění tak, aby odráželo, že ceny dimenze lze zobrazit pouze v souboru.

Soukromý plán

Podobně jako u předdefinovaných fakturačních plánů založených na využití je možné plán s vlastními dimenzemi nastavit jako soukromý plán, který je přístupný jenom pro definovanou cílovou skupinu plánu.

Omezení

Chování uzamčení

Vzhledem k tomu, že dimenze použitá se službou měření komerčního marketplace představuje pochopení způsobu platby zákazníkem za službu, nebudou se po publikování už upravovat všechny podrobnosti o dimenzi. Před publikováním je důležité, abyste měli plně definované dimenze pro plán.

Jakmile je nabídka publikovaná s dimenzí, podrobnosti na úrovni nabídky pro danou dimenzi se už nedají změnit:

• ID
• Zobrazovaný název
• Měrná jednotka

Po publikování plánu už nelze toto podrobnosti na úrovni plánu změnit:

• Zda je dimenze pro plán povolena, nebo ne

Horní limity

Maximální počet dimenzí, které je možné nakonfigurovat pro jednu nabídku, je 30 jedinečných dimenzí.

Fakturace účtovaná podle měrného kontejneru Azure

Účtovaná rozhraní API pro fakturaci by se měla použít, když vydavatel vytvoří vlastní dimenze měření pro nabídku, která se má publikovat v Partnerském centru. Integrace s účtovanými rozhraními API pro fakturaci se vyžaduje pro každou zakoupenou nabídku, která má jeden nebo více plánů s vlastními dimenzemi k generování událostí využití.

Důležité

Další informace o vytváření vlastních dimenzí měření pro Kubernetes Apps najdete v tématu Vytvoření nabídky kontejnerů Azure.

Vynucování poznámky TLS 1.2

Verze PROTOKOLU TLS 1.2 se vynucuje jako minimální verze komunikace HTTPS. Ujistěte se, že ve svém kódu používáte tuto verzi protokolu TLS. Protokoly TLS verze 1.0 a 1.1 jsou zastaralé a pokusy o připojení jsou odmítnuty.

Událost jednorázového využití účtované podle měrného využití

Rozhraní API události využití by mělo být volána vydavatelem, aby vygeneroval události využití pro aktivní prostředek (přihlášený) pro plán zakoupený konkrétním zákazníkem. Událost využití se vygeneruje zvlášť pro každou vlastní dimenzi plánu definovanou vydavatelem při publikování nabídky.

Pro každou hodinu kalendářního dne na zdroj a dimenzi je možné vygenerovat pouze jednu událost využití. Pokud se spotřebuje více než jedna jednotka za hodinu, kumulujte všechny jednotky spotřebované v hodině a pak je vygenerujte v jedné události. Události využití je možné vygenerovat pouze za posledních 24 hodin. Pokud událost využití vygenerujete kdykoli mezi 8:00 a 8:59:59 (a akceptuje se) a odešlete jinou událost pro stejný den mezi 8:00 a 8:59:59, bude odmítnuta jako duplicitní.

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

Parametry dotazu:

Parametr	Doporučení
ApiVersion	Použijte 31. 8. 2018.

Hlavičky požadavku:

Typ obsahu	Použití application/json
x-ms-requestid	Jedinečná řetězcová hodnota pro sledování požadavku od klienta, nejlépe identifikátor GUID. Pokud tato hodnota není zadaná, vygeneruje se a zadává se v hlavičce odpovědi.
x-ms-correlationid	Jedinečná hodnota řetězce pro operaci v klientovi. Tento parametr koreluje všechny události z operace klienta s událostmi na straně serveru. Pokud tato hodnota není zadaná, vygeneruje se a zadává se v hlavičce odpovědi.
authorization	Jedinečný přístupový token, který identifikuje výrobce softwaru, který provádí toto volání rozhraní API. Formát je "Bearer <access_token>" , když vydavatel načte hodnotu tokenu, jak je vysvětleno v aplikaci Kubernetes ve strategiích ověřování.

Příklad textu požadavku:

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

Poznámka:

U aplikací resourceUri Kubernetes je identifikátor URI prostředku ARM instance aplikace Kubernetes.

Odpovědi

Kód: 200
OK. Emise využití byly přijaty a zaznamenány na straně Microsoftu pro další zpracování a fakturaci.

Příklad datové části odpovědi:

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

Kód: 400
Chybný požadavek.

• Byla nalezena chybějící nebo neplatná data žádosti.
• effectiveStartTime je v minulosti více než 24 hodin. Vypršela platnost události.

Příklad datové části odpovědi:

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

Kód: 400
Chybný požadavek.

• Identifikátor URI prostředku je již zaregistrovaný dříve, před odesláním využití je potřeba počkat na 24 hodin.

Příklad datové části odpovědi:

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

Kód: 403

Zakázaný. Autorizační token není zadaný, je neplatný nebo vypršela jeho platnost.

Kód: 409
Konflikt. Událost využití již byla úspěšně hlášena pro zadané ID prostředku, datum efektivního využití a hodinu.

Příklad datové části odpovědi:

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

Událost dávkového využití účtované podle měrného využití

Rozhraní API událostí dávkového využití umožňuje generovat události využití pro více než jeden zakoupený prostředek najednou. Umožňuje také generovat několik událostí využití pro stejný prostředek, pokud jsou pro různé kalendářní hodiny. Maximální počet událostí v jedné dávce je 25.

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

Parametry dotazu:

Parametr	Doporučení
ApiVersion	Použijte 31. 8. 2018.

Hlavičky požadavku:

Typ obsahu	Použití application/json
x-ms-requestid	Jedinečná řetězcová hodnota pro sledování požadavku od klienta, nejlépe identifikátor GUID. Pokud tato hodnota není zadaná, vygeneruje se jedna a zadává se do hlaviček odpovědi.
x-ms-correlationid	Jedinečná hodnota řetězce pro operaci v klientovi. Tento parametr koreluje všechny události z operace klienta s událostmi na straně serveru. Pokud tato hodnota není zadaná, vygeneruje se a zadává se v hlavičce odpovědi.
authorization	Jedinečný přístupový token, který identifikuje výrobce softwaru, který provádí toto volání rozhraní API. Formát je Bearer <access_token> , když vydavatel načte hodnotu tokenu, jak je vysvětleno v aplikaci Kubernetes ve strategiích ověřování.

Poznámka:

V textu požadavku je resourceUriidentifikátor prostředku pro aplikace Kubernetes .

Základní příklad požadavku pro aplikace 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
    }
  ]
}

Odpovědi

Kód: 200
OK. Emise dávkového využití byly přijaty a zaznamenány na straně Microsoftu pro další zpracování a fakturaci. Seznam odpovědí se vrátí se stavem každé jednotlivé události v dávce. Měli byste iterovat datovou část odpovědi, abyste porozuměli odpovědím pro každou jednotlivou událost využití poslanou jako součást dávkové události.

Příklad datové části odpovědi:

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

Popis stavového kódu odkazovaného v BatchUsageEvent odpovědi rozhraní API:

Stavový kód	Popis
Accepted	Přijal.
Expired	Platnost vypršela.
Duplicate	Bylo poskytnuto duplicitní využití.
Error	Kód chyby
ResourceNotFound	Zadaný prostředek využití je neplatný.
ResourceNotAuthorized	Nemáte oprávnění k poskytování využití pro tento prostředek.
ResourceNotActive	Prostředek je pozastavený nebo se nikdy neaktivoval.
InvalidDimension	Dimenze, pro kterou je využití předáno, je pro tuto nabídku nebo plán neplatná.
InvalidQuantity	Předané množství je nižší nebo rovno 0.
BadArgument	Vstup chybí nebo je poškozený.

Kód: 400
Chybný požadavek. Dávka obsahovala více než 25 událostí využití.

Kód: 403
Zakázaný. Autorizační token není zadaný, je neplatný nebo vypršela jeho platnost.

Načítá události využití účtované podle měřených dat fakturace

Pokud chcete získat seznam událostí využití, můžete volat rozhraní API událostí využití. Nezávislí výrobci softwaru můžou toto rozhraní API použít k zobrazení událostí využití, které byly publikovány po určitou konfigurovatelnou dobu a jaký stav jsou tyto události v okamžiku volání rozhraní API.

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

Parametry dotazu:

Parametr	Doporučení
ApiVersion	Použijte 31. 8. 2018.
usageStartDate	DateTime ve formátu ISO8601. Například 2020-12-03T15:00 nebo 2020-12-03
UsageEndDate (volitelné)	DateTime ve formátu ISO8601. Výchozí = aktuální datum
offerId (volitelné)	Výchozí = vše k dispozici
planId (volitelné)	Výchozí = vše k dispozici
dimenze (volitelné)	Výchozí = vše k dispozici
azureSubscriptionId (volitelné)	Výchozí = vše k dispozici
reconStatus (volitelné)	Výchozí = vše k dispozici

Možné hodnoty reconStatus:

ReconStatus	Popis
Odesláno	Dosud nezpracované službou PC Analytics
Přijato	Spárováno s analýzou počítačů
Zamítnuto	Odmítnuto v kanálu. Pokud chcete zjistit příčinu, obraťte se na podporu Microsoftu.
Neshoda	Množství Analýz MarketplaceAPI a Partnerského centra jsou nenulové, ale neodpovídají
TestHeaders	Předplatné uvedené s testovacími hlavičkami, a proto není v analýze pc
DryRun	Odesláno s SessionMode=DryRun, a proto není v počítači PC

Hlavičky požadavku:

Typ obsahu	Použití application/json
x-ms-requestid	Jedinečná řetězcová hodnota (nejlépe IDENTIFIKÁTOR GUID) pro sledování požadavku od klienta. Pokud tato hodnota není zadaná, vygeneruje se a zadává se v hlavičce odpovědi.
x-ms-correlationid	Jedinečná hodnota řetězce pro operaci v klientovi. Tento parametr koreluje všechny události z operace klienta s událostmi na straně serveru. Pokud tato hodnota není zadaná, vygeneruje se a zadává se v hlavičce odpovědi.
autorizace	Jedinečný přístupový token, který identifikuje výrobce softwaru, který provádí toto volání rozhraní API. Formát je Bearer <access_token> , když vydavatel načte hodnotu tokenu. – Aplikace Kubernetes ve strategiích ověřování

Odpovědi

Příklady datové části odpovědi:

Přijal

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

Odesláno

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

Neshoda

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

Odmítnuto

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

Stavové kódy

Kód: 403 Zakázáno. Autorizační token není zadaný, je neplatný nebo vypršela jeho platnost.

Osvědčené postupy vývoje a testování

Pokud chcete otestovat emise vlastního měřiče, implementujte integraci s rozhraním API pro měření, vytvořte plán pro vaši publikovanou nabídku Aplikací Kubernetes s vlastními dimenzemi definovanými s nulovou cenou za jednotku. Tuto nabídku publikujte jako verzi Preview, aby k integraci měli přístup a otestování jenom omezený uživatelé.

Pokud chcete omezit přístup k tomuto plánu během testování na omezenou cílovou skupinu, můžete také použít soukromý plán pro existující živou nabídku.

Související obsah

• Další informace o rozhraních API služby měření najdete v tématu Nejčastější dotazy k rozhraním API služby měření na Marketplace.

Získání podpory

Pokud máte některý z následujících problémů, můžete otevřít lístek podpory.

• Technické problémy s rozhraním API služby měření marketplace
• Problém, který je potřeba eskalovat kvůli chybě nebo chybě na vaší straně (např. kvůli nesprávné události použití).
• Všechny další problémy související s fakturací účtovanou podle měrného využití

Pokud chcete porozumět možnostem podpory vydavatele a otevřít lístek podpory u Microsoftu, postupujte podle pokynů v části Podpora programu komerčního marketplace v Partnerském centru.