Integracja Drupala z PIM i ERP: specyfikacje dla kupujących

Gdy zmienia się specyfikacja produktu, ktoś musi zaktualizować stronę, sprawdzić tabelę porównawczą i znaleźć każdy akapit, w którym nadal pojawia się poprzednia wartość. Ta sama informacja jest wtedy zapisana w kilku miejscach, dlatego łatwo przeoczyć jej nieaktualną wersję. Integracja Drupala z PIM może ograniczyć konieczność wielokrotnego wprowadzania tych samych zmian, ponieważ łączy stronę z systemem PIM, w którym znajdują się zatwierdzone informacje produktowe, oraz z systemem ERP, który przechowuje dane operacyjne.

Podział odpowiedzialności jest prosty. Za wartości produktowe odpowiadają PIM i ERP. Drupal odpowiada za sposób ich prezentacji, wyjaśnienia dla kupujących oraz odpowiedzi na ich pytania. Żeby ta granica działała w praktyce, zespół musi przypisać odpowiedzialność za poszczególne pola.

Kupujący i asystenci AI potrzebują spójnych specyfikacji oraz kontekstu, który pozwala je poprawnie interpretować. Ustrukturyzowane pola w Drupalu pozwalają wielokrotnie wykorzystywać te informacje i uzupełniać je o wyjaśnienia, których zwykle nie ma w rekordzie produktu.

W tym artykule:

• Który system powinien odpowiadać za dane pole produktu?
• Jak mapować atrybuty z PIM na pola w Drupalu?
• Jaki sposób synchronizacji wybrać dla danego typu danych?
• Co się dzieje, gdy dwa systemy zmieniają tę samą wartość?
• Co Drupal powinien zrobić, gdy PIM albo ERP jest niedostępny?
• Jak Drupal zamienia specyfikacje w odpowiedzi dla kupujących?
• Co sprawdzić przed uruchomieniem integracji Drupala z PIM?

Który system powinien odpowiadać za dane pole produktu?

Prace warto zacząć od ustalenia odpowiedzialności za dane, a nie od samego połączenia systemów. Samo działające API nie zapobiegnie sytuacji, w której dwa zespoły zmienią ten sam wymiar w różnych systemach.

Tabela odpowiedzialności za pola daje redakcji i zespołowi technicznemu wspólny punkt odniesienia. Dla każdego pola zespół określa nadrzędne źródło danych, osoby uprawnione do edycji, kierunek synchronizacji i zasady publikacji. Określa również, co powinno się wydarzyć, gdy system źródłowy jest niedostępny.

Okno aktualności określa, jak długo wartość może pozostać opublikowana bez ponownego potwierdzenia w systemie źródłowym. Poniższy podział jest przykładowy. To, który system odpowiada za daną wartość, zależy od miejsca, w którym organizacja ją zatwierdza.

System przekazujący wartość nie musi być jej nadrzędnym źródłem. Identyfikator z ERP może przejść przez PIM, zanim trafi do Drupala. Za identyfikator nadal odpowiada ERP. PIM jedynie przekazuje ten identyfikator do Drupala.

Jeśli oba systemy udostępniają ten sam atrybut, do Drupala powinna prowadzić jedna droga importu. Gdy dwa mechanizmy importu zapisują to samo pole, o jego ostatecznej wartości może zacząć decydować kolejność, w której dotrą aktualizacje.

Równie wyraźnie trzeba oddzielić dane publiczne od danych wewnętrznych. Wewnętrzne koszty zakupu, warunki umów z dostawcami i notatki z procesu zakupowego nie powinny trafiać do danych publikowanych na stronie, chyba że organizacja wyraźnie dopuści ich udostępnianie. Potrzebna jest lista pól dopuszczonych do importu oraz osobne sprawdzenie, co jest widoczne na stronie i w danych udostępnianych na zewnątrz.

