Limity API Comarch ERP Optima: sufity, o których dowiadujecie się za późno

Limit, którego nie ma

API Optimy nie ma limitu zapytań. Comarch nie publikuje żadnej liczby, pod którą dałoby się wymiarować synchronizację — i jest to kłopot, a nie przyzwolenie, na jakie wygląda.

Ludzie słyszą „brak limitu" i rozumieją: można, ile się chce. Odwrotnie.

Limit to kontrakt. Mówi, jak szybko wolno jechać, a kiedy go przekroczycie, odzywa się 429 — jednoznacznie, w Waszych logach, w sekundzie, w której zawiniliście. Optima takiego kontraktu nie podpisuje. Nic w systemie nie da Wam znać, że pętla odpytująca co pięć minut zjada właśnie najwięcej bazy, w której jedenaście osób próbuje wystawić faktury. Sygnał przyjdzie trzy dni później, innym kanałem i do kogoś innego: system zwolnił, odkąd weszła integracja.

Limity istnieją. Po prostu nie leżą tam, gdzie szuka ich odruch wyrobiony na API. Są cztery, a technicznym w tym sensie, jakiego spodziewa się programista, jest jeden. To awaryjna połowa przewodnika po API Optimy, który porządkuje, której z pięciu rzeczy nazywanych „API" właściwie używacie. Jeśli skrót CDN.API nie znaczy dla Was jeszcze nic konkretnego — zacznijcie od tamtego.

Sufit pierwszy: licencja i klucz, który dzwoni do domu

CDN.API loguje się jako operator i tu zaczyna się cały sufit handlowy. Wasza integracja jest użytkownikiem: zajmuje moduł na czas pracy i konkuruje o niego z ludźmi, dla których ten system kupiono.

Skutek jest sezonowy i dlatego przechodzi przez testy. W lutym zadanie i użytkownicy współżyją bez tarć. Dwudziestego, kiedy wszyscy zamykają miesiąc, automat albo nie dostaje licencji, albo zabiera tę, której ktoś właśnie potrzebuje. Integratorzy, którzy żyją z Optimy, zalecają wydzielenie licencji integracyjnych na osobny klucz, przypisany wyłącznie do niej. Powodem jest dokładnie ta kolizja.

Za licencją stoi drugi zegar, którego prawie nikt nie liczy. Klucz wirtualny musi zameldować się na serwerach Comarchu przynajmniej raz na 24 godziny dla modułów Optimy — dla XL i Altum co 72 godziny. Jeśli Menadżer Kluczy straci połączenie na dłużej, moduły przestają się pobierać, a stanowiska nie zalogują się do programu. Menadżer odpytuje mniej więcej co dwie godziny, więc powrót do normy też nie następuje od razu.

Czytajcie to jako zależność dostępnościową, bo nią jest. Uptime Waszej integracji obejmuje od tej chwili wychodzące łącze klienta i infrastrukturę licencyjną Comarchu. Wystarczy reguła na firewallu zmieniona w piątek po południu. A kiedy to się stanie, wszystko w logach mówi „błąd uwierzytelnienia" — więc każda godzina spędzona we własnym kodzie jest godziną straconą.

Sufit drugi: silnik bazy, którego nikt nie wybrał

Silnik bazy sprawdzam na nieznanej instalacji jako pierwszy. Sprawdzenie kosztuje kwadrans, a uderzenie w ten sufit kosztuje najwięcej z całej czwórki.

Comarch opisuje go na własnych stronach pomocy: edycje MS SQL Server Express od 2016 do 2022 ograniczają pojedynczą bazę do 10 GB, a starszy Express 2008 miał 4 GB. Express przycina też pamięć dostępną silnikowi — dlatego biuletyn strojeniowy każe ustawić Max Server Memory na około 1400 MB na Expressie, przy 13500 MB na pełnej edycji z 16 GB RAM.

Teraz to, co robi z przypisu ryzyko projektowe. Ogromna część instalacji Optimy stoi na Expressie, bo Express przyszedł z instalatorem. Nikt nie decydował o pojemności. Zadziałało ustawienie domyślne, wybrane lata temu przez kogoś, kto klikał setup, i nikt do niego nie wrócił, bo oprogramowanie nie przypomina o nim ani razu. Aż do dnia, w którym zapisy zaczynają się wywracać.

Wasza integracja to maszyna do produkowania rekordów wycelowana w tę bazę.

Policzcie więc datę sufitu, zanim wyślecie wycenę. Trzy liczby: rozmiar bazy dzisiaj, rozmiar sprzed dwunastu miesięcy (wystarczy rozmiar starego pliku kopii) i miesiąc, w którym prosta przecina 10 GB. Piętnaście minut roboty. U rosnącej hurtowni regularnie wychodzi od 5 do 14 miesięcy zapasu — czyli mniej, niż ma żyć to, co właśnie macie zbudować.

