Kiedy Jira Automation to za mało: Obsługa paginacji przy użyciu webhooków i wywołań rekurencyjnych

Jira Automation to narzędzie typu „no-code”, które pozwala budować złożone workflow bez użycia zewnętrznych usług. W wielu przypadkach w pełni wystarcza do obsługi integracji i logiki biznesowej.

Problem pojawia się przy pracy z większymi zbiorami danych, szczególnie gdy API zwraca wyniki w formie paginowanej. To, co początkowo wygląda na prostą regułę:

• pobierz dane,
• przetwórz wyniki,
• kontynuuj, jeśli są kolejne,

… bardzo szybko przestaje działać poprawnie.

Ten problem pojawia się m.in. przy:

• synchronizacji danych między systemami,
• walidacji dużych zbiorów danych,
• wyszukiwaniu konkretnych elementów, gdy brak filtrowania.

Efekt: Automatyzacja działa poprawnie tylko pozornie, przetwarzając część danych.

Jeśli Twoja reguła przetwarza tylko pierwsze 50 wyników, to jest dokładnie ten problem.

W artykule zaprezentuję wzorzec oparty na webhookach i rekurencji, który pozwala przetwarzać dane krok po kroku – w pełni w ramach Jira Automation.

Problem paginacji w Jira Automation

Większość API Jira Cloud zwraca dane w sposób paginowany, co oznacza, że zwracana jest tylko część danych oraz konieczne są kolejne zapytania, aby pobrać pełny zbiór.

Typowe mechanizmy paginacji:

• offset-based (start, limit),
• token-based (nextPageToken),
• link-based (_links.next),
• flagi logiczne (np. isLast).

Problem:

• brak jednolitego modelu paginacji,
• brak gwarancji pełnej liczby wyników,
• ograniczone możliwości filtrowania.

Jira Automation oferuje branching, ale:

• działa tylko na już pobranych danych,
• nie umożliwia iteracji między wywołaniami API,
• nie wspiera akumulacji wyników.

Obsługa paginacji wymaga więc rozdzielenia logiki na wiele niezależnych wykonań.

Case study: rekurencyjne przetwarzanie przez webhook

Ten wzorzec jest przydatny, gdy trzeba przetworzyć wszystkie strony danych oraz znaleźć konkretny element bez możliwości filtrowania.

Architektura rozwiązania

Rozwiązanie składa się z dwóch reguł automatyzacji:

1. Reguła inicjalna
   • rozpoczyna process,
   • wysyła pierwszy webhook.
2. Reguła rekurencyjna
   • wywoływana przez webhook,
   • przetwarza dane,
   • decyduje o kontynuacji.

Zarządzanie stanem (payload)

Każde wykonanie jest stateless, dlatego cały stan musi być przekazywany w payloadzie.

Przykład:

{
  "start": 0,
  "limit": 50,
  "targetName": "Example Organization",
  "runId": "12345",
  "maxDepth": 10
}

Kluczowe pola:

• pagination – start, limit
• kontrola – maxDepth
• korelacja – runId
• kontekst – targetName

Nie istnieje współdzielona pamięć między wykonaniami – cały stan musi być przekazywany w requestach.

Dwa praktyczne przypadki użycia

Pełne przetwarzanie (ang. Full Traversal)

Rozwiązanie jest używane, gdy trzeba przetworzyć cały zbiór danych.

Flow:

1. Pobierz stronę.
2. Przetwórz element.
3. Kontynuuj, jeśli są kolejne dane.

Warunki zakończenia:

• brak kolejnych stron,
• pusta odpowiedź,
• osiągnięty maxDepth.

Zastosowanie:

• agregacja,
• synchronizacja,
• walidacja.

Wyszukiwanie warunkowe (ang. Conditional Search)

Rozwiązanie wykorzystujemy, gdy potrzebny jest tylko jeden element.

Flow:

1. Pobierz stronę.
2. Sprawdź warunek.
3. Zatrzymaj, jeśli znaleziono.
4. W przeciwnym razie – kontynuuj.

Warunki zakończenia:

• znaleziono element,
• ostatnia strona,
• osiągnięty maxDepth.

Przepływ wykonania:

Każde wykonanie realizuje tylko jeden krok.

Krok 1: Zapytanie API (na przykładzie JSM)

W przykładzie używamy API JSM, ale ten sam mechanizm można zastosować do każdego paginowanego API.

GET /rest/servicedeskapi/organization?start={{webhookData.start}}&limit={{webhookData.limit}}

Krok 2: Przetwarzanie odpowiedzi

{
  "values": [
    { "id": "1", "name": "Org A" },
    { "id": "2", "name": "Org B" }
  ],
  "isLast": false,
  "start": 0,
  "limit": 50
}

Reguła:

• sprawdza wartość docelową,
• ocenia warunek kontynuacji (isLast).

Krok 3: Wywołanie kolejnej iteracji

POST <webhook-url>
{
  "start": {{webhookData.start.plus(webhookData.limit)}},
  "limit": {{webhookData.limit}},
  "targetName": "{{webhookData.targetName}}",
  "runId": "{{webhookData.runId}}",
  "maxDepth": {{webhookData.maxDepth.minus(1)}}
}

Paginacja przesuwa się dalej, a kontekst jest zachowany.

Krok 4: Warunki zakończenia

Wykonanie zatrzymuje się, gdy:

• znaleziono target,
• brak kolejnych stron (isLast = true),
• osiągnięto maxDepth.

Kluczowa idea: całe zachowanie wynika z łańcucha niezależnych wykonań.

Ograniczenia i ryzyka

To podejście wiąże się z pewnymi kompromisami:

• brak możliwości bezpośredniego anulowania,
• zużycie executions Automation i limitów API,
• zwiększona złożoność (zarządzanie stanem, warunki ochronne),
• ograniczona obserwowalność (rozproszone wykonania),
• brak współdzielonego stanu i brak akumulacji wyników.

Takie rozwiązanie nie zastępuje zewnętrznych systemów przetwarzania danych.

Dobre praktyki

Aby zwiększyć niezawodność:

• definiuj jasne warunki kontynuacji,
• zawsze implementuj logikę zakończenia,
• używaj maxDepth jako zabezpieczenia,
• utrzymuj payload możliwie prosty,
• używaj runId do śledzenia,
• projektuj kroki jako idempotentne.

Każde wykonanie powinno być niezależne i bezpieczne.

Sii x Atlassian

Jako Atlassian Platinum Partner analizujemy, wdrażamy i migrujemy narzędzia do chmury, aby przyspieszyć i usprawnić pracę zespołów.

Oferta Atlassian

Podsumowanie

Rekurencyjne przetwarzanie z użyciem webhooków to praktyczne obejście dla obsługi paginowanych API w Jira Automation.

Sprawdza się, gdy:

• logika musi pozostać w Jira Cloud,
• wolumen danych jest umiarkowany,
• zastosowano odpowiednie zabezpieczenia.

Nie powinno być stosowane, gdy:

• przetwarzanie jest duże lub częste,
• wymagana jest wysoka obserwowalność lub możliwość anulowania,
• dostępne są systemy zewnętrzne.

To rozwiązanie rozszerza możliwości Jira Automation bez wprowadzania dodatkowej infrastruktury.