W przypadku tłumaczeń również trzeba wskazać system odpowiedzialny za dane. PIM może odpowiadać za przetłumaczone etykiety techniczne, a redaktorzy Drupala za wskazówki zakupowe w danym języku. Zespół określa odpowiedzialność za każde tłumaczone pole, zamiast zakładać, że wszystkie tłumaczenia przygotuje zespół odpowiedzialny za stronę.

Planowanie połączenia Drupala z systemami w firmie opisujemy w artykule Jak zintegrować Drupala z innymi systemami w firmie?.

Jak mapować atrybuty z PIM na pola w Drupalu?

Udokumentowany sposób mapowania skraca czas potrzebny na znalezienie błędów i zapobiega pomyłkom, na przykład wyświetleniu wartości w milimetrach z oznaczeniem cali.

Dla każdego importowanego atrybutu zespół zapisuje:

• kod atrybutu w źródle i docelowe pole w Drupalu,
• typ danych, jednostkę, precyzję i dozwolone wartości,
• język, rynek i wariant, którego dotyczy,
• reguły walidacji oraz zachowanie przy braku danych albo przy danych niepoprawnych,
• czy przyjęta aktualizacja może zostać opublikowana od razu, czy wymaga weryfikacji.

Integracja powinna łączyć rekordy na podstawie stałych identyfikatorów zewnętrznych. Nazwy produktów się zmieniają, a nazwy przetłumaczone mogą brzmieć zupełnie inaczej. Warianty również potrzebują własnych identyfikatorów i jednoznacznych powiązań z produktem, do którego należą. Dzięki temu specyfikacja konkretnego wariantu nie zostanie przypadkowo przypisana do całej rodziny produktów.

Wartość osobno od formatu wyświetlania

Załóżmy, że w PIM maksymalna temperatura pracy została określona na 80°C. Wartość liczbową i jednostkę najlepiej przechowywać osobno, a na stronie łączyć je w jeden zapis.

Taka struktura ułatwia spójne wyświetlanie danych, porównywanie i filtrowanie produktów oraz udostępnianie informacji innym systemom. Umożliwia też przeliczanie jednostek tam, gdzie pozwalają na to reguły dotyczące produktu. Pole tekstowe zawierające zapis „do 80°C” trudniej zweryfikować i ponownie wykorzystać.

Pola, encje i terminy taksonomii w Drupalu są elementami modelu produktu. Integracja nadal wymaga wyraźnie zdefiniowanego mapowania i reguł walidacji. Drupal nie ustala automatycznie biznesowego znaczenia atrybutu ze źródła.

Znaczenie braku wartości

Częściowe aktualizacje wymagają osobnych reguł. Każdy z tych trzech stanów oznacza coś innego:

• Brak atrybutu: przesyłane dane (payload) nie zawierają tego pola, więc jego aktualna wartość pozostaje bez zmian.
• Celowo pusta wartość: źródło przekazuje pustą wartość, a integracja obsługuje ją według reguły danego pola.
• Zamierzone usunięcie: określona operacja w systemie źródłowym powoduje wyczyszczenie albo usunięcie wartości.

Zespół powinien jednoznacznie zdefiniować te przypadki. W przeciwnym razie niepełna odpowiedź może usunąć poprawne specyfikacje.

Relacje i kategorie również wymagają świadomego mapowania. Gdy PIM wprowadzi nową klasyfikację albo nową wartość ze słownika, zespół decyduje, czy Drupal utworzy zmapowany termin taksonomii, wstrzyma aktualizację do weryfikacji, czy odrzuci wartość i wyśle powiadomienie. Opublikowanie nieznanego kodu bez powiadomienia zespołu może prowadzić do wyświetlenia kupującemu niezrozumiałych lub błędnie zinterpretowanych informacji.

Na koniec zespół tworzy w Drupalu pola przeznaczone na treści, których nie ma w PIM: bezpośrednie odpowiedzi, wyjaśnienia i informacje o znaczeniu danego parametru dla określonych grup odbiorców. Importer nie powinien mieć uprawnień do zapisu tych pól. Dzięki temu treści przygotowane przez redakcję pozostają nienaruszone, a PIM nie przejmuje roli systemu zarządzania treścią strony.