Jeśli ta data wypada w horyzoncie projektu, licencja SQL Server wchodzi do oferty jako pozycja, o której klient decyduje z otwartymi oczami. Pominiecie ją — wróci na wiosnę jako awaria. I wtedy to Wasza integracja „zapchała bazę".

Sufit trzeci: jeden host Windows, jeden model sesji

CDN.API to model obiektowy COM: działa na Windowsie, w procesie, obok zainstalowanej Optimy. Pracuje sesyjnie — zaloguj się, zrób swoje, wyloguj. Z tych dwóch faktów wynika wszystko, co dotyczy przepustowości.

Poziomo tego nie przeskalujecie, odpalając więcej kontenerów tam, gdzie taniej. Pojemnością jest ten jeden host Windows, a sufitem to, co jego procesor i pamięć udźwigną obok ERP. Integratorzy wspierający Optimę komercyjnie stawiają wymaganie wprost: serwer ma pracować bez przerwy, a wyłączanie go na noc powoduje opóźnienia i problemy z synchronizacją. Zwyczajne zdanie z realnym kosztem w środku — host jest infrastrukturą z celem dostępnościowym, nie komputerem w kącie pokoju.

Model sesyjny karze obie oczywiste implementacje. Logowanie per rekord pełznie, bo koszt otwarcia sesji płacicie tysiące razy. Jedna sesja trzymana przez sześciogodzinną paczkę jest krucha: aktualizacja ERP, mrugnięcie sieci albo restart zabija cały przebieg, a dowiadujecie się o tym rano. Przeżywają paczki z punktami kontrolnymi i wznawialną pracą. Zbudujcie to pierwszego dnia, nie po pierwszej złej nocy.

Sufit czwarty: dziury w samym API

CDN.API nie pokrywa wszystkiego, a dziury łata się SQL-em. To nie moja opinia — tak stoi w opublikowanej dokumentacji integracyjnej.

Operacje, których nie da się wykonać stabilnie ani wydajnie przez CDN.API, robi się bezpośrednimi zapytaniami SQL: konkretnie obsługę atrybutów oraz numer listu przewozowego, a jako wymagające bezpośredniego dostępu wymieniono [CDN].[DefAtrybuty], [CDN].[DokAtrybuty] i jedno pole w [CDN].[TraNag]. Atrybuty wypadły ze ścieżki API właśnie ze względów wydajnościowych.

Wynikają z tego dwie rzeczy. Po pierwsze, zasada „przez API, nigdy przez SQL" ma udokumentowane wyjątki w systemach produkcyjnych, które budowali ludzie robiący to na pełen etat. Udawanie, że jest inaczej, kończy się wyceną opartą na pokryciu, którego API nie ma. Sprawdźcie wcześnie, czy pola, których potrzebujecie, są osiągalne przez CDN.API w użytecznym czasie — pole zapisywalne technicznie, ale wolno, to ten sam problem co pole, którego nie ma.

Po drugie, wyjątek jest wąski i ma taki zostać. Odczyt do raportowania: proszę bardzo. Malutki, nazwany i spisany zbiór zapisów, bo innej drogi nie ma: czasem nieunikniony. Reszta przez API, żeby numeracja dokumentów i logika magazynu zostały robotą Optimy. Zwróćcie przy tym uwagę, co bezpośredni SQL po cichu wyrzuca za burtę: model uprawnień. Połączenie SQL nie wie, że prawa operatora w ogóle istnieją. Ta sama pułapka, którą opisywałem przy kontach serwisowych w enova365 — read-only na bazie jest uprawnieniem dużo szerszym niż read-only w ERP, a na jednym spotkaniu oba nazywa się tak samo.

Przy okazji sprawdźcie, jakiego dostępu integracja naprawdę potrzebuje. Publikowane wymagania mówią o rolach SQL CDN i CDNRaport — i na bazie firmowej, i na konfiguracyjnej. Dwie bazy. To zaskakuje tych, którzy zaplanowali jedną.

Liczby, które ostrzegą Was przed użytkownikami

Optima nie powie Wam, że naciskacie za mocno, więc liczby weźcie z warstwy, która powie. Progi podaje biuletyn strojeniowy Comarchu OPT057 i te akurat warto mieć na dashboardzie:

• Page Life Expectancy powyżej 300 sekund. Najlepsze wczesne ostrzeżenie w całym zestawie. Kiedy ciężkie zadanie przemiela bufor, ta wartość leci pierwsza — zanim ktokolwiek zauważy cokolwiek w interfejsie.
• Buffer Cache Hit Ratio powyżej 90% i Available Bytes powyżej 300 MB — presja pamięciowa.
• Processor Queue Length poniżej 2 na rdzeń, CPU poniżej 80%, Disk Time poniżej 55%.

