Saltar al contenido principal
Un socio puede llamar a Flowker con su propia credencial. En Flowker, restringes esa credencial a algunos workflows. Esta página muestra cómo elegir ese ámbito, qué alcanza y qué recibe el socio cuando sale de él. Todo socio de Flowker necesita un ámbito.

​
Paso a paso

1

Elige los workflows del socio

Flowker tiene una restricción. El campo en la API es el field de una entrada de ámbito; la Console muestra el nombre de la primera columna.El catálogo de ámbito lista la restricción de Flowker. Léelo con Consultar el catálogo de ámbito de un producto para flowker.Algunas reglas valen para todo ámbito:
  • Una solicitud que no nombra un workflow se rechaza. Por ejemplo, un socio no puede listar las ejecuciones sin filtrar por su workflow.
  • Una solicitud que lista varios workflows en una query se rechaza cuando cualquiera de ellos está fuera del ámbito.
2

Da al socio sus permisos y su ámbito

Crea el socio, o cámbialo, en la Console o con la API de Identity. El identificador del producto es flowker.
  • Agrega la entrada de ámbito workflowId, con uno o más workflows. Sin ella, Access Manager rechaza el socio con 400 y IDE-1060.
  • Marca los recursos y las acciones. Lo máximo que puedes dar es lo que el rol flowker-editor-role tiene en tu tenant. Por encima de eso, Access Manager rechaza con IDE-1043. Por ejemplo, catalog con create está por encima de ese rol.
Un socio solo recibe los permisos que actúan sobre un workflow:Todo otro permiso de Flowker actúa sobre todo el tenant, y nunca se da a un socio, ni siquiera los de lectura, como workflows con list o executors con read. Access Manager rechaza con 400 y IDE-1056.
3

Crea su aplicación de Flowker

Crea la aplicación del socio con el producto flowker. Consulta cómo crear las aplicaciones del socio en la guía de la API o en la Console. Envía el client ID y el client secret al socio por un canal seguro.
4

Indica al socio cómo nombrar sus workflows

En casi todas las rutas que el socio alcanza, el workflow ya está en el path, en /v1/workflows/{workflowId}, así que el socio no envía nada extra. Solo la lista de ejecuciones nombra el workflow en una query. Cada valor debe estar dentro del ámbito del socio.
Para leer una ejecución, usa las rutas bajo el workflow: /v1/workflows/{workflowId}/executions/{executionId} y …/results. Las rutas /v1/executions/{id} y /v1/executions/{id}/results no nombran el workflow, y se rechazan a todo socio.
Una ejecución de otro workflow, pedida bajo el path de un workflow del socio, responde 404 con FLK-0500. No se lee nada, y la respuesta no indica de qué workflow es la ejecución.Una Idempotency-Key ya usada para ejecutar otro workflow responde 409 con FLK-0511. No se ejecuta nada, y la respuesta no trae nada de la otra ejecución. Una clave nueva ejecuta el workflow, y la misma clave repetida en el mismo workflow devuelve la misma ejecución.Estas rutas no nombran un workflow, y se rechazan a todo socio: listar y crear workflows (GET /v1/workflows, POST /v1/workflows, POST /v1/workflows/from-template), GET /v1/workflows/schedule/pending-review-counts, POST /v1/workflows/preview-request, y las rutas del catálogo, de los ejecutores, de las configuraciones de proveedor, de los dashboards, de los schemas y de los webhooks. Usa una aplicación de tu propia institución para esas rutas.
5

Confirma que funciona

Esta verificación supone que el socio tiene el recurso workflows con la acción read en Flowker, y un ámbito restringido a uno o más workflows. Usa la credencial del socio. Lee un workflow dentro de su ámbito. La respuesta es 200:
Envía la misma solicitud con un workflow fuera del ámbito. La respuesta es 403 con el código FLK-0004.

​
Si algo falla

La respuesta no indica si fueron los permisos o el ámbito los que rechazaron la solicitud. Es intencional: un socio no puede usar un rechazo para saber qué workflows existen fuera de su ámbito. Para todos los demás códigos, consulta la lista de errores de Flowker. Para los rechazos al crear o cambiar un socio, consulta los códigos de error de la guía de la API.