Jaki sposób synchronizacji wybrać dla danego typu danych?

Sposób synchronizacji warto dobrać do tego, jak duże opóźnienie w aktualizacji danych firma może zaakceptować. Rzadko zmieniająca się specyfikacja materiału i często aktualizowana informacja o dostępności zwykle wymagają innego sposobu synchronizacji.

Import według harmonogramu pasuje do danych, które zmieniają się rzadko. Zespół uwzględnia wtedy limity liczby zapytań do API, stronicowanie wyników i czas trwania całego przebiegu. Uruchomienie importu co godzinę nie oznacza, że każdy produkt zaktualizuje się w ciągu godziny, jeśli samo przetwarzanie trwa dłużej.

W przypadku importu uruchamianego zdarzeniem powiadomienia o zmianach są zwykle zapisywane w kolejce. Następnie odpowiednie procesy pobierają je z kolejki, weryfikują dane i zapisują aktualizacje. Integracja musi uwzględniać zdarzenia powtórzone, opóźnione i dostarczone w innej kolejności niż zostały utworzone. Powiadomienie może zawierać tylko identyfikator zmienionego produktu. Proces, który je obsługuje, pobiera wtedy aktualny, zatwierdzony rekord.

Odświeżenie na żądanie pozwala zespołowi wsparcia sprawdzić i zaktualizować dane konkretnego produktu bez czekania na kolejny import wsadowy. Osobnej decyzji wymaga pobieranie danych ze źródła w czasie wyświetlania publicznej strony. Czas odpowiedzi strony zależy wtedy bezpośrednio od dostępności i wydajności systemu źródłowego.

Często sprawdza się połączenie trzech mechanizmów: zdarzenia przekazują zmiany, cykliczne porównanie wychwytuje pominięte aktualizacje, a kontrolowane ręczne odświeżenie pozwala obsłużyć konkretny przypadek. Takie połączenie warto stosować, gdy możliwości systemu źródłowego i liczba aktualizacji uzasadniają dodatkowy nakład pracy operacyjnej.

Reguły przetwarzania przed wyborem narzędzi

Niezależnie od sposobu uruchamiania importu potrzebne są te same zabezpieczenia:

• Bezpieczne ponawianie: ponowne przetworzenie aktualizacji nie tworzy zduplikowanych produktów ani nie wykonuje ponownie działań, które powinny wystąpić tylko raz.
• Kontrola wersji: starsza wersja ze źródła nie może nadpisać nowszej wersji, która została już przyjęta.
• Ograniczona liczba ponowień: po chwilowym błędzie integracja ponawia próbę, ale nie obciąża systemu źródłowego bez limitu.
• Zasady publikacji: zespół wie, czy import aktualizuje szkic, opublikowany rekord, czy rewizję w Drupalu oczekującą na akceptację.

Pola, które są od siebie zależne i muszą pozostać spójne, warto aktualizować i weryfikować razem. Opublikowanie nowej wartości ze starą jednostką może wprowadzać w błąd bardziej niż tymczasowe pozostawienie poprzedniego, ale spójnego zestawu danych.

Zanim wartość trafi do asystenta AI, przechodzi kilka etapów:

Zatwierdzona zmiana w PIM
  → pole w Drupalu
  → publikacja i unieważnienie cache
  → skonfigurowane API albo kanał danych (feed)
  → pobranie danych przez asystenta

Osobny indeks wyszukiwania, w tym indeks wykorzystywany w procesie RAG, dodaje kolejny etap wymagający odświeżenia danych. Okno aktualności należy określić dla całego procesu, a nie tylko dla momentu zakończenia importu.

Co się dzieje, gdy dwa systemy zmieniają tę samą wartość?

