Pilier puslapis

Sistemų integracija įmonėms

Jungiame ERP, CRM, buhalterines, personalo-darbo užmokesčio sistemas, KRS, MS Graph, Salesforce, SAP. Integracijos per API, eiles, ETL, webhook'us — su pilna kokybės kontrole, audito pėdsaku ir produkciniu monitoringu.

Vidutinė įmonė naudoja nuo keliolikos iki keliasdešimt verslo aplikacijų. Kiekviena saugo tų pačių duomenų fragmentus — kliento, sąskaitų, darbuotojo, užsakymų. Be integracijos darbuotojai praleidžia valandas per dieną rankiniu būdu perrašinėdami, eksportuodami ir importuodami duomenis tarp sistemų.

Sistemų integracija nėra prabanga — tai skaitmeninės transformacijos pagrindas. Su gerai suprojektuota integracija: CRM pridėtas klientas atsiranda ERP be įsikišimo, buhalterijoje išrašyta sąskaita atnaujina vadovo finansinį pulpitą, užsakymo statusas yra suderintas internetinėje parduotuvėje, sandėlyje ir klientų aptarnavime.

Kodėl integracijos yra sudėtingos?

Kiekviena sistema turi savo duomenų modelį, savo pavadinimą tiems patiems laukams, savo operacijų seką, savo API apribojimus (limitai, vėlavimai, laikinos klaidos). Dvi sistemos teoriškai gali atrodyti „suderinamos", bet praktikoje reikalauja savaičių darbo prie mapping'ų, transformacijų, edge-case'ų tvarkymo ir konfliktų sprendimo.

Antras sudėtingumo sluoksnis — produkcinis patikimumas. Integracija, gerai veikianti dev aplinkoje, yra ~30% kelio. Likę 70% — išskirtinių situacijų tvarkymas: išorinė sistema neprieinama, pakeitė API kontraktą, grąžina netikėtus duomenis, į CRM įvestas naujas klientas su lietuviškais ženklais, kurių senas ERP nepalaiko. Kiekvienas toks atvejis reikalauja apgalvojimo, testo ir įspėjimo, kai jis įvyks.

Integracijų tipai

Šeši pagrindiniai šablonai. Daugumoje projektų jungiame kelis, parinkdami metodą konkrečiam atvejui.

REST API / GraphQL

Sinchroninis aplikacijų bendravimas. JSON kaip mainų formatas, OAuth2/JWT autorizacijai, OpenAPI/Swagger dokumentacijai. Dažniausias pasirinkimas šiuolaikinėms debesų sistemoms.

Žinučių eilės

RabbitMQ, Redis Streams, Kafka — asinchroniniai mainai, kai siuntėjas nelaukia gavėjo. Idealu pranešimams, verslo įvykiams, ilgai trunkančioms operacijoms. Pristatymo garantija + retry.

ETL / ELT

Paketinis duomenų krovimas į saugyklas (Snowflake, BigQuery, Redshift, vietinis PostgreSQL). Airflow arba dbt kaip orkestratorius, duomenų kokybės validavimas (Great Expectations), lineage monitoringas.

Webhooks

Push pranešimai iš šaltinio sistemos (Stripe, GitHub, Slack, Salesforce) į mūsų aplikaciją. HMAC parašo patikrinimas, idempotentiškumas, dead-letter queue nepavykusiems pristatymams.

SOAP / XML

Senesnės enterprise sistemos (SAP, Oracle, bankininkystė, draudimas) — pilnas WSDL palaikymas, XSD validavimas, WS-Security. Adapteris į šiuolaikinius protokolus likusiai sistemos daliai.

Duomenų bazės — replikacija, CDC

Change Data Capture (Debezium, AWS DMS) srautinei pakeitimų replikacijai iš šaltinio bazės į tikslinę. Logical replication PostgreSQL high-availability ir ataskaitoms.

Šeši pagrindiniai produkciniai iššūkiai

Dalykai, į kuriuos atkreipiame dėmesį kiekviename integracijos projekte. Vieno iš šių elementų trūkumas = laikrodinė bomba.

Idempotentiškumas

Kiekviena užklausa, atliekama daug kartų, duoda tą patį rezultatą. Idempotenciniai raktai antraštėse, deduplikacija aplikacijos lygmenyje, transakcijos aplink kritines operacijas.

Retry ir backoff

Laikinos tinklo klaidos yra norma. Exponential backoff (1s, 2s, 4s, 8s...), jitter išvengti thundering herd, circuit breaker po N nepavykusių bandymų.

Mapping ir transformacijos

Sistema A vadina lauką "client_id", sistema B "customerId", sistema C "id_klienta". Centrinis mapping'ų katalogas, transformacijos vienoje vietoje, kiekvienos transformacijos testai.

Eventual consistency

