Scenariusz Make, który przez miesiące spokojnie przerzucał rekordy, psuje się na jeden z dwóch sposobów: historia zapełnia się czerwonymi modułami i krótkim komunikatem błędu albo milknie i przez tydzień nikt tego nie zauważa. Ani jedno, ani drugie nie jest przypadkiem. Prawie każda awaria między Make a Bitrix24 (Alaio) bierze się z tych samych czterech miejsc: połączenia, odpytującego triggera, kodów pól i brakującego kroku wyszukiwania przed tworzeniem rekordu.

Dlaczego połączenie pada po miesiącach pracy?

Make sięga do portalu przez aplikację: albo tę zainstalowaną z Marketu, albo lokalną, zarejestrowaną przez Ciebie z identyfikatorem klienta, sekretem i adresem handlera wskazującym na kanał zwrotny Make. Dwie rzeczy zamrażają się w tym momencie — uprawnienia, z których aplikacja może korzystać, i pracownik, którego sesja ją autoryzowała. Wystarczy, że ktoś usunie aplikację z portalu, dezaktywuje tego pracownika albo przytnie uprawnienia, a wszystkie moduły wszystkich scenariuszy padają naraz: z błędem autoryzacji, nie z błędem danych.

Treść komunikatu mówi, którą stronę naprawiać. Jeśli odpowiedź brzmi, że aplikacja nie jest zainstalowana, po stronie portalu jej po prostu nie ma i ponowna autoryzacja w Make niczego nie zmieni, dopóki nie wróci. Nieważny albo wygasły token oznacza z kolei, że urwał się cykl odświeżania i połączenie trzeba autoryzować od nowa. Grzebanie w samym module nie pomaga w żadnym z tych przypadków.

Dlaczego moduł Watch gubi rekordy?

Bo odpytuje. Watch Deals, Watch Leads i Watch Tasks nie są subskrypcją zdarzeń: w rytmie harmonogramu pytają portal, co pojawiło się od ostatniego razu. To, co zobaczą, zależy od trzech ustawień: interwału, tego, czy filtr działa na czasie utworzenia czy modyfikacji, oraz liczby elementów, jaką wolno wziąć jednemu cyklowi — a to pole ma bardzo małą wartość domyślną. Masowy import dwustu leadów sączy się więc po kilka na przebieg, aż kolejka nadrobi zaległości, i czyta się to dokładnie jak trigger, który zgubił rekordy. Filtr na czasie utworzenia nigdy nie zauważy zmian, a filtr na czasie modyfikacji odczyta ponownie to, co scenariusz sam przed chwilą zapisał.

Odpytywanie kosztuje po obu stronach: przebieg dzieje się niezależnie od tego, czy coś się zmieniło, a każdy cykl zużywa wywołania REST portalu. Portal pozwala z grubsza na kilka wywołań na sekundę, więc pętla po kilkuset rekordach bez pauz wchodzi w limit — a ten pułap jest liczony na portal, nie na scenariusz, więc drugi scenariusz go dziedziczy.

Kiedy reakcja ma być natychmiastowa, niech to portal wysyła sam: albo webhook wychodzący skierowany na moduł Custom webhook, albo krok wewnątrz samego procesu. Żądanie HTTP GET/POST odpala się dokładnie w tym miejscu procesu, które wybrałeś, i wysyła tylko to, co chciałeś wysłać; Zbuduj JSON z pól składa treść bez ręcznego escapowania cudzysłowów; Wyodrębnij wartość z JSON po ścieżce wciąga odpowiedź z powrotem do procesu — więcej o tym w tekście o JSON w procesach biznesowych. Tam, gdzie zgubiona dostawa jest droga — zamówienie idzie na produkcję, dokument do podpisu — Niezawodny webhook ponawia próby według własnego harmonogramu, zamiast poddać się po pierwszej. Obie strony opisuje diagnostyka webhooków.

Dlaczego Create i Update kończą się błędem, choć dane wyglądają dobrze?

Prawie zawsze przez kody pól. Pola użytkownika jadą pod swoim kodem UF_CRM_…, a nie pod etykietą widoczną w karcie; etapy i lejki idą po identyfikatorach; telefon i e-mail to pola wielokrotne, więc zwykły ciąg znaków ląduje w złym kształcie albo po cichu nie robi nic. Do tego etap potrafi wymagać pól, które chwilę wcześniej były opcjonalne — dlatego rekord, który człowiek zapisuje ręcznie, wraca z modułu odrzucony. Zanim obwinisz moduł, sprawdź ładunek względem prawdziwych kodów: najczęstszy przypadek rozpisany jest w aktualizacji pola deala przez API. Metody bez własnego modułu idą przez Make an API Call, który trzyma się tych samych reguł, tylko bez żadnego mapowania pól.

Skąd biorą się duplikaty po ponownym uruchomieniu?

Stąd, że moduły Create tworzą. Uruchom ponownie partię, która padła w połowie, a wszystko sprzed punktu awarii wyląduje drugi raz — nic w ładunku nie mówi „ten już istnieje”. Kształt, który przeżywa powtórki, to: znajdź, rozgałęź, dopiero potem twórz albo aktualizuj. Najtaniej robi się to w portalu: Znajdź deal według warunku i Znajdź kontakt po telefonie/e-mailu oddają istniejący rekord do procesu, więc rozgałęzienie następuje przed zapisem. To, co już się nazbierało, to osobna robota — patrz duplikaty w Bitrix24.

Której połowy scenariusza w ogóle nie powinno być w Make?

Tej, która nigdy nie opuszcza portalu. Przesunięcie etapu, wypełnienie pola, założenie zadania, rozgałęzienie po warunku: przepuszczanie tego przez zewnętrzny scenariusz kupuje dodatkową podróż przez sieć, drugie miejsce do debugowania i limit, którego trzeba pilnować — i nic poza tym. Sensowny podział brzmi: Make odpowiada za systemy na zewnątrz, portal za własne rekordy, a między nimi jest jedno wywołanie. Strona wewnętrzna to zwykła konfiguracja reguł automatyzacji; jeśli to właśnie ten wewnętrzny krok nigdy nie wystartował, pomaga lista kontrolna dlaczego reguły nie działają. Ten sam rachunek dla sąsiadów opisują konektory kontra automatyzacja w portalu i łączenie Bitrix24 z n8n.

Co dalej

Rozłóż scenariusz na dwie listy: moduły dotykające systemów poza portalem i moduły dotykające wyłącznie rekordów portalu. Drugą listę przenieś do środka, a zostanie zwykle jedno połączenie i jeden webhook — na tyle mało, żeby dało się to utrzymać przy życiu. Klocki na stronę wewnętrzną leżą w katalogu robotów, a jeśli brakuje tego właściwego, opisz zadanie: Roboteka tworzy brakujące reguły automatyzacji za darmo i wykłada je do wspólnej biblioteki.