Faturação limitada para Contentores do Azure utilizando o serviço de medição do mercado comercial

Artigo
06/14/2024

Com o serviço de medição do mercado comercial, você pode criar ofertas de Contêiner do Azure que são cobradas de acordo com unidades não padrão. Antes de publicar a oferta no mercado comercial, você define as dimensões de faturamento, como largura de banda, fragmentos, arquivos de log, digitalizações, e-mails processados, etc. Em seguida, os clientes pagam de acordo com o seu consumo destas dimensões, com a sua aplicação a informar a Microsoft, através da API do serviço de medição do mercado comercial, dos eventos faturáveis à medida que ocorrem.

Pré-requisitos para faturamento medido

Para que uma oferta de Contentor do Azure utilize faturação com tráfego limitado, tem primeiro de rever as opções de Licenciamento descritas na oferta Planear Contentor do Azure e certificar-se de que tem necessidades de faturação personalizadas que não são satisfeitas por um dos seis modelos de faturação predefinidos existentes.

Em seguida, a oferta do Contêiner do Azure pode se integrar às APIs do serviço de medição do mercado comercial para informar a Microsoft sobre eventos faturáveis.

Importante

Seu aplicativo terá que chamar as APIs do serviço de medição do mercado comercial. Atualmente, não há uma opção para permitir que seu serviço hospedado (fora do aplicativo) chame a API do serviço de monitoramento.

Nota

O serviço de medição do Marketplace está disponível apenas para o modelo de faturamento personalizado e não se aplica ao modelo de faturamento por usuário.

Como a faturação limitada se enquadra nos preços

Entender a hierarquia da oferta é importante quando se trata de definir a oferta juntamente com seus modelos de preços.

Cada oferta está configurada para ser vendida através da Microsoft ou não. Depois que uma oferta é publicada, essa opção não pode ser alterada.
Cada oferta, configurada para vender através da Microsoft, pode ter um ou mais planos.
Cada plano tem um modelo de preços associado a ele: plano de faturamento mensal baseado no uso ou Traga sua própria licença (BYOL). Para o plano de faturamento mensal baseado no uso, você pode escolher gratuito, uma das seis opções de faturamento predefinidas ou personalizado.
O modelo de preços e as opções de entrada de preços não podem ser atualizados depois de publicados.
Cada plano deve ter um plano de preços completo.
Você pode optar por definir o preço usando dimensões personalizadas para cobrar seus clientes para ajudar a atender às suas necessidades de cobrança. Cada dimensão representa uma unidade faturável que seu serviço comunica à Microsoft usando a API do serviço de medição do mercado comercial.

Importante

Tem de controlar a utilização no seu código e enviar apenas eventos de utilização para a Microsoft para a utilização que pretende que o cliente seja faturado.

Nota

As ofertas serão cobradas aos clientes na moeda do contrato do cliente, usando o preço do mercado local que foi publicado no momento em que a oferta foi criada. O valor que os clientes pagam, e que os ISVs são pagos, depende das taxas de câmbio no momento em que o cliente transaciona a oferta. Saiba mais em "Como convertemos moeda?".

Exemplos de opções de preços personalizados

Como exemplo, a Contoso é um editor cujo IP está em sua lógica de fragmentação para seu aplicativo Kubernetes. A Contoso deseja cobrar seus clientes com base no número de fragmentos usados. Eles também estão explorando outras opções de faturamento convenientes e com preços competitivos. A Contoso está registrada como editora no Partner Center para o programa de mercado comercial e deseja publicar ofertas de contêiner para clientes do Azure. Há quatro planos associados à Contoso, descritos abaixo:

Cobrar por estilhaços usados por hora, por exemplo, US$ 1.000/estilhaço/hora
Modelação de pagamento único ou cobrança recorrente: digamos que a Contoso queira cobrar US$ 449/mês de um cliente pelo uso de até 100 arquivos de log de seu aplicativo. A lógica do aplicativo da Contoso controla o evento de uso do mês e aciona uma cobrança no final do mês pelo uso de 100 arquivos de log.
Modelagem de faturamento hierárquico: digamos que a Contoso queira cobrar US$ 449/mês por até 100 fragmentos e, em seguida, preços diferenciados para qualquer excedente. Sua lógica de aplicativo manteria o controle do uso do mês, segmentaria o uso de acordo e o relataria usando as APIs de medição abaixo no final do período:
Cobrança multidimensional: a Contoso também pode usar a medição personalizada para atender às suas necessidades de cobrança avançada usando várias dimensões

