Integracja Pimcore z ERP, e‑commerce i innymi systemami
Projektujemy i wdrażamy połączenia Pimcore z ERP, WMS, platformą e‑commerce, marketplace i innymi systemami.
Ustalamy, gdzie powstają dane, w jakim kierunku mają płynąć i jak często powinny być synchronizowane.
- Nowe integracje
- Przebudowa połączeń
- API i Pimcore Datahub
- Importy i eksporty
- Synchronizacja i obsługa błędów
Każdy rodzaj danych musi mieć ustalone źródło i właściciela
Opis produktu może być edytowany w Pimcore, cena w ERP, stan magazynowy w WMS, a zamówienie powstaje w sklepie. Integracja musi odzwierciedlać ten podział.
Problemy zaczynają się wtedy, gdy dwa systemy mogą nadpisywać tę samą informację albo żaden zespół nie wie, gdzie znajduje się prawidłowa wersja danych. Pojawiają się duplikaty, niepełne aktualizacje oraz rozbieżności pomiędzy kanałami.
Przed zaprojektowaniem połączeń ustalamy odpowiedzialność za każdy zestaw danych. Dopiero później określamy API, częstotliwość synchronizacji i reguły przetwarzania.
| Rodzaj danych | Możliwe źródło | Przykładowi odbiorcy |
|---|---|---|
| Identyfikatory i podstawowe dane produktów | ERP lub Pimcore | Pimcore, sklep, WMS |
| Opisy, atrybuty, tłumaczenia i multimedia | Najczęściej Pimcore | Sklep, marketplace, katalogi |
| Ceny i warunki handlowe | ERP lub system cenowy | Sklep, B2B, marketplace |
| Stany i dostępność | WMS lub ERP | Sklep, marketplace |
| Zamówienia | Platforma e‑commerce | ERP, WMS, CRM |
| Dane klientów i kont B2B | CRM, ERP lub e‑commerce | Systemy sprzedażowe i obsługowe |
Identyfikatory i podstawowe dane produktów
Możliwe źródło
ERP lub Pimcore
Przykładowi odbiorcy
Pimcore, sklep, WMS
Opisy, atrybuty, tłumaczenia i multimedia
Możliwe źródło
Najczęściej Pimcore
Przykładowi odbiorcy
Sklep, marketplace, katalogi
Ceny i warunki handlowe
Możliwe źródło
ERP lub system cenowy
Przykładowi odbiorcy
Sklep, B2B, marketplace
Stany i dostępność
Możliwe źródło
WMS lub ERP
Przykładowi odbiorcy
Sklep, marketplace
Zamówienia
Możliwe źródło
Platforma e‑commerce
Przykładowi odbiorcy
ERP, WMS, CRM
Dane klientów i kont B2B
Możliwe źródło
CRM, ERP lub e‑commerce
Przykładowi odbiorcy
Systemy sprzedażowe i obsługowe
Powyższy podział jest przykładem. Właściwa mapa zależy od procesów oraz odpowiedzialności w konkretnej organizacji.
Jeżeli model danych w samym Pimcore nie został jeszcze zaprojektowany, zakres powinien rozpocząć się od wdrożenia Pimcore.
Z jakimi systemami można zintegrować Pimcore?
Zakres integracji wynika z procesów firmy. Inaczej wygląda połączenie Pimcore ze sklepem, inaczej synchronizacja z ERP, a jeszcze inaczej dystrybucja danych do wielu marketplace.
Poniżej są systemy, które najczęściej uczestniczą w takim projekcie, oraz to, po co wymieniają dane z Pimcore. Podczas analizy sprawdzamy również zależności między nimi: zmiana identyfikatora w ERP może wpłynąć na produkt w Pimcore, ofertę marketplace, indeks w magazynie i pozycję zamówienia.
Systemy w architekturze
- ERP
- Dane podstawowe produktów, indeksy, ceny, kontrahenci, warunki handlowe i dokumenty sprzedażowe. Zakres zależy od roli ERP w organizacji.
- Magento 2
- Sklep odbiera dane produktowe, atrybuty, kategorie i multimedia, a zamówienia oraz wybrane dane klientów mogą wracać do systemów operacyjnych.
- Shopify
- Ten sam podział przy innym modelu danych platformy: Pimcore przygotowuje zakres pól i mediów, który Shopify potrafi przyjąć i pokazać w ofercie.
- WMS
- Stany magazynowe, lokalizacje, rezerwacje, status kompletacji i informacje o dostępności.
- CRM
- Dane kont, segmentów, klientów B2B, opiekunów oraz informacje potrzebne zespołowi sprzedaży.
- Marketplace
- Pimcore może przygotowywać osobne nazwy, opisy i atrybuty dla konkretnego kanału. Integracja powinna też zapisywać status publikacji i powód odrzucenia oferty.
- Hurtownie danych i BI
- Eksport danych produktowych, statusów kompletności i historii zmian do raportowania — zwykle wsadowo i w jedną stronę.
- Systemy dostawców
- Karty produktowe, atrybuty i multimedia od producentów lub importerów, przyjmowane w formatach, w jakich są udostępniane, i mapowane na własny model.
- Aplikacje mobilne
- Aplikacje sprzedażowe, serwisowe i magazynowe pobierające dane przez API, zwykle w węższym zakresie niż sklep.
- Serwisy produktowe
- Porównywarki, portale branżowe i serwisy z kartami produktów, które oczekują własnego zestawu pól i własnej struktury kategorii.
- Katalogi i DTP
- Dane oraz multimedia wykorzystywane do katalogów, kart produktowych, materiałów dla dystrybutorów i wydruków.
- Feedy produktowe
- Pliki generowane dla reklam, porównywarek i partnerów: własny zakres pól, własny format i własny harmonogram publikacji.
To nie jest lista gotowych konektorów. Sposób integracji zależy od tego, co udostępnia konkretny system — jego API, formaty, limity, uwierzytelnianie i możliwość powiadamiania o zmianach. Ten sam typ systemu u dwóch firm potrafi wymagać dwóch różnych rozwiązań.
Jak przepływają dane między Pimcore, ERP i sklepem internetowym?
Podstawowy model jest prosty: ERP i dostawcy zasilają Pimcore, Pimcore porządkuje informacje i przekazuje je do Magento 2, Shopify, marketplace'ów, katalogów oraz aplikacji.
W konkretnych integracjach część danych płynie w przeciwnym kierunku — zamówienia, dane klientów albo statusy publikacji wracają do systemów, które za nie odpowiadają. Kierunek dla każdego rodzaju danych ustalamy osobno, razem z jego źródłem i właścicielem.
Przykładowe kierunki
ERPPimcore
Indeksy i dane bazowe produktów, a zależnie od architektury również ceny lub stany magazynowe. Pimcore traktuje je jako dane tylko do odczytu, jeżeli ich źródłem pozostaje ERP.
Pimcoree‑commerce
Opisy, atrybuty, relacje produktowe, multimedia i tłumaczenia — w zakresie i formacie, którego oczekuje konkretny kanał, po spełnieniu warunków publikacji.
e‑commercePimcore
Dane wymagające synchronizacji zwrotnej, jeżeli przewiduje to architektura projektu: statusy publikacji, treści tworzone w kanale albo informacje o odrzuconych ofertach.
systemy źródłowe
- ERP
- WMS
- CRM
Pimcore
- E‑commerce
- Marketplace
- Katalogi i DTP
kanały i odbiorcy
Ceny i stany magazynowe mogą trafiać z ERP lub WMS bezpośrednio do sklepu, bez przechodzenia przez Pimcore.
Pimcore Datahub – GraphQL, REST, webhooki i eksporty
Pimcore nie wymusza jednego sposobu wymiany danych. Datahub pozwala budować endpointy GraphQL, sama platforma udostępnia API, a ekosystem obejmuje mechanizmy webhooków i pozostałe adaptery integracyjne.
Mechanizm dobieramy do odbiorcy i do tego, jak szybko potrzebuje danych. Jeden projekt korzysta z kilku naraz: sklep pobiera dane przez API, hurtownia dostaje plik nocą, a marketplace jest powiadamiany o zmianie zdjęcia.
Do czego używamy poszczególnych mechanizmów
GraphQL
Odbiorca sam decyduje, które pola i relacje pobiera jednym zapytaniem. Sprawdza się przy aplikacjach i frontendach, które potrzebują węższego zakresu niż pełny eksport produktu.
REST
Proste, przewidywalne operacje na obiektach i zasobach — wygodne dla systemów, które oczekują klasycznego API i obsługują je od lat.
Webhooki
Powiadomienie o zdarzeniu zamiast cyklicznego pytania „czy coś się zmieniło”. Skracają czas między zmianą w Pimcore a aktualizacją w kanale i zdejmują obciążenie z odpytywania.
Eksporty danych
Pliki w ustalonym formacie i harmonogramie, dla odbiorców, którzy nie mają API albo świadomie pracują wsadowo: hurtownie, katalogi, feedy, partnerzy handlowi.
Osobne endpointy dla różnych odbiorców
Każdy kanał dostaje własny zakres pól, własne tłumaczenia i własne reguły widoczności. Zmiana dla jednego odbiorcy nie rusza pozostałych, a uprawnienia i limity są nadawane per endpoint.
Nie każda integracja idzie przez Datahub. Część połączeń powstaje jako własny konektor, część jako import po stronie systemu docelowego, a część opiera się na kolejkach — wybór wynika z architektury projektu, wolumenu i wymagań dotyczących czasu reakcji. Zasady, które ustalamy przed developmentem, opisuje sekcja o decyzjach integracyjnych.
Integracja Pimcore z Magento 2 i Shopify
Podział odpowiedzialności jest ten sam na obu platformach: Pimcore prowadzi informację o produkcie, a sklep odpowiada za prezentację oferty i proces sprzedaży. Różni się to, jaki zakres danych platforma potrafi przyjąć.
Pimcore
przechowuje i zarządza
- produktami
- atrybutami
- kategoriami
- opisami
- relacjami produktowymi
- mediami
- tłumaczeniami
- danymi specyficznymi dla kanałów
Magento 2 i Shopify
odpowiadają za
- prezentację oferty
- wyszukiwanie i nawigację
- koszyk i checkout
- ceny widoczne dla klienta
- promocje i reguły sprzedaży
- konta klientów
- zamówienia i płatności
- obsługę posprzedażową
Jak synchronizujemy poszczególne dane
- Produkty
- Rekord w Pimcore ma swój odpowiednik w sklepie, rozpoznawany po ustalonym identyfikatorze. Nowe produkty powstają dopiero po spełnieniu warunków kompletności.
- Kategorie
- Struktura sklepu może różnić się od tej w Pimcore. Wtedy synchronizacja korzysta z osobnego drzewa przypisanego do kanału, a nie z drzewa wewnętrznego.
- Atrybuty
- Pola i słowniki mapujemy na atrybuty platformy razem z jednostkami i typami. Wartości spoza słownika są błędem walidacji, nie nową wartością w sklepie.
- Zdjęcia
- Media idą z DAM razem z kolejnością, rolami (główne, galeria) i tekstem alternatywnym. Ponownie wysyłamy tylko pliki, które się zmieniły.
- Dokumenty
- Instrukcje, certyfikaty i karty techniczne trafiają do sklepu jako pliki powiązane z produktem albo jako odnośniki, zależnie od tego, co obsługuje platforma.
- Wersje językowe
- Tłumaczenia wchodzą w odpowiednie widoki sklepu lub rynki Shopify. Brak tłumaczenia jest widoczny w Pimcore przed publikacją, a nie po niej.
- Dane specyficzne dla kanałów
- Skrócone nazwy, inne opisy albo węższy zestaw atrybutów przygotowujemy w Pimcore jako dane kanału — sklep nie musi ich nadpisywać po swojej stronie.
Zakres i sposób połączenia zależą od wersji platformy oraz jej modelu danych. Usługi dla obu środowisk opisujemy osobno: Magento 2 i Shopify.
Przepływ podstawowy jest łatwy. Zakres ujawniają sytuacje wyjątkowe
Wysłanie prawidłowego produktu z jednego systemu do drugiego rzadko stanowi największy problem. Integracja musi także wiedzieć, co zrobić z niepełnymi danymi, duplikatem, błędem autoryzacji albo niedostępnym systemem.
Przed rozpoczęciem developmentu ustalamy zasady, które później można jednoznacznie przetestować. Zespół klienta widzi, jak dane będą przetwarzane i jakie decyzje pozostają po jego stronie.
- 01
Źródło i właściciel danych
Który system tworzy informację i kto może ją zmienić?
- 02
Identyfikatory
W jaki sposób ten sam produkt, wariant, klient lub zamówienie jest rozpoznawane w różnych systemach?
- 03
Mapowanie i transformacje
Jak pola, jednostki, słowniki i relacje mają zostać przeliczone lub przekształcone?
- 04
Kierunek oraz moment synchronizacji
Czy dane są pobierane cyklicznie, wysyłane po zdarzeniu czy odczytywane na żądanie?
- 05
Walidacja
Które dane są wymagane i co wydarzy się, gdy rekord nie spełnia reguł?
- 06
Błędy i ponowienia
Które operacje mogą zostać ponowione automatycznie, a które wymagają decyzji człowieka?
- 07
Dostęp i bezpieczeństwo
Jak zostaną obsłużone uprawnienia, klucze, tokeny, zakres danych oraz środowiska?
- 08
Uruchomienie i porównanie danych
Jak zweryfikujemy, czy po starcie oba systemy zawierają zgodne informacje?
Projekt prowadzimy od mapy danych do kontrolowanego uruchomienia
Zakres i estymację implementacji potwierdzamy po sprawdzeniu systemów, dostępnych interfejsów i jakości danych. Wcześniejsza wycena opierałaby się głównie na założeniach.
- 01
Rozpoznanie systemów i procesu
Sprawdzamy, jakie systemy uczestniczą w procesie, kto nimi zarządza oraz jakie interfejsy są dostępne. Zbieramy przykładowe dane, dokumentację i ograniczenia techniczne.
RezultatMapa systemów, lista zależności i obszary wymagające decyzji.
- 02
Mapa danych i odpowiedzialności
Określamy źródła danych, kierunki przepływu, identyfikatory, częstotliwość aktualizacji oraz właścicieli biznesowych.
RezultatMacierz odpowiedzialności i mapa przepływów.
- 03
Specyfikacja techniczna
Opisujemy endpointy, zdarzenia, formaty, transformacje, walidację, uprawnienia, obsługę błędów oraz wymagania dotyczące monitoringu.
RezultatZakres implementacji, kryteria odbioru i zaktualizowana estymacja.
- 04
Implementacja i testy
Budujemy połączenia oraz sprawdzamy prawidłowe dane, przypadki brzegowe, niedostępność systemów i reakcję na błędy.
RezultatDziałająca integracja na środowisku testowym oraz raport z testów.
- 05
Pilot i dane startowe
Uruchamiamy przepływ na ograniczonym zakresie danych albo wybranym kanale. Porównujemy wyniki ze źródłami i poprawiamy rozbieżności.
RezultatPotwierdzona gotowość do uruchomienia pełnego zakresu.
- 06
Produkcja, monitoring i dokumentacja
Integracja zostaje uruchomiona zgodnie z ustalonym planem. Dokumentujemy konfigurację, zależności, procedury oraz sposób diagnozowania problemów.
RezultatDziałające połączenie i materiały potrzebne do jego dalszego utrzymania.
Integracja obejmuje przepływ danych, kontrolę błędów i dokumentację
Połączenie musi dać się bezpiecznie uruchomić, monitorować i dalej rozwijać. Dlatego zakres obejmuje nie tylko wymianę danych, ale również walidację, obsługę błędów, bezpieczeństwo, testy i dokumentację.
| Obszar | Rezultat |
|---|---|
| Analiza systemów | Lista systemów, właścicieli, interfejsów i ograniczeń |
| Mapa danych | Źródła, odbiorcy, identyfikatory i kierunki przepływu |
| Kontrakty danych | Format komunikatów, pola wymagane, wersjonowanie i przykłady |
| Mapowanie | Reguły transformacji pól, słowników, jednostek i relacji |
| Endpointy i connectory | Implementacja połączeń wynikających z zaakceptowanej architektury |
| Bezpieczeństwo | Model dostępu, uwierzytelnianie, uprawnienia i sposób przechowywania sekretów |
| Harmonogram lub zdarzenia | Reguły uruchamiania synchronizacji |
| Obsługa błędów | Walidacja, logowanie, ponowienia, alerty i raporty rozbieżności |
| Testy | Scenariusze poprawne, przypadki brzegowe i niedostępność systemów |
| Uruchomienie | Plan wdrożenia, kontrola danych i procedura wycofania zmiany |
| Dokumentacja | Opis architektury, konfiguracji, zależności i procedur operacyjnych |
Analiza systemów
Lista systemów, właścicieli, interfejsów i ograniczeń
Mapa danych
Źródła, odbiorcy, identyfikatory i kierunki przepływu
Kontrakty danych
Format komunikatów, pola wymagane, wersjonowanie i przykłady
Mapowanie
Reguły transformacji pól, słowników, jednostek i relacji
Endpointy i connectory
Implementacja połączeń wynikających z zaakceptowanej architektury
Bezpieczeństwo
Model dostępu, uwierzytelnianie, uprawnienia i sposób przechowywania sekretów
Harmonogram lub zdarzenia
Reguły uruchamiania synchronizacji
Obsługa błędów
Walidacja, logowanie, ponowienia, alerty i raporty rozbieżności
Testy
Scenariusze poprawne, przypadki brzegowe i niedostępność systemów
Uruchomienie
Plan wdrożenia, kontrola danych i procedura wycofania zmiany
Dokumentacja
Opis architektury, konfiguracji, zależności i procedur operacyjnych
Bieżącą obsługę działających połączeń opisujemy w usłudze Utrzymanie Pimcore.
Ile kosztuje integracja Pimcore?
Jednej ceny nie podajemy, bo dwie integracje o tej samej nazwie potrafią różnić się kilkukrotnie pracochłonnością. Poniżej jest dziesięć rzeczy, które o niej decydują — przy każdej wiadomo, czego szukać we własnym projekcie.
Co decyduje o wycenie
- Liczba integrowanych systemów
- Każdy system to własne API, uwierzytelnianie, limity i właściciel po drugiej stronie. Trzy połączenia to nie trzy razy jedno — dochodzi kolejność i zależności między nimi.
- Liczba typów danych
- Produkty, atrybuty, media, ceny, stany, zamówienia i klienci to osobne kontrakty, osobne mapowania i osobne scenariusze testowe.
- Kierunek przepływu danych
- Wymiana w jedną stronę jest prostsza niż dwukierunkowa: przy dwóch kierunkach trzeba rozstrzygnąć konflikty i zdecydować, który system wygrywa przy rozbieżności.
- Częstotliwość synchronizacji
- Nocny wsad kosztuje mniej niż aktualizacja liczona w minutach. Krótszy czas reakcji zwykle oznacza zdarzenia, kolejki i osobną obsługę spiętrzeń.
- Jakość API systemów zewnętrznych
- Udokumentowane API z filtrowaniem i stronicowaniem to inna praca niż eksport bez wersjonowania albo interfejs, który nie mówi, co się zmieniło od ostatniego pobrania.
- Transformacje danych
- Przeliczanie jednostek, scalanie pól, podział wartości opisowych i mapowanie słowników. Im dalej modele obu stron są od siebie, tym więcej reguł do napisania i przetestowania.
- Reguły biznesowe
- Warunki publikacji, wyjątki dla rynków, zakresy danych dla kanałów i decyzje typu „czego nie wysyłamy”. To one, a nie samo połączenie, zwykle zajmują najwięcej czasu.
- Kolejki
- Przy większym wolumenie potrzebne jest kolejkowanie, kontrola równoległości i odporność na częściowe przetworzenie paczki danych.
- Obsługa błędów
- Walidacja, statusy przetwarzania, ponowienia, raporty rozbieżności i decyzja, co dzieje się z rekordem, którego nie da się przetworzyć.
- Monitoring integracji
- Alerty, widoczność stanu synchronizacji dla zespołu klienta i sposób sprawdzenia, czy przepływ działa — bez tego awaria ujawnia się dopiero brakiem produktu w kanale.
Estymację implementacji potwierdzamy po sprawdzeniu interfejsów i przykładowych danych — wcześniejsza wycena opierałaby się na założeniach o cudzych systemach. Bieżącą obsługę działających połączeń opisuje utrzymanie Pimcore.
FAQ – integracje Pimcore
Odpowiedzi mają pomóc ocenić zakres, systemy, czas i sposób obsługi integracji.
Omówmy integrację PimcoreTak i jest to najczęstsze połączenie w takim projekcie. ERP zwykle zostaje źródłem indeksów, danych bazowych, a często również cen i stanów; Pimcore przejmuje opisy, atrybuty, relacje, tłumaczenia i multimedia. Sposób połączenia zależy od tego, co udostępnia konkretny ERP — API, eksport plikowy albo bezpośredni dostęp do bazy. Pełną listę systemów zebraliśmy w sekcji o systemach w architekturze.
Tak. Pimcore przekazuje produkty, kategorie, atrybuty, media i tłumaczenia, a Magento 2 zostaje odpowiedzialne za prezentację oferty i proces sprzedaży. Zamówienia i wybrane dane klientów mogą wracać do systemów operacyjnych. Podział odpowiedzialności opisuje sekcja o integracji z Magento 2 i Shopify, a samą platformę — usługi Magento 2.
Tak, przy tym samym podziale odpowiedzialności co na Magento 2. Różnica jest w modelu danych platformy: Shopify przyjmuje węższy zakres pól i inaczej obsługuje warianty oraz rynki, więc zakres danych kanału ustalamy pod jego możliwości. Szczegóły są w sekcji o integracji z Magento 2 i Shopify oraz w usługach Shopify.
Tak. Platforma udostępnia API do obiektów i zasobów, a Datahub pozwala zbudować własne endpointy GraphQL dla konkretnego odbiorcy. W praktyce w jednym projekcie używamy kilku mechanizmów naraz — opisuje je sekcja o Datahubie i API.
To narzędzie Pimcore do udostępniania danych na zewnątrz: pozwala zdefiniować endpointy GraphQL, wskazać, które klasy, pola i relacje są w nich widoczne, oraz nadać im osobne uprawnienia. Dzięki temu każdy odbiorca może dostać własny zakres danych bez pisania osobnego eksportu. Datahub nie jest jednak jedyną drogą — część integracji realizujemy jako własne konektory, importy albo przepływy oparte na kolejkach.
Zwykle mówimy o synchronizacji zdarzeniowej: zmiana w Pimcore uruchamia powiadomienie albo zadanie, a kanał dostaje dane w ciągu sekund lub minut. Pełny czas rzeczywisty rzadko jest potrzebny i bywa kosztowny — przy dużym wolumenie i tak trzeba kolejkować, żeby jedna masowa zmiana nie zablokowała pozostałych. Ceny i stany, które muszą być aktualne w chwili zakupu, częściej płyną z ERP lub WMS wprost do sklepu, z pominięciem Pimcore.
Tak i to jest typowe zastosowanie. Każdy dostawca ma własny format, własne nazwy pól i własną jakość danych, więc dla każdego powstaje osobne mapowanie oraz reguły walidacji. Ustalamy też klucz rozpoznawania produktu i zasadę pierwszeństwa, gdy dwa źródła podają inną wartość tego samego pola.
Tak i zwykle po to się go wdraża. Każdy kanał dostaje własny zakres pól, tłumaczeń i mediów oraz własną definicję kompletności — produkt gotowy do publikacji w jednym sklepie nie musi być gotowy w marketplace. Osobne endpointy albo eksporty pozwalają zmienić zakres dla jednego odbiorcy bez ruszania pozostałych.
Taki warunek nie jest przyjmowany z góry. Najpierw sprawdzamy możliwości obecnych systemów, dokumentację oraz jakość dostępnych danych. Zmiana systemu może okazać się potrzebna, gdy jego ograniczenia uniemożliwiają wymagany przepływ, ale jest to osobna decyzja.
Nie muszą. Źródło każdego rodzaju danych wynika z procesów organizacji. Ceny mogą pozostać w ERP, a stany w WMS. Pimcore może odpowiadać za opisy, atrybuty, relacje, tłumaczenia i multimedia.
Tak, strona dotyczy również przebudowy połączeń, których rozwój jest kosztowny, obsługa błędów niewystarczająca albo dokumentacja nie odpowiada aktualnemu działaniu. Pierwszym etapem jest sprawdzenie kodu, danych, interfejsów i zależności.
Zakres zależy od liczby systemów, struktury danych, wolumenu, częstotliwości synchronizacji, dostępności dokumentacji oraz liczby sytuacji wyjątkowych. Wszystkie dziesięć czynników rozpisaliśmy w sekcji o koszcie integracji. Estymacja implementacji powinna zostać potwierdzona po analizie interfejsów i przykładowych danych.
Mechanizm może obejmować walidację, statusy przetwarzania, logi, kontrolowane ponowienia, alerty i raporty rozbieżności. Dokładny sposób zależy od architektury oraz znaczenia danego przepływu dla sprzedaży.
Dostęp do danych w Pimcore idzie przez API, a nie przez wspólną bazę: każde połączenie wymaga własnego uwierzytelnienia, a transmisja odbywa się po HTTPS. Zakres uprawnień — które systemy mogą czytać, które zapisywać i do jakich danych — jest częścią zakresu integracji, nie ustawieniem domyślnym.Sposób przechowywania danych dostępowych oraz to, kto nimi zarządza po uruchomieniu, ustalamy razem z osobami administrującymi każdym z połączonych systemów. Bez tego nie da się rozdzielić odpowiedzialności za dostępy między nami, klientem i dostawcami pozostałych systemów.
Zakres dokumentacji powinien obejmować architekturę, przepływy danych, konfigurację, kontrakty, mapowanie, scenariusze testowe i procedury operacyjne. Ostateczna lista zostaje określona w zakresie projektu.
Po zakończeniu projektu połączenie może zostać przekazane zespołowi klienta albo objęte dalszym utrzymaniem. Zakres stałej obsługi należy ustalić osobno, na podstawie liczby integracji i wymaganej dostępności. Poznaj zakres Utrzymania Pimcore.
Zacznijmy od mapy systemów i danych, które mają się między nimi przemieszczać
Podczas pierwszej rozmowy sprawdzimy obecną architekturę, rolę Pimcore, systemy wymagające połączenia i najważniejsze problemy z wymianą danych. Po rozmowie wskażemy, czy projekt powinien rozpocząć się od analizy integracyjnej, wdrożenia nowego połączenia, przebudowy obecnego rozwiązania albo uporządkowania samego Pimcore.
Do rozmowy wystarczy podstawowa lista systemów oraz krótki opis danych, które mają być pomiędzy nimi wymieniane. Dokumentacja API lub diagram obecnej architektury będą pomocne, ale nie są wymagane do pierwszego kontaktu.
