# Workflow

Genera un [workflow](/es/workflows) en segundo plano en `src/lib/workflows`, con una prueba de servidor junto a él.

### Sintaxis

```
$ vela generate workflow <name> [--cron <schedule>]
```

```
$ vela generate workflow send-welcome-email
```

### Opciones

- `--cron <schedule>` - Ejecutar según un horario, dado como una expresión cron de cinco campos

### Qué escribe

```
src/lib/workflows/send-welcome-email.ts
src/lib/workflows/send-welcome-email.server.test.ts
```

El nombre puede escribirse como `send-welcome-email`, `sendWelcomeEmail` o `send_welcome_email`; el archivo y el nombre registrado del workflow usan la forma kebab-case, y la exportación es camelCase. El workflow generado toma un esquema de entrada vacío y tiene un paso por rellenar:

```ts
import { z } from 'zod';
import { ow } from '$lib/server/workflows';

export const sendWelcomeEmail = ow.defineWorkflow(
	{
		name: 'send-welcome-email',
		// Lo que acepta `run()`, comprobado antes de encolar la ejecución.
		schema: z.object({}),
		retryPolicy: { maximumAttempts: 3 }
	},
	async ({ input, step }) => {
		const result = await step.run({ name: 'first-step' }, async () => {
			return input;
		});
		return result;
	}
);
```

Inícialo desde el código del servidor con `sendWelcomeEmail.run(input)`. La prueba arranca un worker en el proceso de pruebas, ejecuta el workflow y espera su resultado, de modo que [`vela test:server`](/es/test/server) lo ejercita de principio a fin.

### Recurrente

```
$ vela generate workflow sync-prices --cron '*/5 * * * *'
```

Un workflow recurrente no toma entrada y su archivo exporta el horario. Todos los workflows definidos en ese archivo se ejecutan con él, como mucho una vez por minuto y una sola vez entre todos los servidores; `syncPrices.run()` inicia una ejecución extra en cualquier momento.

El proyecto tiene que contar con el runtime de workflows — todo proyecto creado con Vela lo tiene, y [`vela enable workflows`](/es/enable/workflows) lo añade a uno creado antes.