Integracja Drupala z n8n: formularze, treści i systemy biznesowe

Wyobraźmy sobie, że użytkownik wysyła na stronie formularz z zapytaniem o produkt. Dzięki integracji Drupala z n8n zgłoszenie może trafić do CRM i powiadomić właściwy zespół sprzedaży, a numer rekordu z CRM może wrócić do Drupala, co ułatwia dalszą obsługę. Zespół poświęca wtedy mniej czasu na przepisywanie danych, a więcej na odpowiedź klientowi.

Integracja działa także w drugą stronę. Na podstawie artykułu zatwierdzonego w innym systemie może powstać szkic w Drupalu, a zmiana daty wydarzenia może zaktualizować istniejącą stronę.

Drupal zapewnia formularze, ustrukturyzowane treści, walidację i kontrolę nad publikacją. Narzędzie n8n przekazuje i przekształca dane między systemami. Razem pozwalają włączyć stronę internetową w procesy firmy, które toczą się przed wizytą użytkownika i po niej.

W tym artykule:

• Co można zautomatyzować, łącząc Drupala z n8n?
• Jak webhooki i API łączą oba systemy?
• Jak formularz w Drupalu może utworzyć lub zaktualizować rekord w CRM?
• Jak zdarzenie w systemie zewnętrznym może utworzyć lub zaktualizować treść w Drupalu?
• Jak zmiany w Drupalu mogą uruchamiać działania w innych systemach?
• Dlaczego model encji w Drupalu ułatwia ponowne wykorzystanie integracji?
• Który komponent odpowiada za które zadanie?
• Co zapewnia niezawodne działanie workflow w n8n?

Co można zautomatyzować, łącząc Drupala z n8n?

Najbardziej przydatne integracje eliminują konkretny ręczny krok, na przykład pobieranie zgłoszeń z formularza, kopiowanie treści artykułu albo informowanie innego zespołu o publikacji.

Większość codziennych potrzeb da się opisać trzema schematami:

• Z formularzy do systemów biznesowych: przesłanie zapytania do CRM, skierowanie zgłoszenia do działu wsparcia albo rejestracja uczestnika wydarzenia.
• Z systemów zewnętrznych do Drupala: utworzenie szkicu na podstawie zatwierdzonego materiału źródłowego albo aktualizacja specyfikacji produktu.
• Z Drupala do systemów zewnętrznych: powiadomienie zespołu o publikacji treści albo przesłanie zmienionych informacji do zewnętrznego katalogu.

Każdy schemat wymaga mapowania pól i uzgodnionych reguł. Samo połączenie systemów nie rozstrzygnie, który rekord w CRM należy zaktualizować ani kto może opublikować zaimportowany artykuł.

Odpowiedzialność za dane trzeba jasno przypisać. Drupal może pozostać nadrzędnym źródłem danych o treściach na stronie, CRM odpowiada za dane klientów, a system PIM (do zarządzania informacjami o produktach) za specyfikacje produktów. Rola n8n ogranicza się do koordynowania przekazywania danych, dzięki czemu narzędzie nie staje się kolejnym repozytorium treści.

Szerzej o tym, jak planować połączenia strony z innymi systemami, piszemy w artykule Integracje CMS z zewnętrznymi systemami i bazami danych - co warto wiedzieć?

Jak webhooki i API łączą oba systemy?

Do opisanych przykładów nie jest potrzebny specjalny konektor dla Drupala. Połączenie zapewniają standardowe węzły n8n: Webhook i HTTP Request.

Z Drupala do n8n: Drupal wysyła żądanie HTTP, gdy wystąpi skonfigurowane zdarzenie. Węzeł Webhook odbiera przesłane dane (payload) i uruchamia workflow w n8n.

Z n8n do Drupala: węzeł HTTP Request wywołuje API Drupala, aby odczytać, utworzyć lub zaktualizować rekordy w zakresie uprawnień konta integracyjnego. Jeśli system źródłowy nie obsługuje wysyłania zdarzeń, n8n może pobierać rekordy według harmonogramu.

