- Introdução
- Sobre OData e referências
- Tipos enumerados
- Autenticando
- Criação de solicitações de API
- Permissões por endpoint
- Códigos de resposta
- Pontos de extremidade de verificação de integridade
- Definição do Swagger
- APIs do Orchestrator
- Solicitações de alertas
- Solicitações de ativos
- Solicitações de calendários
- Solicitações de ambientes
- Solicitações de pastas
- Solicitações de Tarefas Genéricas
- Solicitações de trabalhos
- Solicitações de bibliotecas
- Solicitações de licenças
- Solicitações de pacotes
- Solicitações de permissões
- Solicitações de processos
- Solicitações de robôs
- Solicitações de funções
- Solicitações de agendamentos
- Solicitações de configurações
- Solicitações de tarefas
- Solicitações de catálogos de tarefas
- Solicitações de formulários de tarefas
- Solicitações de tenants
- Solicitações de Transações
- Solicitações de usuários
- Solicitações de webhooks
Pontos de extremidade de verificação de integridade
Certifique-se de que todos os seus serviços estejam funcionando, fazendo chamadas de API para endpoints especiais, chamados endpoints de verificação de integridade.
Esses endpoints executam verificações de integridade e retornam um status que informa se o serviço que você está verificando está funcionando ou não.
Para verificar a disponibilidade de sua instância do Orchestrator e suas dependências, use os seguintes endpoints:
-
Obter
https://{yourDomain}/api/health
— verifica apenas dependências críticas -
Obter
https://{yourDomain}/api/health/startup
— verifica todas as dependências
Por padrão, os endpoints de verificação de integridade acima retornam um corpo de resposta vazio.
Para ver quais verificações de integridade foram realizadas e os status que elas possuem:
- No
orchestrator-customconfig
mapa de configuração (configurado viaorchestrator-configurator.sh
) eadicione<add key="HealthCheck.DetailsKey" value="12345" />
na seção<appsettings>
.12345
serve como uma senha que permite acessar as verificações de integridade. Portanto, não se esqueça de alterá-la com um valor próprio. - Reinicie o IIS para garantir que a alteração entre em vigor.
- Use a senha definida anteriormente como um parâmetro de consulta na chamada de API de verificação de integridade (por exemplo,
/api/health?detailsKey=password
). Se for bem-sucedida, a chamada retorna um corpo de resposta contendo detalhes sobre as verificações de integridade e seus status.
Depois de concluir essas etapas, a verificação de integridade também será acessível a partir de uma máquina diferente do servidor do Orchestrator.
Para verificar se o servidor de identidade está funcionando, use o seguinte endpoint:
-
OBTER
https://{yourDomain}/identity/health
O corpo da resposta desse endpoint resume a configuração do Identity Server.
{
"status": "Healthy",
"results": {
"ApplicationDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"AuditDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"PersistedGrantDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"IdentityServerConfigurationDbContext": {
"status": "Healthy",
"description": null,
"data": {}
}
}
}
{
"status": "Healthy",
"results": {
"ApplicationDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"AuditDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"PersistedGrantDbContext": {
"status": "Healthy",
"description": null,
"data": {}
},
"IdentityServerConfigurationDbContext": {
"status": "Healthy",
"description": null,
"data": {}
}
}
}
Um código de erro 500 sinaliza um status não saudável, mas ainda pode retornar um corpo de resposta. Verifique o conteúdo do corpo da resposta para descobrir os motivos.
Para verificar a disponibilidade do seu serviço Webhooks, use o seguinte endpoint:
-
OBTER
https://{yourDomain}/webhooks/api/status
Interprete o código de resposta da seguinte maneira:
200 OK
—seu serviço está funcionando5xx
falha—seu serviço está inativo
200 OK
e um status Degraded
, o que significa que o componente verificado está em um estado degradado.