Dwa ustawienia liczą się szczególnie wtedy, gdy Wasze zadanie chodzi po żywej bazie. Blokady wywołane zrównolegleniem zapytań stroi się przez Max Degree of Parallelism i Cost Threshold for Parallelism — jeśli odpowiadają za istotny procent tego, co widzicie, zejdźcie z MaxDoP albo podnieście próg kosztu. A sys.dm_db_missing_index_group_stats posortowany po avg_user_impact zwykle pokaże, że to Wasze własne zapytania raportowe proszą o indeksy, których nikt nigdy nie założył.

Zdejmijcie baseline przed startem produkcyjnym. Bez niego nie odpowiecie na jedyne pytanie, które padnie — czy integracja spowolniła Optimę. A przy braku odpowiedzi winny jest zawsze najnowszy element.

Budżet, którego nikt Wam nie ustalił

Prędkość ustalcie sami i na piśmie, bo platforma tego za Was nie zrobi. Na tym kończy się cała reguła projektowa.

Dajcie zadaniu okno i każcie mu szanować dzień pracy: pełna synchronizacja kończy się, kiedy ludzie zaczynają, obojętne, ile jej zostało. Dajcie wielkość paczki wziętą z pomiaru, nie z optymizmu, plus punkty kontrolne, żeby zatrzymany przebieg wznawiał się, zamiast startować od zera. Odetnijcie raportowanie od ścieżki transakcyjnej — to zapytania analityczne zamieniają ruchliwy poranek w powolny, a raportowanie tylko do odczytu to dokładnie ten przypadek, w którym replika ma sens. I każdy zapis zróbcie idempotentnym, bo wznawialne zadanie prędzej czy później któryś powtórzy.

Nic z tego nie jest rzemiosłem specyficznym dla Optimy. To zwyczajna dyscyplina inżynierska, konieczna tutaj właśnie dlatego, że platforma nie daje żadnej z barierek, które dałoby współczesne API.

Godzinna inwentaryzacja sufitów

Przed wyceną jakiejkolwiek integracji z Optimą zadajcie cztery pytania. Zajmują mniej więcej godzinę i przesuwają szacunki skuteczniej niż cokolwiek innego, co robię na tym etapie:

1. Która edycja SQL i jak duża jest baza? Express czy pełna, rozmiar dziś, rozmiar rok temu, data sufitu.
2. Który klucz, ile modułów i czy integracja ma własny klucz? Do tego: czy instalacja ma pewne łącze wychodzące na potrzeby meldunku co 24 godziny?
3. Która wersja Optimy i jaki jest rytm aktualizacji? Comarch wydaje kilka wersji rocznie, a komercyjne integracje wspierają zwykle tylko trzy ostatnie. Jeśli klient jest dwie wersje w tyle i aktualizuje się w marcu, to jest Wasz kalendarz, nie jego.
4. Co istniejąca integracja już dziś robi bezpośrednim SQL-em? Jeśli coś pisze dziś do tabel Optimy, dziedziczycie to niezależnie od tego, czy to Wy napisaliście.

Zróbcie to przed wyceną, nie w trzecim tygodniu. Wzorzec ten sam co przy opóźnieniu dostępowym: pytania, które przesuwają datę, są tanie, nudne i zadawane za późno.

Dokąd to prowadzi

Żaden z czterech sufitów nie jest powodem, żeby nie budować. Są powodem, żeby wiedzieć, o który uderzycie najpierw, i powiedzieć to, zanim ktokolwiek podpisze się pod datą. Dwa z nich — klucz licencyjny i edycja SQL — nie są nawet decyzjami technicznymi. To decyzje handlowe, podjęte lata temu przez kogoś, kto o integracji nie myślał, i obie da się załatwić zamówieniem, jeśli podniesiecie temat wystarczająco wcześnie.

Praca warta zrobienia na tej hydraulice jest ta sama co zawsze: coś, co czyta dokumenty z Optimy, sprawdza je ze źródłem spoza ERP i kładzie człowiekowi przed oczami gotowy szkic do zatwierdzenia, zamiast kazać mu przepisywać. Tak działa agent księgowy na Optimie. Każdy sufit powyżej ogranicza to, jak szybko wolno mu czytać — nie to, czy w ogóle zadziała.

Po czym poznać proces, który nadaje się do oddania maszynie, rozbierają agenci AI dla firm. Wariant z enova365 zamiast Optimy pod spodem opisuje integracja enova365 z AI.

Wyceniacie integrację z Optimą i chcecie zmierzyć sufity, zanim zobowiążecie się do daty? Napiszcie do mnie. Cztery pytania powyżej zajmują godzinę i ani razu nie przeszedłem przez nie tak, żeby przynajmniej jedna odpowiedź nie zmieniła planu.