Dzięki funkcji działań asynchronicznych bloki akcji w kreatorze przepływów pracy mogą działać asynchronicznie. Pozwala to wykonywać złożone operacje bez blokowania przepływu automatyzacji i pozorowania powodzenia działania, a tym samym zapobiegać duplikatom i niepotrzebnym ponownym próbom. Dzięki temu użytkownicy mają płynniejsze doświadczenia, a zasoby są wykorzystywane efektywniej.

Pojęcia

Dotychczas oczekiwano, że bloki akcji szybko zwrócą odpowiedź synchroniczną. Niektóre działania, takie jak wywołanie zewnętrznych interfejsów API, trwają jednak dłużej, niż pozwala na to obecne okno oczekiwania na odpowiedź. Aby uniknąć błędów przekroczenia limitu czasu, deweloperzy często od razu zwracają odpowiedź „powodzenie”, zanim zostanie wykonana logika działania.

Taki przepływ ukrywa przed użytkownikami rzeczywisty wynik działania bloku, ale automatyzacja działa tak, jakby zakończyło się ono powodzeniem. Jeśli deweloper zbyt długo zwleka z odpowiedzią, mogą wystąpić przekroczenia limitu czasu, ponowne próby i duplikaty.

Działania asynchroniczne rozwiązują ten problem, pozwalając deweloperom zgłosić wynik, gdy działanie zakończy się powodzeniem lub niepowodzeniem. Automatyzacja wstrzymuje się wtedy i czeka na potwierdzenie, zanim będzie kontynuowana. Zapobiega to duplikatom i niepotrzebnym ponownym próbom, a użytkownicy zyskują większą wiedzę o tym, co się dzieje.

Działania asynchroniczne a niestandardowe

Asynchroniczne bloki akcji działają podobnie do tradycyjnych akcji niestandardowych (custom actions). Po wyzwoleniu działania serwer aplikacji monday wysyła żądanie POST na adres URL uruchamiania skonfigurowany w bloku niestandardowym. Po otrzymaniu żądania aplikacja nadal musi odpowiedzieć kodem stanu 200.

W przeciwieństwie do akcji niestandardowych asynchroniczne bloki akcji wysyłają odpowiedź 200 tylko po to, aby potwierdzić, że działanie zostało wyzwolone. Automatyzacja wstrzymuje się wtedy i czeka, aż aplikacja wykona działanie. Po jego zakończeniu aplikacja powinna wysłać żądanie POST na podany adres callbackUrl, aby poinformować o powodzeniu lub niepowodzeniu.

Poniższa tabela przedstawia najważniejsze podobieństwa i różnice między asynchronicznymi blokami akcji a akcjami niestandardowymi:

Asynchroniczne bloki akcji

Akcje niestandardowe

Pozwalają tworzyć dowolne działania, których nie obsługują wbudowane bloki Po wyzwoleniu odbierają żądanie POST na skonfigurowanym adresie URL uruchamiania Od razu zwracają kod stanu 200, aby potwierdzić, że działanie zostało wyzwolone Automatyzacja czeka na wynik, zanim będzie kontynuowana Wysyłają żądanie POST na nową trasę, aby poinformować o powodzeniu lub niepowodzeniu Ładunek żądania zawiera callbackUrl, na który deweloper powinien odesłać wynik działania bloku

Pozwalają tworzyć dowolne działania, których nie obsługują wbudowane bloki Po wyzwoleniu odbierają żądanie POST na skonfigurowanym adresie URL uruchamiania Automatyzacja działa dalej od razu po otrzymaniu początkowej odpowiedzi Zwracają odpowiedź po zakończeniu działania z kodem stanu 200

Obsługa błędów

Odpowiedź wysyłana na nową trasę zawiera kody ważności, które wskazują powodzenie lub niepowodzenie działania. Działa to zgodnie z istniejącą umową obsługi błędów. Kody stanu HTTP nie są używane, ponieważ działanie kończy się w żądaniu, a nie w odpowiedzi.

Aby zgłosić problem bez wywoływania efektów ubocznych, takich jak zapisanie komunikatu w dzienniku aktywności, możesz użyć kodu ważności 2000 i podać opis błędu środowiska wykonawczego.

Wdrażanie

Wykonaj poniższe kroki, aby utworzyć asynchroniczny blok akcji:

1. Otwórz swoją aplikację w Centrum deweloperów (Developer Center).
2. Utwórz nowy blok akcji.
3. W sekcji Podstawowe szczegóły (Basic Details) zaznacz opcję Oznacz blok jako asynchroniczny (Mark block as async).

Dokumentacja

Przykładowa treść żądania POST z serwera monday

{ 
  "payload": { 
    "blockKind": "action",
    "inboundFieldValues": {
      "boardId": 1234567890, 
      "columnId": "text",
      "itemId": 9876543210
    },
    "inputFields": { 
      "boardId": 1234567890,
      "itemId": 9876543210,
      "columnId": "text"
    },
    "recipeId": 123456,
    "integrationId": 123456,
    "callbackUrl": "https://callback-to-monday.com/callbacks/12345678" 
  }, 
  "runtimeMetadata": {
    "actionUuid": "a6676dzce11zd50b25c4871417e1zez1",
    "triggerUuid": "z607d55cc428bb438ba02cbbcde6a25e"
  }
}

Przykładowa odpowiedź POST po wyzwoleniu działania

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

{
  "status": "received",
  "message": "Action has been triggered.",
  "actionUuid": "a6676dzce11zd50b25c4871417e1zez1"
}

Przykładowe żądanie POST z wynikiem działania

Przed wysłaniem odpowiedzi zwrotnej musisz podpisać token JWT za pomocą klucza tajnego do podpisywania aplikacji.

Następnie wyślij token JWT w nagłówku Authorization jako surowy token. W ładunku tokenu powinien znaleźć się identyfikator appId.

Przykład: podpisywanie tokenu JWT

import jwt from "jsonwebtoken";

const appId = "YOUR_APP_ID";
const appSigningSecret = "YOUR_APP_SIGNING_SECRET";

const token = jwt.sign({ appId }, appSigningSecret);

Użyj otrzymanego tokenu jako wartości nagłówka Authorization.

# The `callbackUrl` received from monday in the initial POST request body
POST https://callback-to-monday.com/callbacks/12345678 HTTP/1.1
Content-Type: application/json
Authorization: <SIGNED_JWT_TOKEN>

{
  "success": true,
  "outputFields": {}
}

{
  "success": false,
  "severityCode": 4000,
  "runtimeErrorDescription": "This is the activity log description of 4000",
  "notificationErrorTitle": "This is the notification title of 4000",
  "notificationErrorDescription": "This is the notification description of 4000"
}