Redaktor nie powinien poprawiać bezpośrednio w Drupalu wartości, która przy kolejnym imporcie zostanie ponownie pobrana ze źródła.

Załóżmy, że redaktor zauważa błędny wymiar i poprawia go bezpośrednio w Drupalu. W PIM nadal jest poprzednia wartość, więc kolejna synchronizacja przywraca błąd. Korekta redaktora była zasadna, ale w procesie zabrakło jasnej reguły określającej, w którym systemie należy ją wprowadzić.

Pola specyfikacji, za które odpowiada system źródłowy, powinny być dla redaktorów Drupala domyślnie tylko do odczytu. Obok nich potrzebny jest widoczny sposób zgłoszenia korekty w systemie źródłowym. Tę samą granicę zespół techniczny wymusza w formularzach niestandardowych, przy zapisie przez API i w kodzie importera. Ukrycie pola na jednym ekranie edycji nie wystarczy.

Numery wersji albo kolejne numery zmian ze źródła pozwalają odrzucać aktualizacje starsze niż wersja już przyjęta przez system. Znaczniki czasu z różnych systemów bywają niespójne ze względu na różnice między zegarami systemowymi oraz opóźnienia wynikające z przetwarzania danych. Gdy źródło nie udostępnia numeru wersji, potrzebny jest inny mechanizm zapewniający prawidłową kolejność aktualizacji. Integracja może wtedy przetwarzać aktualizacje danego produktu sekwencyjnie i przed każdym zapisem ponownie pobierać aktualny rekord ze źródła.

Tymczasowe nadpisania osobno od importu

Czasem zespół potrzebuje tymczasowego nadpisania, zanim korekta w systemie źródłowym przejdzie akceptację. Takie nadpisanie warto przechowywać osobno od wartości zaimportowanej i zapisać przy nim:

• właściciela nadpisania i powód jego wprowadzenia,
• informację o akceptacji,
• datę wygaśnięcia,
• regułę określającą, która wartość ma być widoczna.

Trzeba również określić, co ma się wydarzyć po wygaśnięciu takiego nadpisania. Po wygaśnięciu integracja przywraca wartość ze źródła albo odsyła produkt do weryfikacji, zależnie od ryzyka.

Warto prowadzić rejestr przyjętych zmian, odrzuconych aktualizacji i nadpisań. Informacja o odrzuconych danych powinna trafić do zespołu, który może je poprawić, wraz z danymi pozwalającymi jednoznacznie wskazać produkt i pole.

Zmiana specyfikacji może też sprawić, że wyjaśnienie napisane w Drupalu przestanie być zgodne z danymi. To zadanie dla redakcji, a nie powód, by importer automatycznie nadpisywał przygotowane wyjaśnienie. W tym miejscu spotykają się odpowiedzialność systemu źródłowego i odpowiedzialność redakcji.

Co Drupal powinien zrobić, gdy PIM albo ERP jest niedostępny?

Strony produktów mogą pozostać dostępne podczas niedostępności systemu źródłowego, jeśli Drupal przechowuje zatwierdzone specyfikacje lokalnie. Odwiedzający widzą wtedy stan opublikowany w Drupalu, zamiast czekać na bieżące zapytanie do PIM przy każdym wyświetleniu strony.

Sama dostępność strony nie wystarcza. Nie każda zapisana informacja powinna być jednak wyświetlana bezterminowo bez ponownego potwierdzenia jej aktualności.

Dla każdego pola zespół ustala, co zrobić, gdy nie udało się go ponownie potwierdzić w źródle. Specyfikacja materiału może pozostać opublikowana także przy dłuższej niedostępności źródła. Informacja o dostępności może wymagać ostrzeżenia albo ukrycia znacznie wcześniej. W przypadku informacji związanych z bezpieczeństwem użytkowania zasady powinny być bardziej rygorystyczne niż w przypadku danych o materiale czy dostępności produktu.

Warto rejestrować co najmniej dwa momenty:

• Ostatnie udane sprawdzenie w źródle: moment, w którym integracja ostatnio potwierdziła rekord.
• Ostatnia zmiana w źródle: moment, w którym wartość w źródle ostatnio się zmieniła.

Specyfikacja, która nie zmieniała się od miesięcy, nadal może być aktualna, jeśli integracja potwierdziła ją dzisiaj w systemie źródłowym. Sam czas od ostatniej zmiany nie rozstrzyga, czy dane są nieaktualne.

W przypadku przekroczenia limitu czasu (timeout), błędu uwierzytelniania albo niepełnej odpowiedzi integracja zachowuje ostatni poprawnie zaimportowany stan. Nieudane żądanie nie powinno być interpretowane jako polecenie usunięcia danych. Ta sama zasada dotyczy importu wsadowego: integracja nie powinna wycofywać produktów z oferty tylko dlatego, że zabrakło ich w niepełnym przebiegu.

Plan przywrócenia działania warto przygotować przed uruchomieniem. Potrzebne są: ograniczona liczba ponowień z narastającym opóźnieniem (backoff), kolejka nieudanych zadań, powiadomienia dla wskazanego zespołu oraz określony sposób ponownego przetworzenia danych. Po przywróceniu dostępności systemu źródłowego integracja porównuje rekordy, aby wykryć zmiany pominięte podczas przerwy.

W tabeli odpowiedzialności można również określić, co w takiej sytuacji zobaczy użytkownik. Wartość może pozostać widoczna wraz z datą ostatniego sprawdzenia lub informacją, że nie udało się ponownie potwierdzić jej aktualności. W innych przypadkach dane mogą zostać ukryte. Wybór zależy od ryzyka biznesowego. Te same zasady powinny obowiązywać zarówno na stronie, jak i w danych udostępnianych innym systemom.

Jak Drupal zamienia specyfikacje w odpowiedzi dla kupujących?

Tabela specyfikacji informuje kupującego o parametrach produktu. Uzupełnienie tych danych o dodatkowy kontekst w Drupalu pomaga mu ocenić, co konkretne wartości oznaczają w jego sytuacji.

Tę różnicę dobrze pokazują trzy rodzaje treści, za które odpowiada Drupal:

• Bezpośrednia odpowiedź: zwięzła odpowiedź na konkretne pytanie kupującego.
• Wyjaśnienie dla kupującego: specyfikacje i warunki stanowiące podstawę odpowiedzi.
• Znaczenie dla grupy odbiorców: wyjaśnienie, dlaczego dany parametr ma znaczenie w konkretnym zastosowaniu albo dla określonych odbiorców.

Załóżmy, że kupujący pyta, czy urządzenie zmieści się w przestrzeni montażowej o szerokości 590 mm. W tym przykładowym przypadku zatwierdzona szerokość produktu wynosi 560 mm, a instrukcja montażu wymaga 20 mm odstępu z każdej strony.

Bezpośrednia odpowiedź może brzmieć: „Nie. Ta przestrzeń jest za wąska, gdy doliczyć wymagany odstęp po bokach.”

Wyjaśnienie pokazuje obliczenie: 560 + 20 + 20 = 600 mm wymaganej szerokości. Kontekst dotyczący danego zastosowania może wyjaśniać, dlaczego instalator powinien sprawdzić wymagane odstępy przed złożeniem zamówienia. Taka informacja jest bardziej przydatna niż sama liczba pozbawiona kontekstu.

Odpowiedź powinna dotyczyć tylko tego, co da się uzasadnić danymi. Sama szerokość nie wystarcza, aby stwierdzić, czy montaż jest możliwy. Znaczenie mogą mieć także głębokość, wysokość, dostęp, wentylacja i inne wymagania. Jeśli w źródle nie ma informacji o wymaganym odstępie, redaktor powinien wskazać w odpowiedzi brak danych, zamiast uzupełniać wymaganie na podstawie przypuszczeń.

