Integracja ManageEngine z
Comarch ERP w Polsce

Pytanie o integrację ManageEngine z Comarch ERP to jedno z najczęstszych, które dostaję od polskich firm IT. Problem jest prosty: Comarch ERP zawiera dane o strukturze organizacyjnej, pracownikach i aktywach, a ManageEngine ServiceDesk Plus też potrzebuje tych samych danych. Jeśli dane się rozsynchronizują — helpdesk nie wie do kogo przypisać incydent, jaki center cost rozliczyć, a audit data się nie zgadza. W tym artykule pokazuję architekturę integracji, jak dokładnie przebiega synchronizacja danych, ile czasu zajmuje wdrożenie, i co się działo przy trzech rzeczywistych wdrożeniach u klientów Rotech Group.

Dlaczego ManageEngine + Comarch musi być zintegrowane

Comarch ERP zawiera „źródło prawdy" (source of truth) dla organizacji: kto pracuje w której komórce, jakie są centra kosztów, jakie aktywa należą do jakiego działu, ile ich jest warte. ManageEngine ServiceDesk Plus musi znać te same fakty, żeby móc:

• Przypisać incydenty do prawidłowego OU (Organizational Unit) — gdy zgłosi się pracownik z Działu Logistyki, system musi wiedzieć że pracuje tam i przypisać ticket do logistyki team-u, nie do IT ogólnie
• Rozliczyć koszty na prawidłowy center cost — audit musi pokazać że wsparcie dla Sali Produkcji C5 poszło na CC 4521 (produkcja), nie CC 1200 (IT)
• Znaleźć nowego pracownika przy założeniu konta — HR założyło pracownika w Comarch, ManageEngine musi się domyślić że potrzebuje maila, VPN, konta w systemach
• Śledzić aktywa z dokładnością — gdy IT przydział nowy laptop pracownikowi, numery inventaryzacyjne muszą się zgadywać między Comarch CMDB a ManageEngine CMDB

Jeśli nie ma synchronizacji — dane się rozsynchronizują w ciągu tygodni. Pracownik przeniesie się do innego działu w Comarch, ale w ManageEngine dalej siedzi w starym. Laptop zmieni właściciela w Comarch, ale w helpdesku dalej siedzi przy starym. Koszt rozsynchronizacji (błędne rozliczenia, szukanie pracownika godzinę) przekracza koszt integracji kilkakrotnie.

Co dokładnie synchronizuje integracja

Architektura — API, webhooks, batch sync

Integracja może działać na trzy sposoby, w zależności od możliwości Comarch ERP i wymagań real-time.

Opcja 1: Batch synchronizacja (REST API) — najczęstsze

Harmonogram: co 4 godziny, skrypt pobiera dane z Comarch API i push do ManageEngine API. Prosty do wdrożenia, no dependencies, delay do 4h akceptowalny dla większości. Implementacja: Python/Node.js script, cron job na serwerze.

Opcja 2: Event-based (webhooks) — real-time, ale trudniejsze

Comarch wysyła event webhookem gdy: nowy pracownik, zmiana danych, usunięcie. ManageEngine reaguje natychmiast. Wymaga: Comarch API z webhook support (tylko ERP XL), webhook receiver po stronie ManageEngine. Delay: <1 minuta. Risk: jeśli webhook się nie wyśle, data może się rozsynchronizować w milczeniu.

Opcja 3: Direct database read — ostateczność

Comarch baza danych dostępna bezpośrednio (stare wersje bez API). Skrypt czyta tabelę users bezpośrednio i synchronizuje. Risk: bezpośredni dostęp do produkcyjnej bazy Comarch = ciężko, i jeśli struktura zmieni się w aktualizacji Comarch, skrypt się łamie. Not recommended, tylko gdy Comarch nie ma API.

Rekomendacja Rotech Group: Batch sync (opcja 1) — najprostsze do utrzymania, wystarczająco szybkie (4h), brak ryzyka webhook timeouts. Jeśli wymagane real-time (np. provisioning) — hybrydowy: batch co 4h + event-based tylko dla nowych pracowników.

Harmonogram wdrożenia 3-5 dni

• Dzień 1: Audit danych i analiza API

  Partner przychodzi, zapisuje dostęp do Comarch API, sprawdza dokumentację, testuje endpointy na środowisku testowym. Czy API zwraca strukturę org? Czy jest historię zmian? Czy jest backup strategy?

• Dzień 2-3: Mapowanie pól i prototyp

  Mapowanie: które pole Comarch (e.g. „kod_pracownika") = które pole ManageEngine (e.g. „employee_id"). Prototyp synchronizacji na danych testowych. Testowanie: ktoś zmienia dane w Comarch, czy sync zabiera zmianę poprawnie?

