Synchronizacja CRM z ERP wygląda prosto, dopóki rozważamy tylko pierwszy zapis rekordu. Prawdziwe problemy pojawiają się później: ten sam kontrahent istnieje już w dwóch systemach, dane są zmieniane po obu stronach, a jedna z aplikacji może być chwilowo niedostępna.
Dlatego integrację warto projektować jako proces, a nie pojedyncze wywołanie API lub zapis do bazy.
Jak rozpoznać ten sam rekord?
Podstawą jest trwałe powiązanie rekordów. Po utworzeniu kontrahenta w ERP warto zapisać jego identyfikator również w CRM. Przy kolejnych operacjach integracja nie musi ponownie zgadywać, który rekord jest właściwy.
Przed pierwszym utworzeniem można dodatkowo wyszukać kontrahenta po jednoznacznej danej biznesowej, np. NIP lub VAT ID, zależnie od rodzaju podmiotu i zasad systemu ERP.
Który system jest źródłem danych?
Dla każdego pola warto ustalić, gdzie może być edytowane i w którym kierunku ma być synchronizowane. Inaczej łatwo stworzyć pętlę, w której CRM aktualizuje ERP, ERP odsyła tę samą zmianę do CRM, a proces uruchamia się ponownie.
Nie wszystkie dane muszą być synchronizowane dwukierunkowo.
Kolejka zamiast blokowania użytkownika
Jeżeli zapis w CRM wymaga natychmiastowej odpowiedzi ERP, awaria drugiego systemu może blokować codzienną pracę. W wielu procesach lepiej oddzielić zapis użytkownika od późniejszej synchronizacji.
Operacja trafia wtedy do kolejki, a osobny proces podejmuje kolejne próby wysłania danych.
Log powinien pomagać rozwiązać problem
Log integracji powinien przede wszystkim odpowiadać na pytanie, dlaczego dana operacja się nie udała. Przy udanych synchronizacjach nie zawsze potrzebna jest rozbudowana historia techniczna widoczna dla użytkownika.
W przypadku błędu warto zapisać co najmniej rodzaj operacji, rekord, czas, komunikat otrzymany z systemu docelowego oraz informację, czy proces będzie ponawiany.
Integracja przez API czy bazę danych?
Najbezpieczniejszym wariantem jest zwykle oficjalne API systemu ERP, jeżeli udostępnia wymagane operacje. Zdarzają się jednak środowiska, w których integracja działa poprzez kontrolowany dostęp do bazy danych.
W takim przypadku trzeba szczególnie dokładnie znać strukturę danych i reguły systemu docelowego. Sam poprawny INSERT nie oznacza jeszcze poprawnego utworzenia kontrahenta, jeżeli aplikacja wymaga dodatkowych powiązań lub wartości generowanych przez własną logikę.
Najpierw scenariusze, później kod
Przed rozpoczęciem implementacji warto opisać przypadki: nowy kontrahent, istniejący kontrahent, zmiana adresu, brak połączenia z ERP, duplikat, błąd walidacji i ponowienie operacji. Dopiero taki zestaw pozwala zaprojektować integrację, która będzie działała również poza scenariuszem idealnym.