Formularz lub zdarzenie dotyczące treści w Drupalu
  → webhook n8n → przetwarzanie i kierowanie danych → CRM / helpdesk / inne API

Zdarzenie zewnętrzne lub zatwierdzona treść
  → workflow n8n → Drupal JSON:API → nowa lub zaktualizowana treść

Odebranie żądania nie oznacza, że zadanie zostało wykonane. Odpowiedź webhooka może potwierdzać tylko, że żądanie dotarło do n8n, a późniejsza operacja w CRM nadal może się nie powieść. Dlatego warto osobno monitorować status żądania HTTP i ostateczny efekt biznesowy.

Jak formularz w Drupalu może utworzyć lub zaktualizować rekord w CRM?

Załóżmy, że formularz zapytania zbiera dane kontaktowe, wiadomość, produkt, którym interesuje się klient, oraz region. W proponowanym scenariuszu Drupal waliduje zgłoszenie i przesyła wybrane wartości do n8n, a workflow wyszukuje pasujący kontakt w CRM.

Jeśli kontakt istnieje, n8n aktualizuje dozwolone pola i dołącza do niego zapytanie. W przeciwnym razie tworzy nowy kontakt. Następnie, zgodnie z uzgodnioną regułą, zapytanie trafia do regionalnej kolejki sprzedaży albo powstaje z niego ticket w systemie wsparcia.

Wybór komponentu, który wysyła dane z Drupala

W przypadku formularzy zbudowanych w module Webform, rozwijanym przez społeczność Drupala, najprostszy sposób wysyłania żądań zapewnia Remote Post handler. Ten handler należy do modułu Webform i nie jest częścią Form API w rdzeniu Drupala. Przed ustaleniem formatu danych i sposobu uwierzytelniania warto sprawdzić opcje dostępne w zainstalowanej wersji modułu.

Opcjonalny projekt Webform Remote Handlers udostępnia handlery REST i SOAP z możliwością konfiguracji przesyłanych danych i uwierzytelniania. To rozwiązanie na wypadek szczególnych wymagań, a nie moduł niezbędny w każdej integracji.

W niestandardowym formularzu Drupala funkcja obsługująca wysyłkę (submit handler) może przekazać zwalidowane wartości do usługi integracyjnej albo do kolejki zadań. Istniejące formularze encji często łatwiej podłączyć przez zdarzenia encji niż przez modyfikowanie każdego formularza z osobna.

Mapowanie pól z myślą o efekcie biznesowym

Niejednoznaczne przypadki warto uzgodnić na wczesnym etapie. Jeśli wyszukiwanie zwróci kilka kontaktów, workflow może przekazać zapytanie do ręcznej weryfikacji, zamiast wybierać kontakt na ślepo. Zgody marketingowe również wymagają osobnego mapowania. Wysłanie zapytania handlowego nie oznacza automatycznie zgody na otrzymywanie komunikacji marketingowej.

Stały identyfikator zgłoszenia pozwala systemowi docelowemu rozpoznać, że te same dane dotarły ponownie. Ma to znaczenie, gdy po przekroczeniu limitu czasu (timeout) n8n ponawia wysyłkę, choć CRM zdążył już zapisać rekord.

Krótszy czas oczekiwania dla użytkownika

Gdy obsługa zgłoszenia ma kilka etapów, przesyłanie danych w tle sprawia, że użytkownik nie czeka na odpowiedź każdego połączonego systemu. Trwała kolejka i mechanizm ponawiania wymagają jednak osobnej implementacji. Sam Remote Post handler takiego mechanizmu nie zapewnia.

Numer rekordu z CRM można też przekazać z powrotem do Drupala – do przygotowanego w tym celu punktu końcowego API (endpointu) albo do innego rekordu, do którego integracja ma uprawnienia. Nie należy zakładać, że moduł JSON:API z rdzenia Drupala pozwala zapisywać każdy element zgłoszenia z Webform. Nie wpływa to jednak na wysyłanie danych na zewnątrz.

Jak zdarzenie w systemie zewnętrznym może utworzyć lub zaktualizować treść w Drupalu?