Com base no plano selecionado, um cliente do Azure que recebe a oferta de Contêiner Contoso é cobrado com base em seu uso. A Contoso conta o uso sem enviar nenhum evento de uso para a Microsoft. Quando os clientes consomem a quantidade adequada ou periodicamente, a Contoso relata o uso. Os clientes não precisam mudar de planos ou fazer nada diferente. A Contoso mede o uso e começa a emitir eventos de uso para a Microsoft por cobrar o uso excessivo usando a API do serviço de medição do mercado comercial. A Microsoft, por sua vez, cobra do cliente pelo uso, conforme especificado pelo editor nas dimensões personalizadas. A faturação é feita no próximo ciclo de faturação mensal.

Dimensões de faturação

Cada dimensão de faturamento define uma unidade personalizada pela qual o ISV pode emitir eventos de uso. As dimensões de faturamento também são usadas para comunicar ao cliente como ele será cobrado pelo uso do software. Eles são definidos da seguinte forma:

ID: o identificador de dimensão imutável referenciado durante a emissão de eventos de uso.
Nome para exibição: o nome de exibição associado à dimensão, por exemplo, "mensagens de texto enviadas".
Unidade de medida: a descrição da unidade de faturação, por exemplo "por mensagem de texto" ou "por 100 e-mails".
Preço por unidade em USD: o preço de uma unidade de dimensão. Pode ser 0.

Importante

Tem de controlar a utilização no código da sua aplicação e enviar eventos de utilização para a Microsoft com base nas suas necessidades de faturação.

As dimensões de faturamento são compartilhadas em todos os planos de uma oferta. Alguns atributos se aplicam à dimensão em todos os planos, e outros atributos são específicos do plano.

Os atributos, que definem a própria dimensão, são compartilhados em todos os planos de uma oferta. Antes de publicar a oferta, uma alteração feita nesses atributos a partir do contexto de qualquer plano afeta a definição de dimensão em todos os planos. Depois de publicar a oferta, esses atributos não são mais editáveis. Estes atributos são:

ID
Nome a apresentar
Unidade de Medida

Os outros atributos de uma dimensão são específicos de cada plano e podem ter valores diferentes de plano para plano. Antes de publicar o plano, você pode editar esses valores, e somente esse plano será afetado. Depois de publicar o plano, esses atributos não serão mais editáveis. Estes atributos são:

Preço por unidade em USD

As dimensões também têm um conceito especial chamado "habilitado":

Ativado indica que este plano participa nesta dimensão. Se estiver a criar um novo plano que não envie eventos de utilização com base nesta dimensão, poderá querer deixar esta opção desmarcada. Além disso, quaisquer novas dimensões adicionadas após a publicação de um plano pela primeira vez aparecerão como "não habilitadas" no plano já publicado. Uma dimensão desabilitada não aparecerá em nenhuma lista de dimensões de um plano visto pelos clientes.

Nota

Os seguintes cenários são explicitamente suportados:

Você pode adicionar uma nova dimensão a um novo plano. A nova dimensão não será habilitada para nenhum plano já publicado.

Definição do preço de dimensão por unidade por mercado suportado

Tal como outros preços baseados na utilização, os preços da dimensão de faturação podem ser definidos por país ou região suportados. Você precisa usar o recurso de importação e exportação de dados de preços no Partner Center, da seguinte maneira.

Defina as dimensões desejadas e marque quais mercados são suportados.
Exporte esses dados para um arquivo.
Adicione os preços corretos por país/região e importe o arquivo no Partner Center.

A interface do usuário do medidor muda para refletir que os preços da dimensão só podem ser vistos no arquivo.

Plano privado

Como os planos de faturamento baseados no uso predefinidos, um plano com dimensões personalizadas pode ser definido como plano privado, acessível apenas pelo público definido do plano.