Duomenys dviejose sistemose niekada nėra 100% suderinti realiu laiku. Priimame vėlavimus (paprastai sekundes), stebime drift, įspėjame esant didesniems neatitikimams.

Auditas ir compliance

Kiekviena integracijos operacija fiksuoja: kas/ką/kada/iš kur/kur, payload (anonimizuotą jei yra PII), rezultatą. Audito žurnalas atitinka BDAR ir ISO 27001 reikalavimus.

Mastelio keitimas ir kaštai

Integracijos auga kartu su verslu. Horizontal scaling (daugiau instancijų), rate limiting (apsauga nuo perteklinių užklausų), monitoringas kaštams per integraciją.

Kaip vykdome integracijos projektą

  1. Discovery (1-2 savaitės): dabartinių duomenų srautų mapping'as, kiekvienos esybės tiesos šaltinių identifikavimas, API kontraktų rinkimas, rizikų ir priklausomybių vertinimas.
  2. Architektūros projektavimas (1 savaitė): šablonų pasirinkimas (sinchroniškai vs asinchroniškai, push vs pull, hub-and-spoke vs point-to-point), audito žurnalo schema, monitoringo planas.
  3. Bandomasis projektas vienai esybei (2-3 savaitės): įgyvendiname integraciją vienam duomenų tipui (pvz., klientams) end-to-end. Kontraktų validavimas, apkrovos testai, dry-run testavimo aplinkoje.
  4. Plėtimas į kitas esybes (4-8 savaitės): sekančios sinchronizacijos (sąskaitos, užsakymai, produktai) tuo pačiu šablonu. Kiekvienas diegimas prieš tai turi Change Request ir regresijos testus.
  5. Istorinė migracija (1-3 savaitės): esamų duomenų perkėlimas. Dry-run, auditas, rollback planas. Inkrementinė migracija arba aptarnavimo lange.
  6. Hypercare (4 savaitės po produkcijos): intensyvus monitoringas, greitas reagavimas į incidentus, įspėjimų derinimas. Po hypercare perėjimas į standartinę priežiūrą.

Įgyvendintų integracijų pavyzdžiai

KRS + CRBR — RejestrFirm

Mikropaslauga, jungianti duomenis iš Lenkijos Teismų Registro (740k+ įmonių) su Centriniu Tikrųjų Naudos Gavėjų Registru. Smart caching (24val), dual-source su automatic fallback, 15+ REST endpoint'ų. Naudojama KYC procesuose, kontrahentų patikrinimuose, compliance ataskaitų generavime.

SSO su daugeliu aplikacijų

Centrinė Keycloak platforma (realm eskom-ai) integruota su keliolika klientų aplikacijų. OAuth2/OIDC + PKCE, social login (Google, Microsoft, Apple, Facebook), vartotojų provisioning, atsiskaitymas pagal LLM token'ų sunaudojimą. Single sign-on visiems ESKOM AI produktams.

Microsoft Graph — kalendoriai, el. paštas, OneDrive

Integracija su Microsoft 365 kalendoriaus automatizavimui (susitikimų derinimas per DI asistentą), transakcinių el. laiškų siuntimui, dokumentų archyvavimui. OAuth2 su delegated permissions, refresh token'ai Vault, Graph API rate limit'ų monitoringas.

LLM Proxy — multi-provider maršrutizavimas

Centrinė eilė, jungianti kelis LLM tiekėjus (Anthropic, OpenAI, vietinis Ollama). Maršrutizavimas per užduotį (smulkios — vietinis modelis, sudėtingos — Claude Opus), atsakymų cache, kaštų monitoringas per projektą, fail-over tarp tiekėjų.

Dažniausiai užduodami klausimai