Załóżmy, że zewnętrzny system redakcyjny oznacza artykuł jako zatwierdzony. Narzędzie n8n odbiera zdarzenie, pobiera rekord źródłowy, mapuje jego pola i tworzy w Drupalu szkic typu Article. Przed publikacją redaktor weryfikuje zaimportowaną treść.

Ten sam schemat pozwala aktualizować istniejące treści. Platforma do obsługi wydarzeń może na przykład odpowiadać za daty wydarzeń, a Drupal za wstęp na stronie i powiązane linki. Zmiana daty powinna zaktualizować pola z datą, nie nadpisując wstępu przygotowanego przez redaktora.

JSON:API do operacji na encjach

Moduł JSON:API w rdzeniu Drupala udostępnia zasoby HTTP oparte na modelu encji i pól danej strony.

Dla typu treści Article typowe operacje to:

• POST /jsonapi/node/article - utworzenie artykułu,
• PATCH /jsonapi/node/article/{uuid} - aktualizacja istniejącego artykułu.

Nazwy zasobów zależą od faktycznego modelu treści na stronie. Węzeł HTTP Request w n8n wysyła uwierzytelnione żądania, a Drupal nadal stosuje walidację i kontrolę dostępu.

Domyślnie JSON:API działa w trybie tylko do odczytu. Zapis wymaga świadomego włączenia, uwierzytelniania i konta o ograniczonych uprawnieniach. Samo włączenie zapisu nie zabezpiecza integracji. Udostępnianie danych przez API opisujemy szerzej w artykule Headless CMS. Jak wystawiać dane z użyciem modułów REST API i JSON API?

Identyfikator rekordu z systemu źródłowego warto przechowywać w uzgodnionym polu albo w osobnym rekordzie mapowania. Przy kolejnych uruchomieniach n8n używa tego identyfikatora, aby odnaleźć encję w Drupalu i pobrać jej UUID. Bez tego każda aktualizacja w systemie źródłowym mogłaby tworzyć kolejny artykuł.

Atrybuty i relacje pełnią różne funkcje

Różnicę dobrze pokazuje proste mapowanie:

Tytuł z systemu zewnętrznego      → attributes.title
Treść z systemu zewnętrznego      → attributes.body.value
ID w systemie źródłowym           → attributes.field_source_id
Kategoria z systemu zewnętrznego  → relationships.field_tags
Obraz z systemu zewnętrznego      → relationships.field_image

Nazwy pól niestandardowych są tu tylko przykładowe.

Atrybuty przechowują wartości pól. Relacje wskazują inne encje, na przykład terminy taksonomii albo media. Te encje muszą już istnieć, a workflow musi znać ich typy zasobów i UUID. Żądanie POST, które tworzy artykuł, nie utworzy automatycznie brakującego terminu ani nie wgra obrazu do encji media.

Trzeba też wybrać dozwolony format tekstu dla treści i walidować przychodzący kod HTML, zamiast uznawać go za bezpieczny tylko dlatego, że pochodzi z innego systemu.

Publikacja jako osobna decyzja

Utworzenie, aktualizacja i publikacja to osobne działania.

Gdy w Drupalu włączone są moduły Workflows i Content Moderation z rdzenia, integracja musi respektować skonfigurowane stany, uprawnienia do przejść między nimi i zasady weryfikacji. Zmiana pola status nie jest uniwersalnym sposobem na obejście moderacji.

Automatyczna publikacja ma sens przy autoryzowanych i zwalidowanych aktualizacjach, takich jak data wydarzenia pobrana z systemu, który za nią odpowiada. Zaimportowane teksty redakcyjne mogą wymagać weryfikacji przez człowieka. Tę granicę warto ustalić osobno dla każdego workflow.

Gdy jedna, ściśle określona operacja obejmuje kilka encji, niestandardowy endpoint bywa czytelniejszy niż kilka ogólnych operacji zapisu. Nadal wymaga on jednak wyraźnie zdefiniowanej autoryzacji i walidacji.

Jak zmiany w Drupalu mogą uruchamiać działania w innych systemach?