Restrições

Comportamento de bloqueio

Como uma dimensão usada com o serviço de medição do mercado comercial representa uma compreensão de como um cliente pagará pelo serviço, todos os detalhes de uma dimensão não são mais editáveis depois que você a publica. É importante que você tenha suas dimensões totalmente definidas para um plano antes de publicar.

Depois que uma oferta é publicada com uma dimensão, os detalhes do nível da oferta para essa dimensão não podem mais ser alterados:

ID
Nome a apresentar
Unidade de Medida

Depois que um plano é publicado, esse detalhe no nível do plano não pode mais ser alterado:

Se a dimensão está habilitada para o plano ou não

Limites superiores

O número máximo de dimensões que podem ser configuradas para uma única oferta é de 30 dimensões únicas.

Faturação limitada do Contentor do Azure

As APIs de faturamento limitado devem ser usadas quando o editor cria dimensões de medição personalizadas para uma oferta a ser publicada no Partner Center. A integração com as APIs de faturamento limitado é necessária para qualquer oferta comprada que tenha um ou mais planos com dimensões personalizadas para emitir eventos de uso.

Importante

Para obter mais informações sobre como criar dimensões de medição personalizadas para aplicativos Kubernetes, consulte Criar uma oferta de contêiner do Azure.

Aplicando a nota TLS 1.2

A versão 1.2 do TLS é imposta como a versão mínima para comunicações HTTPS. Certifique-se de usar esta versão TLS em seu código. As versões 1.0 e 1.1 do TLS foram preteridas e as tentativas de conexão foram recusadas.

Evento de utilização única de faturação com tráfego limitado

A API de eventos de uso deve ser chamada pelo editor para emitir eventos de uso em relação a um recurso ativo (inscrito) para o plano adquirido pelo cliente específico. O evento de uso é emitido separadamente para cada dimensão personalizada do plano definido pelo editor ao publicar a oferta.

Apenas um evento de uso pode ser emitido para cada hora de um dia de calendário por recurso e dimensão. Se mais de uma unidade for consumida em uma hora, acumule todas as unidades consumidas na hora e, em seguida, emite-a em um único evento. Os eventos de utilização só podem ser emitidos nas últimas 24 horas. Se você emitir um evento de uso a qualquer momento entre 8:00 e 8:59:59 (e for aceito) e enviar outro evento para o mesmo dia entre 8:00 e 8:59:59, ele será rejeitado como uma duplicata.

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

Parâmetros de consulta:

Parâmetro	Recomendação
`ApiVersion`	Use 2018-08-31.

Cabeçalhos de solicitação:

Tipo de conteúdo	Utilizar o comando `application/json`
`x-ms-requestid`	Valor de cadeia de caracteres exclusivo para acompanhar a solicitação do cliente, de preferência um GUID. Se esse valor não for fornecido, um será gerado e fornecido nos cabeçalhos de resposta.
`x-ms-correlationid`	Valor de cadeia de caracteres exclusivo para operação no cliente. Este parâmetro correlaciona todos os eventos da operação do cliente com eventos no lado do servidor. Se esse valor não for fornecido, um será gerado e fornecido nos cabeçalhos de resposta.
`authorization`	Um token de acesso exclusivo que identifica o ISV que está fazendo essa chamada de API. O formato é `"Bearer <access_token>"` quando o valor do token é recuperado pelo editor, conforme explicado no aplicativo Kubernetes em Estratégias de autenticação.

Exemplo de corpo de solicitação:

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

Nota

Para aplicativos Kubernetes, o é o resourceUri URI do recurso ARM da instância do Aplicativo Kubernetes.

Respostas

Código: 200
OK. A emissão de uso foi aceita e registrada no lado da Microsoft para processamento e faturamento posteriores.

Exemplo de carga útil de resposta:

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

Código: 400
Mau pedido.

Dados de solicitação ausentes ou inválidos fornecidos.
effectiveStartTime é mais de 24 horas no passado. O evento expirou.

Exemplo de carga útil de resposta:

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

Código: 400
Mau pedido.

O URI do recurso já está registrado anteriormente, precisa aguardar 24 horas antes de enviar o uso.