Odpowiedzi powiązane z danymi źródłowymi

Gdy to możliwe, liczby ze specyfikacji warto pobierać z pól, zamiast kopiować je ręcznie do kilku akapitów. Redaktor utrzymuje wyjaśnienie, a Drupal wstawia zatwierdzoną wartość.

Zespół określa, które atrybuty ze źródła stanowią podstawę danej odpowiedzi. Zmiana szerokości albo wymaganego odstępu może wtedy automatycznie utworzyć zadanie weryfikacji odpowiedzi dotyczącej montażu, bez kierowania całej strony produktu do ponownej weryfikacji redakcyjnej.

W przypadku wyższego ryzyka odpowiedź może zostać ukryta do czasu weryfikacji. Przy niższym ryzyku wystarczy utworzenie zadania dla redaktora. Tę zasadę warto uzgodnić, zanim zmiana ze źródła pojawi się na stronie.

Drupal może wykorzystać zatwierdzone informacje produktowe i uzupełnienia redakcyjne zarówno na stronach, jak i w danych udostępnianych uprawnionym systemom. JSON-LD, JSON:API, kanały danych i Markdown wymagają osobnej konfiguracji, kontroli dostępu i zasad publikacji. Wspólny model treści pomaga utrzymać spójność informacji we wszystkich tych kanałach. Nie oznacza to jednak, że każde zapisane pole można bezpiecznie udostępnić na zewnątrz.

Wydzielenie porównywalnych wartości do pól opisujemy w artykule Modelowanie treści w Drupalu pod odpowiedzi kupujących: pola zamiast prozy. Udostępnianie danych przez API opisujemy szerzej w artykule Headless CMS. Jak wystawiać dane z użyciem modułów REST API i JSON API?.

Aktualne źródło danych produktowych dla asystentów AI

Połączenie Drupala z zatwierdzonymi rekordami w PIM i ERP zapewnia integracjom AI aktualizowane źródło danych o produktach, zamiast kolejnego katalogu wymagającego ręcznego przepisywania informacji. Gdy szerokość urządzenia zmieni się w PIM, zintegrowany asystent powinien pobrać zaktualizowaną wartość wraz z identyfikatorem produktu, jednostką, wariantem i rynkiem.

Aktualność tych informacji zależy od całego procesu ich pobierania i synchronizacji. Asystent mający dostęp do odpowiednich danych przez API może sprawdzić aktualność pobranej wartości. Publiczne systemy wyszukiwania oparte na AI pobierają i indeksują strony we własnym tempie. Aktualizacja danych w Drupalu nie zmienia danych użytych wcześniej do wytrenowania modelu językowego ani nie gwarantuje, że jego odpowiedź będzie uwzględniać tę zmianę.

Przy pytaniu o montaż asystent potrzebuje także wymagań dotyczących odstępów i istotnych zastrzeżeń. Gdy pobranie danych się nie powiedzie albo zostanie przekroczone ustalone okno aktualności, integracja powinna oznaczyć status danych jako niepewny albo powstrzymać się od przedstawiania wartości jako aktualnej. Nie powinna przedstawiać starszych danych jako aktualnych.

Co sprawdzić przed uruchomieniem integracji Drupala z PIM?

Przed uruchomieniem warto zweryfikować nie tylko samo połączenie, ale przede wszystkim podział odpowiedzialności za dane. Udany import jednego kompletnego produktu niewiele mówi o tym, jak integracja zachowa się przy codziennych zmianach.

Do testów zespół wybiera reprezentatywne produkty, warianty, tłumaczenia i przypadki wycofania produktu z oferty. Następnie sprawdza, jak integracja zachowuje się w następujących sytuacjach:

