Pular para o conteúdo principal
Um parceiro pode chamar o Flowker com uma credencial própria. No Flowker, você restringe essa credencial a alguns workflows. Esta página mostra como escolher esse escopo, o que ele alcança e o que o parceiro recebe quando sai dele. Todo parceiro do Flowker precisa de escopo.

​
Passo a passo

1

Escolha os workflows do parceiro

O Flowker tem uma restrição. O campo na API é o field de uma entrada de escopo; o Console mostra o nome da primeira coluna.O catálogo de escopo lista a restrição do Flowker. Leia-o com Consultar o catálogo de escopo de um produto para flowker.Algumas regras valem para todo escopo:
  • Uma requisição que não nomeia um workflow é recusada. Por exemplo, um parceiro não pode listar as execuções sem filtrar pelo workflow dele.
  • Uma requisição que lista vários workflows numa query é recusada quando qualquer um deles está fora do escopo.
2

Dê ao parceiro as permissões e o escopo

Crie o parceiro, ou altere-o, no Console ou com a API do Identity. O identificador do produto é flowker.
  • Adicione a entrada de escopo workflowId, com um ou mais workflows. Sem ela, o Access Manager recusa o parceiro com 400 e IDE-1060.
  • Marque os recursos e as ações. O máximo que você pode dar é o que o papel flowker-editor-role tem no seu tenant. Acima disso, o Access Manager recusa com IDE-1043. Por exemplo, catalog com create está acima desse papel.
Um parceiro só recebe as permissões que atuam sobre um workflow:Toda outra permissão do Flowker atua sobre o tenant inteiro, e nunca é dada a um parceiro, nem as de leitura, como workflows com list ou executors com read. O Access Manager recusa com 400 e IDE-1056.
3

Crie a aplicação dele no Flowker

Crie a aplicação do parceiro com o produto flowker. Veja Criar as aplicações do parceiro no guia da API, ou no Console. Envie o client ID e o client secret ao parceiro por um canal seguro.
4

Diga ao parceiro como nomear os workflows dele

Em quase todas as rotas que o parceiro alcança, o workflow já está no path, em /v1/workflows/{workflowId}, então ele não envia nada extra. Só a lista de execuções nomeia o workflow numa query. Todo valor tem que estar dentro do escopo do parceiro.
Para ler uma execução, use as rotas sob o workflow: /v1/workflows/{workflowId}/executions/{executionId} e …/results. As rotas /v1/executions/{id} e /v1/executions/{id}/results não nomeiam o workflow, e são recusadas a todo parceiro.
Uma execução de outro workflow, pedida sob o path de um workflow do parceiro, responde 404 com FLK-0500. Nada é lido, e a resposta não diz de qual workflow é a execução.Uma Idempotency-Key já usada para executar outro workflow responde 409 com FLK-0511. Nada é executado, e a resposta não traz nada da outra execução. Uma chave nova executa o workflow, e a mesma chave repetida no mesmo workflow devolve a mesma execução.Estas rotas não nomeiam um workflow, e são recusadas a todo parceiro: listar e criar workflows (GET /v1/workflows, POST /v1/workflows, POST /v1/workflows/from-template), GET /v1/workflows/schedule/pending-review-counts, POST /v1/workflows/preview-request, e as rotas do catálogo, dos executores, das configurações de provedor, dos dashboards, dos schemas e dos webhooks. Use uma aplicação da sua própria instituição para essas rotas.
5

Confirme que funciona

Esta conferência supõe que o parceiro tem o recurso workflows com a ação read no Flowker, e um escopo restrito a um ou mais workflows. Use a credencial do parceiro. Leia um workflow dentro do escopo dele. A resposta é 200:
Envie a mesma requisição com um workflow fora do escopo. A resposta é 403 com o código FLK-0004.

​
Se algo falhar

A resposta não diz se foram as permissões ou o escopo que recusaram a requisição. Isso é proposital: um parceiro não consegue usar uma recusa para descobrir quais workflows existem fora do escopo dele. Para todos os outros códigos, veja a lista de erros do Flowker. Para as recusas ao criar ou alterar um parceiro, veja os códigos de erro no guia da API.