Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Señales
Las señales le permiten inyectar información en una ejecución de flujo de trabajo en ejecución. En algunos casos, puede ser conveniente añadir información a una ejecución de flujo de trabajo en ejecución para informar a esta de que algo ha cambiado o de un evento externo. Cualquier proceso puede enviar una señal a una ejecución de flujo de trabajo abierta. Por ejemplo, una ejecución de flujo de trabajo podría señalar otra.
nota
Un intento de envío de una señal a una ejecución de flujo de trabajo que no está abierta hace que SignalWorkflowExecution experimente errores con UnknownResourceFault.
Para utilizar señales, defina el nombre de la señal y los datos que se van a transferir a esta, si los hay. A continuación, programe el decisor para que reconozca el evento de señal (WorkflowExecutionSignaled) del historial y lo procese correctamente. Cuando un proceso desea señalar una ejecución de flujo de trabajo, realiza una llamada a Amazon SWF (mediante la acción SignalWorkflowExecution o, en el caso de un decisor, mediante la decisión SignalExternalWorkflowExecution) que especifica el identificador de la ejecución del flujo de trabajo de destino, el nombre de la señal y los datos de la señal. A continuación, Amazon SWF recibe la señal, la registra en el historial de ejecución del flujo de trabajo de destino y programa una tarea de decisión para ella. Si el decisor recibe la tarea de decisión, también recibirá la señal dentro del historial de ejecución del flujo de trabajo. Es entonces cuando el decisor puede tomar las acciones adecuadas según la señal y sus datos.
En ocasiones, es posible que quiera esperar a recibir una señal. Por ejemplo, para cancelar un pedido, un usuario puede enviar una señal, pero solo en el plazo de una hora desde el momento en que realizó el pedido. Amazon SWF no tiene un tipo primitivo que permita a un decisor esperar a recibir una señal del servicio. La funcionalidad de pausa debe implementarse en el propio decisor. Para hacer una pausa, el decisor debería iniciar un temporizador mediante la decisión StartTimer, que especifica la duración de la espera de la señal por parte del decisor mientras se sigue realizando el sondeo de tareas de decisión. Al recibir el decisor una tarea de decisión, debería comprobar el historial para ver si se ha recibido la señal o si se ha iniciado el temporizador. Si se ha recibido la señal, el decisor debería cancelar el temporizador. Sin embargo, si por el contrario, se ha iniciado el temporizador, significa que la señal no llegó en el periodo de tiempo especificado. Para resumir, a fin de esperar a recibir una señal específica, haga lo siguiente.
-
Cree un temporizador durante el tiempo que debería esperar el decisor.
-
Al recibirse una tarea de decisión, compruebe el historial para ver si ha llegado la señal o si se ha iniciado el temporizador.
-
Si ha llegado una señal, cancele el temporizador mediante una decisión
CancelTimery procese la señal. Dependiendo de los tiempos, el historial puede contener los eventosTimerFiredyWorkflowExecutionSignaled. En estos casos, puede confiar en el orden relativo de los eventos del historial para determinar qué ocurrió primero. -
Si se ha iniciado el temporizador, antes de recibirse una señal, el decisor ha agotado el tiempo de espera de la señal. Puede producir un error en la ejecución o llevar a cabo cualquier otra lógica que sea adecuada para su caso de uso.
Para los casos en los que deba cancelarse un flujo de trabajo, por ejemplo, si el cliente canceló el pedido, debe utilizarse la acción RequestCancelWorkflowExecution en lugar de enviar una señal al flujo de trabajo.
Algunas aplicaciones para señales incluyen las siguientes acciones:
-
Detener el progreso de ejecuciones de flujo de trabajo hasta que se reciba una señal (p. ej., esperar un envío del inventario).
-
Proporcionar información a una ejecución de flujo de trabajo que podría afectar a la lógica de la toma de decisiones por parte de los decisores. Esto resulta útil para los flujos de trabajo afectados por eventos externos (p. ej., intentar finalizar la venta de una acción tras cerrar el mercado).
-
Actualizar una ejecución de flujo de trabajo si prevé que pueden producirse cambios (p. ej., cambiar los volúmenes de pedidos después de realizarse un pedido y antes de enviarse).
En el siguiente ejemplo, se envía una señal a la ejecución de flujo de trabajo para cancelar un pedido.
https://swf.us-east-1.amazonaws.com SignalWorkflowExecution {"domain": "867530901", "workflowId": "20110927-T-1", "runId": "f5ebbac6-941c-4342-ad69-dfd2f8be6689", "signalName": "CancelOrder", "input": "order 3553"}
Si la ejecución del flujo de trabajo recibe la señal, Amazon SWF devolverá una respuesta HTTP correcta similar a la siguiente: Amazon SWF generará una tarea de decisión para informar al decisor de que procese la señal.
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: application/json
x-amzn-RequestId: bf78ae15-3f0c-11e1-9914-a356b6ea8bdf