• Podział odpowiedzialności jest zachowany. Każde importowane pole ma jasno wskazany system nadrzędny. Każde pole uzupełniane w Drupalu ma właściciela redakcyjnego. Import nie nadpisuje treści, za które odpowiada Drupal.
• Powtórzone i dostarczone poza kolejnością aktualizacje są obsługiwane bezpiecznie. Zduplikowane zdarzenia nie tworzą zduplikowanych rekordów, a starsze wersje nie zastępują nowszych wartości.
• Błędy mapowania są widoczne. Niezgodność jednostek, nieznane kategorie i brakujące tłumaczenia są obsługiwane według uzgodnionych reguł. Takie błędy nie mogą prowadzić do niezauważonego opublikowania informacji, które wprowadzają kupującego w błąd.
• Częściowe aktualizacje zachowują poprawne dane. Brak atrybutu, celowo pusta wartość, zamierzone usunięcie i niepełna odpowiedź mają różne skutki.
• Zmiany są poprawnie publikowane na stronie. Korekty ze źródła pojawiają się na publicznych stronach po oczekiwanych krokach publikacji i po unieważnieniu cache.
• Skutki niedostępności źródła są jasno określone. Zachowanie istniejących wartości, oznaczanie danych bez ponownego potwierdzenia, ukrywanie informacji, wysyłanie powiadomień i ponowne przetwarzanie danych odbywają się zgodnie z ustalonymi zasadami.
• Odpowiedzi pozostają powiązane z danymi. Zmiana specyfikacji, na której opiera się odpowiedź, tworzy zadanie weryfikacji dla właściwego redaktora.
• Dane publiczne są zgodne. Strony i udostępniane dane korzystają z tych samych zatwierdzonych wartości i nie zawierają pól wewnętrznych.

Sposób obsługi wycofanych produktów należy sprawdzić osobno. Wycofany produkt może wymagać linku do następcy, usunięcia z kanałów danych albo pozostawienia strony informacyjnej. Właściwy sposób postępowania zależy od potrzeb kupujących i procesów obowiązujących w firmie. Wycofanie produktu ze strony nie powinno być przypadkowym skutkiem błędu importu.

Jeśli zakres prac obejmuje połączonego asystenta AI, warto sprawdzić, jakie dane faktycznie pobiera on po wprowadzeniu korekty w systemie źródłowym. Test powinien uwzględniać pośrednie warstwy cache i indeksy wyszukiwania oraz obejmować nie tylko poprawnie zaktualizowane dane, ale także rekordy nieaktualne i produkty wycofane.

Na koniec warto zapisać mierzalne kryteria odbioru: uzgodnione okno aktualności, uprawnienia do zapisu poszczególnych pól, zasady działania podczas niedostępności źródła oraz sposób weryfikacji odpowiedzi zależnych od zmienionych danych. Dzięki tym kryteriom cały zespół rozumie, jakie warunki muszą zostać spełnione przed uruchomieniem integracji.

Trudności, które często wychodzą na jaw dopiero przy codziennych zmianach, opisujemy w artykule 5 problemów, które mogą pojawić się przy integracji Drupala z zewnętrznymi systemami.

Od czego zacząć integrację Drupala z PIM i ERP?

Jasny podział odpowiedzialności za pola ogranicza konieczność wielokrotnego wprowadzania tych samych zmian i chroni treści uzupełniane przez zespół redakcyjny. PIM i ERP pozostają nadrzędnymi źródłami zatwierdzonych danych produktowych. Drupal prezentuje te wartości w sposób przydatny dla kupujących i udostępnia je systemom, które mają odpowiednie uprawnienia.

Które specyfikacje zespół nadal ręcznie przenosi na stronę? To od nich warto zacząć. Na rozmowę wystarczy przykładowy zestaw danych z PIM albo ERP oraz przykładowa strona produktu. Porozmawiajmy o tym, który system powinien odpowiadać za poszczególne pola, jak powinna przebiegać synchronizacja i jakiego dodatkowego kontekstu potrzebują kupujący w Drupalu. Więcej o naszej pracy można przeczytać na stronie poświęconej wdrożeniom Drupala.