Exemplo de carga útil de resposta:

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

Código: 403

Proibido. O token de autorização não é fornecido, é inválido ou expirou.

Código: 409
Conflito. Um evento de uso já foi relatado com êxito para a ID do recurso especificado, data de uso efetivo e hora.

Exemplo de carga útil de resposta:

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

Evento de uso do lote de faturamento limitado

A API de eventos de uso em lote permite que você emita eventos de uso para mais de um recurso comprado de uma só vez. Ele também permite que você emita vários eventos de uso para o mesmo recurso, desde que sejam para horas de calendário diferentes. O número máximo de eventos num único lote é 25.

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

Parâmetros de consulta:

Parâmetro	Recomendação
`ApiVersion`	Use 2018-08-31.

Cabeçalhos de solicitação:

Tipo de conteúdo	Utilizar o comando `application/json`
`x-ms-requestid`	Valor de cadeia de caracteres exclusivo para acompanhar a solicitação do cliente, de preferência um GUID. Se esse valor não for fornecido, um será gerado e fornecido nos cabeçalhos de resposta.
`x-ms-correlationid`	Valor de cadeia de caracteres exclusivo para operação no cliente. Este parâmetro correlaciona todos os eventos da operação do cliente com eventos no lado do servidor. Se esse valor não for fornecido, será gerado e fornecido nos cabeçalhos de resposta.
`authorization`	Um token de acesso exclusivo que identifica o ISV que está fazendo essa chamada de API. O formato é `Bearer <access_token>` quando o valor do token é recuperado pelo editor, conforme explicado no aplicativo Kubernetes em Estratégias de autenticação.

Nota

No corpo da solicitação, o identificador de recurso para aplicativos Kubernetes é resourceUri.

Exemplo de corpo de solicitação para aplicativos 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
    }
  ]
}

Respostas

Código: 200
OK. A emissão de uso em lote foi aceita e registrada no lado da Microsoft para processamento e faturamento posteriores. A lista de respostas é retornada com o status de cada evento individual no lote. Você deve iterar através da carga útil de resposta para entender as respostas para cada evento de uso individual enviado como parte do evento em lote.

Exemplo de carga útil de resposta:

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

Descrição do código de status referenciado na BatchUsageEvent resposta da API:

Código de estado	Description
`Accepted`	Aceito.
`Expired`	Uso expirado.
`Duplicate`	Uso duplicado fornecido.
`Error`	Código de erro.
`ResourceNotFound`	O recurso de uso fornecido é inválido.
`ResourceNotAuthorized`	Você não está autorizado a fornecer uso para este recurso.
`ResourceNotActive`	O recurso está suspenso ou nunca foi ativado.
`InvalidDimension`	A dimensão para a qual o uso é passado é inválida para esta oferta/plano.
`InvalidQuantity`	A quantidade passada é menor ou igual a 0.
`BadArgument`	A entrada está ausente ou malformada.

Código: 400
Mau pedido. O lote continha mais de 25 eventos de uso.

Código: 403
Proibido. O token de autorização não é fornecido, é inválido ou expirou.

Faturação limitada recuperar eventos de utilização

Você pode chamar a API de eventos de uso para obter a lista de eventos de uso. Os ISVs podem usar essa API para ver os eventos de uso que foram postados por um determinado período de tempo configurável e qual o estado desses eventos no ponto de chamar a API.

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

Parâmetros de consulta:

Parâmetro	Recomendação
ApiVersion	Use 2018-08-31.
usageStartDate	DateTime no formato ISO8601. Por exemplo, 2020-12-03T15:00 ou 2020-12-03
UsageEndDate (opcional)	DateTime no formato ISO8601. Padrão = data atual
offerId (opcional)	Padrão = todos disponíveis
planId (opcional)	Padrão = todos disponíveis
dimensão (opcional)	Padrão = todos disponíveis
azureSubscriptionId (opcional)	Padrão = todos disponíveis
reconStatus (opcional)	Padrão = todos disponíveis

Valores possíveis de reconStatus:

ReconStatus	Description
Submetido	Ainda não processado pelo PC Analytics
Aceite	Compatível com o PC Analytics
Rejeitado	Rejeitado na calha. Entre em contato com o suporte da Microsoft para investigar a causa.
Incompatibilidade	As quantidades do MarketplaceAPI e do Partner Center Analytics são diferentes de zero, mas não correspondem
TestHeaders	Subscrição listada com cabeçalhos de teste e, portanto, não no PC Analytics
DryRun [en]	Enviado com SessionMode=DryRun e, portanto, não no PC

Cabeçalhos de solicitação:

Tipo do conteúdo	Usar application/json
X-MS-RequestID	Valor de string exclusivo (de preferência um GUID), para acompanhar a solicitação do cliente. Se esse valor não for fornecido, um será gerado e fornecido nos cabeçalhos de resposta.
X-MS-CorrelationID	Valor de cadeia de caracteres exclusivo para operação no cliente. Este parâmetro correlaciona todos os eventos da operação do cliente com eventos no lado do servidor. Se esse valor não for fornecido, um será gerado e fornecido nos cabeçalhos de resposta.
autorização	Um token de acesso exclusivo que identifica o ISV que está fazendo essa chamada de API. O formato é `Bearer <access_token>` quando o valor do token é recuperado pelo editor. - Aplicação Kubernetes em estratégias de Autenticação

Respostas

Exemplos de carga útil de resposta:

Aceito

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

Submetido

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

Incompatibilidade

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

Rejeitado

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

Códigos de status

Código: 403 Proibido. O token de autorização não é fornecido, é inválido ou expirou.

Melhores práticas de desenvolvimento e teste

Para testar a emissão de medidores personalizados, implemente a integração com a API de medição, crie um plano para sua oferta publicada de aplicativos Kubernetes com dimensões personalizadas definidas nela com preço zero por unidade. E publique esta oferta como pré-visualização para que apenas utilizadores limitados possam aceder e testar a integração.

Você também pode usar o plano privado para uma oferta ao vivo existente para limitar o acesso a esse plano durante o teste para um público limitado.

Para obter mais informações sobre APIs de serviço de monitorização, consulte Perguntas frequentes sobre APIs de serviço de medição do Marketplace.

Obter suporte

Se você tiver um dos seguintes problemas, poderá abrir um tíquete de suporte.

Problemas técnicos com a API do serviço de medição do marketplace.
Um problema que precisa ser escalado devido a um erro ou bug do seu lado (por exemplo, evento de uso errado).
Quaisquer outras questões relacionadas com a faturação com contagem.

Para entender as opções de suporte do editor e abrir um tíquete de suporte com a Microsoft, siga as instruções em Suporte para o programa de mercado comercial no Partner Center.

Partilhar via

Faturação limitada para Contentores do Azure utilizando o serviço de medição do mercado comercial

Pré-requisitos para faturamento medido

Como a faturação limitada se enquadra nos preços

Exemplos de opções de preços personalizados

Dimensões de faturação

Definição do preço de dimensão por unidade por mercado suportado

Plano privado

Restrições

Comportamento de bloqueio

Limites superiores

Faturação limitada do Contentor do Azure

Aplicando a nota TLS 1.2

Evento de utilização única de faturação com tráfego limitado

Respostas

Evento de uso do lote de faturamento limitado

Respostas

Faturação limitada recuperar eventos de utilização

Respostas

Melhores práticas de desenvolvimento e teste

Obter suporte

Comentários

Recursos adicionais

Partilhar via

Faturação limitada para Contentores do Azure utilizando o serviço de medição do mercado comercial

Pré-requisitos para faturamento medido

Como a faturação limitada se enquadra nos preços

Exemplos de opções de preços personalizados

Dimensões de faturação

Definição do preço de dimensão por unidade por mercado suportado

Plano privado

Restrições

Comportamento de bloqueio

Limites superiores

Faturação limitada do Contentor do Azure

Aplicando a nota TLS 1.2

Evento de utilização única de faturação com tráfego limitado

Respostas

Evento de uso do lote de faturamento limitado

Respostas

Faturação limitada recuperar eventos de utilização

Respostas

Melhores práticas de desenvolvimento e teste

Conteúdos relacionados

Obter suporte

Comentários

Recursos adicionais