Ką reiškia sistemų integracija?
Sistemų integracija — procesas, kurio metu sujungiamos dvi ar daugiau aplikacijų taip, kad galėtų keistis duomenimis, paleisti įvykius viena kitoje ir išlaikyti informacijos vientisumą. Praktikoje: kai CRM pridedamas klientas, jis automatiškai atsiranda ERP; kai buhalterijoje išrašoma sąskaita, duomenys keliauja į CRM ir į analitiką. Be integracijos įmonė žongliruoja duomenimis rankiniu būdu (CSV eksportai, kopijavimas tarp sistemų), o tai generuoja klaidas, vėlavimus ir kaštus.
Kokias integracijos technologijas naudojate?
Technologijų pasirinkimas priklauso nuo konteksto: REST API ir webhook'ai šiuolaikinėms debesų sistemoms, SOAP/XML senesniems ERP/bankininkystei, žinučių eilės (RabbitMQ, Redis Streams, Kafka) asinchroniniams mainams, ETL/ELT duomenų saugyklų maitinimui, GraphQL kai klientas nori lankstumo. Dažnai mišriname požiūrius — sinchroniškai ten, kur vartotojas laukia rezultato, asinchroniškai ten, kur svarbi pralaidumas.
Ar integracijos lūžta atnaujinant šaltinio sistemas?
Tai viena didžiausių integracijų problemų — ir todėl statome adapterius su izoliacija (anti-corruption layer). Išorinė sistema keičia kontraktą → keičiasi tik adapteris, likusi integracija lieka be pakeitimų. Papildomai: kontraktai versionuojami (v1, v2), integraciniai testai paleidžiami kasdien sandbox API, įspėjimai Sentry/Wazuh esant atsakymo formato pokyčiams. Klientas sužino apie problemą prieš ją pasiekiant vartotojus.
Kiek trunka tipinė integracija?
Paprastas integracijas (viena sistema su kita, ~5 endpoint'ai, viena sinchronizacijos kryptis) įgyvendiname per 1-2 savaites. Sudėtingas (dvikryptė sinchronizacija, keliolika esybių, mapping'ai, transformacijos, deduplikacija) — 4-8 savaites. Integracijas su daugeliu sistemų vienu metu (hub-and-spoke) projektuojame fazomis, pristatydami verslo vertę 2-3 savaičių iteracijomis.
Kaip dėl istorinių duomenų esant naujai integracijai?
Kiekvienas integracijos projektas turi atskirą istorinės migracijos etapą. Pirmiausia pilna analizė: kiek įrašų, kokie duomenų tipai, kur yra dublikatai, kokie laukai yra privalomi, o kokie pasirinktiniai. Tada migracijos skriptas su dry-run, audito pėdsaku (kas perkelta, kas atmesta, kodėl) ir rollback planu. Migracija vykdoma aptarnavimo lange arba inkrementiškai, priklausomai nuo verslo rizikos.
Ar integracija turi veikti 24/7?
Priklauso nuo verslo kritiškumo. Online procesai (mokėjimai, autorizacijos) reikalauja aukšto prieinamumo — projektuojame juos su redundancija (load balancer, multiple instances, health checks, auto-restart). Nakties procesai (ataskaitos, paketinės sinchronizacijos) gali veikti aptarnavimo languose. Kiekvieną integraciją klasifikuojame SLA: p95 atsako laikas, priimtinas downtime per mėnesį, RTO/RPO.
Kaip stebite produkcines integracijas?
Kiekviena integracija pateikia metrikas į Prometheus (request rate, error rate, latency p50/p95/p99), žurnalus į centrinį SIEM (Wazuh), klaidas į Sentry. Įspėjimai pralaidumo kritimui, error rate augimui ar timeout'ams. Dashboard rodo visų integracijų būklę vienoje vietoje — operatorius mato, kad pvz. integracija su tiekėju X turi 3% klaidų, kai likusios veikia sklandžiai.
Kaip dėl saugumo esant išorinėms integracijoms?
Kiekviena integracija naudoja mažiausius būtinus leidimus (least privilege). Raktus ir token'us saugome HashiCorp Vault (ne .env failuose, ne kode). Komunikacija visada per TLS 1.2+, sertifikatai patikrinami (niekada verify=False). Įeinantys webhook'ai turi HMAC parašo patikrinimą. Token'ui nutekėjus — momentinė rotacija, audito žurnalas rodo kas ir kada buvo padaryta.
Kuo integracija per ESKOM AI skiriasi nuo klasikinio ESB (Enterprise Service Bus)?
Klasikinis ESB (Mule, BizTalk, WebMethods) — monolitinė platforma, brangi licencijomis, reikalaujanti dedikuotos komandos. Mūsų modelis: integracijos mikropaslaugos, kiekviena integracija kaip atskiras komponentas su savo diegimu ir monitoringu, infrastruktūra paremta open source (FastAPI, RabbitMQ, Redis, PostgreSQL, Vault). Mažesni licencijų kaštai, lengvesnė priežiūra, jokio vendor lock-in. Daliai klientų tai finansinis argumentas, daliai — strateginis.
Ar integruojatės su Lenkijos viešomis sistemomis (KRS, CRBR, KSeF, ePUAP)?
Taip. Produkcijoje turime mikropaslaugą, kuri integruojasi su KRS ir CRBR (rejestrfirm.eskom.ai — 740k+ įmonių duomenys su beneficial owners). KSeF (e-sąskaitos) — turime paruoštus integracijos komponentus Kontroling projekte. ePUAP, e-pristatymai — pasiekiami per Microsoft Graph API ir tiesiogines integracijas. Pilnas atitikimas Lenkijos teisei (BDAR, ataskaitiniai įsipareigojimai).

Turite integracijos projektą?

Pradedame nuo nemokamo audito — sumapuosime esamus duomenų srautus, identifikuosime butelio kakliukus ir pasiūlysime planą aiškiais etapais.