PIM od strony technicznej: middleware, integracje, DAM

O czym jest ten odcinek

Ósmy odcinek Akademii PIM jest najdłuższą rozmową w serii i jedyną z gościem technicznym. Karolina pyta, a Marcin Żebrowski, senior Symfony developer z Macopedii, odpowiada na pytania, które klienci zadają najczęściej: jak wygląda integracja, czym jest middleware, gdzie trzymać zdjęcia, kto dostarcza serwer i co można dopisać do systemu.

Kluczowe punkty odcinka

• Trzy sposoby integracji: bezpośrednia przy otwartym kodzie, middleware, albo gotowa wtyczka. Zasada jest jedna: gotowe przed własnym.
• Integracja bezpośrednia wiąże Was z platformą. Przy aktualizacji trzeba wszystko przetestować, a przejście na inny system staje się trudne.
• Synchronizacja zwykle raz na dobę, można co 15 minut, ale częstsze przesyły obciążają system. Najlepiej działa wariant hybrydowy z ręcznym wywołaniem.
• Nie hostujcie zdjęć wprost z systemu PIM. Systemy PIM nie są przystosowane do dużego ruchu; zdjęcia wydaje CDN, a PIM trzyma oryginał.
• Przy customizacji lepiej dołożyć funkcję obok, w middleware, niż wpiąć się w kod platformy, bo taka wtyczka może przestać działać po aktualizacji.

Skąd bierze się oszczędność czasu

Pytanie na rozgrzewkę: jak PIM realnie przyspiesza pracę z produktami? Odpowiedź jest prosta i wcale nie technologiczna. Dane są w jednym miejscu.

W wielu firmach informacje leżą w różnych arkuszach w różnych działach, a działy nie wiedzą, że potrzebna im informacja już istnieje w Excelu w innym dziale. Zebranie tego w jednym systemie daje łatwy dostęp, a dopiero na tym da się zbudować integracje z ERP, e-commerce, marketplace’ami i systemem DAM.

Czym jest middleware

Middleware to, jak mówi gość, centrum dowodzenia: aplikacja pośrodku, między systemem PIM, e-commerce i pozostałymi systemami. Przebieg wygląda tak: użytkownik dodaje dane w ERP, middleware je pobiera, przekształca i zapisuje w systemie PIM. W drugą stronę bierze dane z PIM, transformuje i wysyła do e-commerce.

Trzy sposoby integracji

Bezpośrednia. Możliwa, gdy system ma otwarty kod albo pozwala dodawać własne elementy. Zaletą jest mniej pracy programistycznej. Wadą, i to poważną, jest przywiązanie do platformy: przy aktualizacji do wyższej wersji trzeba wszystko przetestować, część rzeczy przestanie działać, a przejście na inny system staje się bardzo trudne.

Middleware. Konieczny przy systemach SaaS z zamkniętym kodem, hostowanych przez producenta. Warto wiedzieć, że nie zawsze buduje się go od zera. Każdy projekt sprawdzany jest pod kątem platform low code, na przykład Mage AI, gdzie dostajecie gotowe przepływy i logowanie błędów, a dopisujecie tylko konkretne fragmenty, jak zamiana jednego atrybutu na drugi.

Wtyczka. Gotowa mała aplikacja, którą się instaluje i konfiguruje. Zaleta: nie budujecie integracji od podstaw. Wada: wtyczki nie zmodyfikujecie pod siebie, więc to Wy dostosowujecie się do niej. Często jednak zmiany po stronie organizacji są na tyle niewielkie, że warto to zrobić i zaoszczędzić czas.

Rekomendacja brzmi: najlepiej znaleźć gotowe rozwiązanie i je wdrożyć. Własny kod piszemy dopiero wtedy, gdy gotowego nie ma. Miks jest w porządku, ze wskazaniem na gotowe.

Jak często dane się synchronizują

Zwykle automatycznie, raz na dobę, na przykład o północy, gdy nikt nie pracuje. Można ustawić co 15 minut, ale trzeba pamiętać, że częste przesyły obciążają system i mogą powodować przestoje.

Najlepiej sprawdza się wariant hybrydowy: automat w nocy plus możliwość ręcznego wywołania integracji, gdy ktoś potrzebuje, żeby zmiana pojawiła się w sklepie natychmiast. Z doświadczenia zespołu: taka opcja znalazła się praktycznie w każdym projekcie.

Ile kosztuje integracja i jak to skrócić

Koszt zależy od złożoności. Przykład z odcinka jest wymowny: integracja z bankiem danych, z której trzeba było przenieść około 300 atrybutów. Licząc po pół godziny na atrybut, wychodzi około 19 dni roboczych. Do tego dochodzi liczba integracji i to, czy system po drugiej stronie już działa. Zdarzyło się integrować z systemem wdrażanym równolegle u klienta: część funkcji nie działała, dokumentacji nie było, i harmonogram się wydłużył.