• Dzień 4-5: Wdrożenie, testing na produkcji, go-live

  Deployment skryptu na serwer produkcji, konfiguracja crona, first full sync ze wszystkimi danymi realnymi (bez czyszczenia). Monitoring: czy sync przebiega ok? Czy nie ma błędów? Go-live o 22:00, zanim przyjdą użytkownicy. Następny dzień: monitoring 8:00-16:00.

Limitacje — Comarch XL vs Optima vs Brak API

Case study: Trzy rzeczywiste wdrożenia

Case 1: Fabryka Primario Grande (Comarch XL, 200 pracowników)

Komarch XL z pełnym REST API. Wdrożenie: 6 dni. Synchronizacja: użytkownicy (200), CC (15), aktywa (450). Batch co 4h. Benefit: audit kosztów IT dokładny, w koniec miesiąca controller widział że wsparcie Produkcji kosztowało 12k PLN. Przed: dane w Excelu, brak dokładności. Teraz: automated, brak szans na błąd. Cost: 8k PLN wdrożenia + 500 PLN/mies. utrzymanie.

Case 2: Hurtownia DAAG (Comarch Optima, 80 pracowników)

Comarch Optima bez pełnego API, dokumentacja skromna. Wdrożenie: 4 dni (prostsze bo mniejszy zakres). Synchronizacja: użytkownicy (80), CC (8), aktywa (120). Export nightly z Optima do CSV na share drive, ManageEngine importuje CSV. Delay: 12h (acceptable dla hurtowni). Benefit: znowu audit kosztów, ale też provisioning nowych pracowników. Before: 2 dni zanim nowy pracownik miał konto w helpdesku. Now: 1h (automatycznie). Cost: 5k PLN wdrożenia.

Case 3: Druknia Konopka (Comarch wersja 2019, brak API publicznego)

Comarch wersja 2019, brak dokumentacji API. Rotech zaproponował: upgrade do Optima (szybki path) lub CSV export (riskier). Client wybrał CSV export (budget). Export nightly do share drive z napisanym custom scriptem w Comarch. ManageEngine importuje CSV co rano. Delay: 8h (not great, ale client zaakceptował). Benefit: MINIMAL — głównie że dane się nie duplikują. Cost: 3.5k PLN, ale przy upgrade Comarch w 2027 przejdą na API i będzie szybciej.

Troubleshooting — co idzie nie tak

• Zduplikowanych requesters w ManageEngine

  Pracownik istnieje już w ManageEngine, API Comarch zwraca go jeszcze raz. Rozwiązanie: unique key mapping (np. employee_id z Comarch = custom field w ManageEngine), check na duplicate zanim POST.

• Sync się nie odpalił o 2 w nocy

  Cron job nie odpala. Mogące być: brak dostępu do sieci Comarch (firewall), timeout (API wolny), credentials stare. Fix: monitoring alerting (nagłowek do Slacka jeśli sync fail), retrry logic, timeout extension.

• Pole zmienione w Comarch, ale nie zaktualizowało się w ManageEngine

  Batch sync tylko aktualizuje istniejące, nie usuwa. Dane w Comarch się zmieniły (email), ale w ManageEngine old email zostaje. Fix: upsert logic (update if exists, insert if not, ale zawsze pull latest state).

• Pracownik usunięty z Comarch, ale w ManageEngine dalej active

  Synchronizacja tylko dodaje/zmienia, nie usuwa (safety first). Rozwiązanie: separate sync dla usunięć, disabled requester zamiast delete (zachowuje historię), raport tygodniowy do przeglądu.

Podsumowanie i checklist

Checklist przed wdrożeniem integracji ManageEngine + Comarch:

• Sprawdzić wersję Comarch: XL, Optima czy stara? Czy API dostępny?
• Dostęp do API: Czy IT/Admins mogą dać dostęp do API Comarch? Czy są credentials?
• Dokumentacja: Czy mamy dokumentację API Comarch? Jeśli nie — kontakt do partnera Comarch
• Dane testowe: Czy możliwe wdrożenie na env. testowym zanim produkcja?
• Timeline: Czy znamy czas wdrożenia (3-10 dni zależnie od wersji)?
• Harmonogram: Czy możliwy batch sync co 4h czy wymagane real-time?
• Monitoring: Plan monitorowania synca — na przykład daily raport do Slacka
• Rollback: Czy wiemy jak wycofać się jeśli coś pójdzie nie tak?