Załóżmy, że publikacja artykułu ma powiadomić zespół komunikacji i zaktualizować zewnętrzny katalog. Drupal wysyła do n8n zdarzenie publikacji, a n8n przekazuje odpowiednie dane do każdego systemu docelowego.

Właściwym zdarzeniem jest „artykuł został opublikowany”, a nie „ktoś zapisał artykuł”. Zapisywanie szkiców i edycje niezwiązane z publikacją nie powinny uruchamiać powiadomienia o publikacji.

Wybór i wysłanie zdarzenia w Drupalu

Moduł ECA (Events, Conditions, Actions), rozwijany przez społeczność, pozwala modelować zdarzenia, warunki i akcje. Model ECA może rozpoznać istotną zmianę i wywołać akcję wysyłającą żądanie, o ile taką akcję udostępniają moduły zainstalowane na stronie.

Przed zaplanowaniem dokładnej konfiguracji warto sprawdzić dostępne wtyczki i ich wersje. HTTP Client Manager to moduł społeczności, który pozwala wielokrotnie wykorzystywać zdefiniowane operacje HTTP i bywa wykorzystywany w ekosystemie ECA. Nie jest obowiązkowy przy każdym żądaniu wychodzącym, a dostępne akcje zależą od konfiguracji.

Alternatywą jest własny moduł. Hooki wywoływane przy tworzeniu lub aktualizacji encji mogą dodawać zdarzenie do kolejki, a proces działający w tle (worker) wysyła je za pomocą klienta HTTP Drupala. To podejście sprawdza się, gdy projekt wymaga wyraźnie zdefiniowanej logiki ponawiania albo precyzyjnego wykrywania zmiany stanu treści.

Entity API w Drupalu nie wysyła webhooków automatycznie. Wybór zdarzeń, zawartość przesyłanych danych, mechanizm wysyłki i obsługę dostarczenia trzeba skonfigurować.

Odpowiedni kontekst w danych zdarzenia

Przesyłane dane zdarzenia powinny zawierać identyfikator zdarzenia, UUID encji, typ zdarzenia i pola, których potrzebuje system docelowy. W razie potrzeby n8n może pobrać dodatkowe dane, do których ma uprawnienia.

Decyzja redaktora o publikacji może pełnić funkcję kontroli wykonywanej przez człowieka. Jeśli dalsze działania obejmują wysłanie kampanii, nadal może być potrzebna osobna akceptacja.

Trzeba też zapobiec zapętleniu. Gdy n8n zapisuje w Drupalu identyfikator z systemu zewnętrznego, ta aktualizacja nie powinna ponownie uruchamiać tego samego workflow. Warunki mogą sprawdzać, czy zmieniły się istotne pola i czy zmiana pochodzi z integracji.

Dlaczego model encji w Drupalu ułatwia ponowne wykorzystanie integracji?

Dzięki zdefiniowanym polom nie trzeba wyciągać danych biznesowych z kodu HTML strony. Workflow może bezpośrednio odczytać pole z datą, odwołanie do produktu albo kategorię, zamiast zgadywać, w którym miejscu wyrenderowanej strony się znajdują.

Dwa pojęcia z Drupala pełnią różne role:

• Entity API to wewnętrzny model programistyczny Drupala do obsługi encji.
• JSON:API to interfejs HTTP zbudowany na Entity API i Field API.

Narzędzie n8n korzysta z interfejsu HTTP, a nie z Entity API w PHP.

Gdy uwierzytelnianie, mapowanie identyfikatorów i obsługa błędów są już gotowe, ten sam schemat integracji można wykorzystać dla kolejnego, dobrze zamodelowanego typu treści. Konkretne operacje nadal zależą od tego, czy dana encja je obsługuje, od uprawnień oraz od wymagań dotyczących tłumaczeń i rewizji.

Taka struktura ma znaczenie również w kontekście modeli językowych (LLM). Spójne pola mogą zasilać strony internetowe, kanały danych, API i dane strukturalne, co ogranicza ryzyko pojawienia się sprzecznych informacji w różnych miejscach. Integracje pomagają utrzymać aktualność informacji źródłowych, ale nie gwarantują, że asystenci AI znajdą albo polecą daną stronę.