Sposoby na skrócenie: gotowe elementy middleware przenoszone między projektami, oficjalne paczki popularnych systemów, wtyczki tam, gdzie się nadają, i priorytetyzacja na analizie przedwdrożeniowej, czyli zrobienie na start tylko kluczowych integracji.

Jak się przygotować

Trzy kroki, w tej kolejności.

Audyt atrybutów. Zebranie w jednym miejscu wszystkiego, co macie: w Excelach, w systemie ERP, w DAM, na dyskach. Najpierw trzeba wiedzieć, co jest.

Decyzja, które dane gdzie trafiają. Nie ma sensu wysyłać do systemu wszystkich 300 atrybutów, jeśli wykorzysta on pięć. Trzeba by nimi zarządzać, a integracja kosztuje.

Mapowanie. Przygotowanie danych do wgrania i do przesyłania dalej. Jeśli w systemie PIM macie dane numeryczne, metryczne i zdjęcia, a docelowy system przyjmuje tylko tekst i obrazy, trzeba to przekształcić. To podstawa działania middleware.

Zdjęcia: PIM, DAM czy CDN

Pytanie brzmi: czy PIM może pełnić funkcję systemu DAM? Odpowiedź zależy od potrzeby. Do samego przechowywania, drobnych modyfikacji i udostępniania systemy PIM wystarczą. Jeśli potrzebujecie skalowania zdjęć, generowania miniatur i szerszej obróbki, trzeba wybrać dedykowany DAM.

Najważniejsza jest jednak część o wydawaniu zdjęć. Systemy PIM potrafią udostępniać je bezpośrednio na stronę, ale to nie jest dobre rozwiązanie, bo nie są przystosowane do szybkiego ruchu. Zalecenie: PIM trzyma główne zdjęcie w wysokiej jakości jako źródło prawdy, a wydaje je CDN, który zmienia rozmiar w locie i jest zbudowany pod intensywny ruch.

Formaty danych i migracja

Klucz to przetłumaczenie wszystkiego na wspólny język. Excel wgrywa się przez konfiguratory mapujące kolumny na atrybuty. Dane z innych systemów pobiera się przez API i mapuje transformatorami po swojej stronie. W drugą stronę: zrzut do Excela w formacie pasującym do systemu docelowego albo transformacja w middleware i przesłanie przez API.

Przy pierwszym zasilaniu systemu zespół stosuje metodę, którą gość nazywa wprost brute force: klient dostaje formatkę i uzupełnia ją atrybutami ze swoich arkuszy, potem następuje próba importu, z niej wracają błędy, a na podstawie błędów powstają skrypty poprawiające całe pliki. Po kilku iteracjach import się udaje. Dlaczego tak, a nie przez integracje ze wszystkimi systemami klienta? Bo to jest część pracy, którą klient może wziąć na siebie, i wychodzi taniej oraz szybciej niż budowanie integracji tylko na potrzeby migracji.

Hosting

Zależy od systemu. Wersje darmowe, community i free, są open source i producent nie gwarantuje serwera: serwer dostarcza partner wdrożeniowy albo klient, a instalacja jest po stronie wdrożenia. W modelu SaaS instaluje i utrzymuje producent, bez dostępu do kodu i serwera, a Wy dostajecie gotową platformę.

W praktyce oznacza to, że Akeneo w wersji Enterprise i Ergonode idą w model SaaS, a Akeneo Community i Pimcore Community na własnym serwerze.

Customizacje

Kolejność jest zawsze ta sama: najpierw sprawdzenie App Store danego systemu, bo gotowe jest tańsze niż nowe.

Jeśli gotowego nie ma, przy otwartym kodzie ograniczeniem są tylko finanse, ale trzeba pamiętać, że własna wtyczka może przestać działać po aktualizacji systemu. Dlatego lepszym rozwiązaniem jest zwykle dołożenie funkcji obok, w middleware: wyciągnąć dane, zmodyfikować, zapisać z powrotem. Z trzech omawianych systemów Pimcore jest najbardziej nastawiony na takie modyfikacje.

Pada jeszcze jedna obserwacja, warta zapamiętania: często po dopytaniu o realną potrzebę okazuje się, że istniejące funkcje systemu wystarczają, albo że taniej jest przejść na wyższą wersję licencji, w której dana funkcja już jest, niż budować ją od zera.

Macie pytanie techniczne o swoje wdrożenie? Napiszcie do nas. Więcej na stronie wdrożeń PIM i o integracjach systemów.