Een proces hervatten vanuit een ander systeem

Laat een proces in Picked wachten tot er buiten Picked iets gebeurt: een vervoerder haalt op, je ERP keurt een kredietcontrole goed, een pallet komt aan bij het dock. Je systeem stuurt een signaal, en het wachtende werk gaat verder.

Wanneer gebruik je dit

Gebruik dit recept als een stap in je magazijn afhangt van een systeem dat Picked niet zelf draait. Het bestaat uit twee helften: een wachtstap in het proces, en een aanroep vanuit je systeem.

Je hebt een token nodig met het recht process-events:write (zie Authenticatie en rechten).

Bouw de wachtstap

Open in de procesbouwer de stap die moet wachten:

1. Zet de invoer op Wachten.

2. Kies bij wat het wachten beëindigt voor Een signaal van buiten.

3. Vul een Naam van het signaal in, zoals pallet-landed. Die naam stuurt je systeem mee. Gebruik tot 255 letters, cijfers, ., _, : en -, en maak hem specifiek: elk proces dat op de naam wacht, hoort hem.

4. Optioneel: Alleen doorgaan als, een voorwaarde die het werk aanwijst waar het signaal over gaat. De velden van het signaal heten event_… en de eigen waarden van het werk staan er onder hun naam, dus event_order_id == order_id maakt alleen het werk voor die order wakker. Geneste velden lees je als event['line']['sku'].

5. Optioneel: Opgeven na (minuten). Komt het signaal niet op tijd, dan gaat de stap verder met de uitkomst timed_out, en daar kun je op vertakken. Zonder deze tijd wacht het werk tot het signaal komt of iemand het wachten beëindigt.

6. Optioneel: Outputs die velden uit de payload van het signaal halen, zodat latere stappen ze kunnen tonen en gebruiken als {{ steps.<stap>.<naam> }}. Elke output noemt het Veld in de payload (dock, line.sku) en kan een Standaard hebben. Een signaal dat een veld zonder standaard mist, of er een van een ander type heeft, maakt de stap niet wakker, net als een signaal dat niet aan de voorwaarde voldoet. Zie Gebruik het antwoord in latere stappen.

Is Opgeven na voorbij, dan is de stap van de klok: een signaal dat later komt, maakt niets meer wakker, en het werk gaat verder met timed_out.

Publiceer het proces. Werk dat bij de stap aankomt, gaat daar nu slapen.

Stuur het signaal

POST /api/v1/process-events/{eventKey} met de naam van het signaal in het pad. De optionele payload is een willekeurig JSON-object, tot 100 sleutels op het hoogste niveau en 64 KB. De voorwaarde wordt ertegen gecontroleerd, en het werk dat wakker wordt, kan hem lezen.

curl -X POST "https://picked.nl/api/v1/process-events/pallet-landed" \
  -H "Authorization: Bearer $PICKED_TOKEN" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{
    "payload": { "dock": "D3", "sscc": "387123450000012345", "order_id": 48211 }
  }'

HTTP/1.1 200 OK
Content-Type: application/json

{
  "event_key": "pallet-landed",
  "woken_task_batch_ids": [5512],
  "woken_count": 1,
  "deferred_task_batch_ids": [],
  "deferred_count": 0
}

Lees het antwoord

Het antwoord is altijd 200, wat het signaal ook wakker maakte:

• woken_task_batch_ids: het werk dat nu verdergaat.
• Niets wakker gemaakt: er wachtte geen werk op deze naam, of de voorwaarde klopte niet. Dat is geen fout. Misschien was het werk nog niet bij de stap, of heeft een eerder signaal het al gewekt. Probeer het niet opnieuw.
• deferred_task_batch_ids: werk dat wel paste maar nog niet verder kan, bij gebrek aan voorraad of capaciteit. Stuur hetzelfde signaal later nog een keer. Niets anders probeert het opnieuw, dus zonder jouw herhaling gaat het signaal voor dat werk verloren.

Picked herkent een signaal niet als herhaling: elke aanroep is een nieuwe levering. Zie Idempotentie.

Fouten afhandelen

Foutmeldingen noemt alle codes, en Rate limits wat je doet bij een 429.

Testen

Een signaal kun je niet proefdraaien: met de header Picked-Dry-Run: true krijg je hier 400 en gebeurt er niets. Test daarom met een eigen proces: geef de wachtstap een signaalnaam die verder nergens voorkomt, laat een stuk werk bij de wachtstap aankomen, stuur het signaal en controleer dat woken_count op 1 staat.