Fakturace měřená pro kontejnery Azure pomocí služby měření komerčního tržiště
Pomocí služby měření v komerčním tržišti můžete vytvářet nabídky kontejnerů Azure, které jsou účtovány 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í. Vaše aplikace informuje Microsoft prostřednictvím rozhraní API služby měření komerčního marketplace fakturovatelných událostí, jak k nim dochází.
Požadavky na měřenou fakturaci
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ých v plánu pro nabídku kontejnerů Azure a ujistěte se, že máte vlastní fakturační potřeby, které nejsou splněné jedním z šesti existujících předdefinovaných fakturačních modelů.
Nabídka kontejneru Azure se pak může integrovat s rozhraními API pro měření komerčního trhu , která informují 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 zapadá účtování podle spotřeby do cenotvorby
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 přineste si vlastní licenci (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 kolik nezávislí výrobci softwaru dostávají zaplaceno, závisí na kurzech cizích měn v okamžiku, kdy zákazník provede transakci s nabídkou. Přečtěte si další informace o "Jak převedeme měnu?".
Ukázkové přizpůsobené cenové možnosti
Contoso je například vydavatel, jehož duševní vlastnictví spočívá v sharding logice pro jejich aplikaci Kubernetes. Společnost Contoso chce účtovat své zákazníky na základě počtu použitých datových oddílů. Také zkoumají další pohodlné a cenově konkurenceschopné možnosti 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 shardy použité za hodinu, například 1 000 USD/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.
Modelování stupňovitého účtování: Řekněme, že Contoso chce účtovat 449 $/měsíc za až 100 shardů a následně stupňovité ceny za veškerý nadlimitní objem. 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 odesílat události využití do Microsoftu pro účely účtování překročení 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í.
Fakturační dimenze
Každá dimenze fakturace definuje vlastní jednotku, pomocí které může výrobce softwaru zaznamenávat události využití. Rozměry fakturace se také používají k tomu, aby zákazníkům sdělovaly, jak budou účtovány poplatky za používání softwaru. Jsou definovány takto:
- ID: neměnný identifikátor dimenze, na který odkazuje při generování událostí použití.
- zobrazený název: zobrazený název přidružený k dimenzi, například "odeslané textové zprávy".
- měrná jednotka: popis fakturační jednotky, například "po textové zprávě" nebo "po 100 e-mailech".
- Cena za jednotku v USD: cena za jednu jednotku dimenze. Může to být 0.
Důležitý
Musíte sledovat využití ve vašem aplikačním kódu a odesílat události využití do Microsoftu na základě vašich potřeb fakturace.
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. Mezi tyto atributy patří:
- 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. Mezi tyto atributy patří:
- 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. Dimenze, která je zakázaná, se nezobrazí v žádných seznamech dimenzí u plánu, 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í rozměrové ceny na jednotku pro každý 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.
- Definujte požadované rozměry a označte, které trhy jsou podporovány.
- Export těchto dat do souboru.
- 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í
Protože dimenze využívaná se službou monitorování komerčního marketplace vyjadřuje dohodu o tom, jak zákazník bude za službu platit, veškeré podrobnosti o dimenzi už po jejím zveřejnění nelze upravovat. 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 za měřenou spotřebu kontejnerů 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 rozhraními API pro účtování podle spotřeby je vyžadována pro každou zakoupenou nabídku, která má jeden nebo více plánů s vlastními dimenzemi k zaznamenávání událostí spotřeby.
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.
Poznámka k vynucování 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.
Jednorázová událost s účtováním podle měřidla
Rozhraní API události využití by mělo být voláno poskytovatelem, aby generovalo události využití u aktivního prostředku (přihlášeného) 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 :
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
Pro aplikace Kubernetes je resourceUri 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.
-
effectiveStartTimeje 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 již byl dříve zaregistrován, před odesláním využití je potřeba počkat 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 zatížení 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í při měřeném účtování
Rozhraní API událostí dávkového využití umožňuje najednou odesílat události využití pro více zakoupených prostředků. 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žijte 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 nezávislého dodavatele softwaru, který provádí toto volání API. Formát je Bearer <access_token>, jakmile je hodnota tokenu načtena vydavatelem, jak je vysvětleno v aplikaci Kubernetes v strategiích ověřování. |
Poznámka
V textu požadavku je identifikátor prostředku pro aplikace Kubernetes resourceUri.
příklad textu 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í je vrácen včetně stavu pro každou jednotlivou událost v dávkovém zpracování. 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 odpovědi rozhraní API BatchUsageEvent:
| Stavový kód | Popis |
|---|---|
Accepted |
Přijato. |
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í poskytovat informace o využití tohoto zdroje. |
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čtení událostí využití pro měřenou fakturaci
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. |
| datumZačátkuPoužívání | Datum a čas ve formátu ISO8601. Například 2020-12-03T15:00 nebo 2020-12-03 |
| UsageEndDate (volitelné) | Datum a čas 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 parametrů stavu obnovení:
| ReconStatus | Popis |
|---|---|
| Předložený | Dosud nezpracované službou PC Analytics |
| Přijato | Spárováno s analýzou počítačů |
| Odmítnutý | Odmítnuto v procesu. 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 PC Analytics. |
| DryRun | Odesláno s SessionMode=DryRun, a proto není v počítači PC |
Hlavičky požadavku:
Odpovědi
Příklady datové části odpovědi:
Přijato
[
{
"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
}
]
odeslané
[
{
"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 Rozhraní API služby měření marketplace – nejčastější dotazy.
Získání podpory
Pokud máte některý z následujících problémů, můžete otevřít podpůrný tiket.
- 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í).
- Jakékoliv další problémy související s fakturací podle měření.
Pokud chcete porozumět možnostem podpory vydavatele a vystavit žádost o podporu u Microsoftu, postupujte podle pokynů uvedených v Podpora pro program komerčního trhu v Partnerském centru.