Krok z wykorzystaniem AI jest opcjonalny. Workflow w n8n może sklasyfikować zapytanie albo przygotować szkic, jeśli zasady przetwarzania danych zostały zatwierdzone, a wynik podlega odpowiedniej weryfikacji. Przekazanie zwalidowanego zgłoszenia z formularza do CRM nie wymaga modelu językowego.

Walidację, reguły dotyczące treści i decyzje o publikacji warto zostawić w Drupalu. Rolą n8n jest przekształcanie danych i koordynacja działań między systemami.

Który komponent odpowiada za które zadanie?

Nie wszystkie wymienione niżej moduły będą potrzebne. Komponenty dobiera się osobno do każdego połączenia.

Co zapewnia niezawodne działanie workflow w n8n?

Dobra integracja sygnalizuje błędy i pozwala ponownie wysłać dane, które nie dotarły do celu. Te kwestie warto uwzględnić już na etapie projektowania workflow:

• Ochrona danych uwierzytelniających. Każda integracja powinna mieć osobne konto z minimalnymi uprawnieniami, uwierzytelnione webhooki i połączenie przez HTTPS. Sekrety należy przechowywać w mechanizmie poświadczeń n8n (credentials) albo w zatwierdzonym magazynie sekretów, a nie w przesyłanych danych ani w eksportowanej definicji workflow. Trzeba też zaplanować ich regularną zmianę.
• Ograniczenie danych osobowych. Warto przesyłać tylko niezbędne pola i świadomie ustawić okres przechowywania logów z wykonań workflow. Nieudane uruchomienia mogą zawierać treść wiadomości i dane kontaktowe.
• Bezpieczne ponawianie. Stałe identyfikatory, sprawdzanie duplikatów i ograniczona liczba ponowień chronią przed podwójnym zapisem. Każdy system docelowy warto śledzić osobno, aby ponowienie nieudanego powiadomienia nie utworzyło kolejnego zapytania w CRM.
• Monitorowanie automatyzacji. Za automatyzację powinna odpowiadać konkretna osoba. Potrzebne są alerty o nieudanych lub zawieszonych wykonaniach oraz kontrola, czy zaplanowane workflow faktycznie się uruchamiają. Poprawne odebranie webhooka nie potwierdza, że dalsze kroki zostały wykonane.
• Granice edycji. Aktualizacje z zewnątrz powinny obejmować tylko pola, za które odpowiada system źródłowy. Jeśli redaktor zmienił tę samą treść, system powinien wykryć konflikt i przekazać go do weryfikacji.

Dzięki tym zabezpieczeniom integracja rzeczywiście oszczędza czas zespołu, zamiast generować dodatkową pracę. Typowe trudności, które pojawiają się na tym etapie, opisujemy w artykule 5 problemów, które mogą pojawić się przy integracji Drupala z zewnętrznymi systemami.

Połącz stronę internetową z dalszymi procesami w firmie

Drupal i n8n mogą usprawnić trzy praktyczne procesy: przesyłanie danych z formularzy do systemów biznesowych, aktualizowanie treści na stronie po zmianach w systemach zewnętrznych oraz uruchamianie dalszych działań po zdarzeniach w Drupalu.

Zdefiniowane encje, pola i mechanizmy kontroli publikacji sprawiają, że Drupal stanowi solidną podstawę do zarządzania treściami. Narzędzie n8n łączy tę podstawę z procesami w firmie, ale nie przejmuje odpowiedzialności za treści.

Który etap ręcznego przekazywania danych zajmuje zespołowi najwięcej czasu? Od niego warto zacząć. Porozmawiajmy o formularzach, zmianach treści i systemach biznesowych, które mają ze sobą współpracować. Pomożemy wskazać niezbędne API, zaplanować mapowanie pól i określić, gdzie potrzebna jest weryfikacja przez człowieka. Więcej o naszej pracy można przeczytać na stronie poświęconej wdrożeniom Drupala.