Pillar lapa
Sistēmu integrācija uzņēmumiem
Savienojam ERP, CRM, grāmatvedības, personāla un algu sistēmas, KRS, MS Graph, Salesforce, SAP. Integrācijas caur API, rindām, ETL, webhook — ar pilnu kvalitātes kontroli, audita pierakstu un ražošanas monitoringu.
Vidējs uzņēmums izmanto desmitiem līdz vairākiem desmitiem biznesa lietojumprogrammu. Katra glabā fragmentus no tiem pašiem datiem — klients, rēķini, darbinieki, pasūtījumi. Bez integrācijas darbinieki dienā pavada stundas, manuāli pārrakstot, eksportējot un importējot datus starp sistēmām.
Sistēmu integrācija nav greznība — tas ir digitālās transformācijas pamats. Ar labi izstrādātu integrāciju: klients, kas pievienots CRM, parādās ERP bez iejaukšanās; grāmatvedībā izrakstīts rēķins atjaunina prezidenta finanšu paneli; pasūtījuma statuss ir konsekvents tiešsaistes veikalā, noliktavā un klientu apkalpošanā.
Kāpēc integrācijas ir grūtas?
Katrai sistēmai ir savs datu modelis, savs nosaukums tiem pašiem laukiem, sava darbību secība, savi API ierobežojumi (limiti, aizkaves, pārejas kļūdas). Divas sistēmas teorētiski var šķist „saderīgas", bet praksē tās prasa nedēļu darbu pie kartējumiem, transformācijām, edge-case apstrādes un konfliktu risināšanas.
Otrs grūtību slānis ir ražošanas uzticamība. Integrācija, kas pareizi darbojas dev vidē, ir ~30% no ceļa. Pārējie 70% ir izņēmuma situāciju apstrāde: ārējā sistēma nav pieejama, mainījusi API līgumu, atgriež neparedzētus datus, ievietots jauns klients CRM ar poļu rakstzīmēm, ko vecā ERP neatbalsta. Katrs šāds gadījums prasa pārdomas, testu un brīdinājumu, kad tas notiek.
Integrāciju veidi
Seši pamata šabloni. Vairumā projektu mēs apvienojam vairākus, izvēloties metodi konkrētajam gadījumam.
REST API / GraphQL
Sinhrona komunikācija starp aplikācijām. JSON kā apmaiņas formāts, OAuth2/JWT autorizācijai, OpenAPI/Swagger dokumentācijai. Visbiežākā izvēle moderniem mākoņa sistēmām.
Ziņojumu rindas
RabbitMQ, Redis Streams, Kafka — asinhrona apmaiņa, kad sūtītājs negaida saņēmēju. Ideāli paziņojumiem, biznesa notikumiem, ilgstošām operācijām. Piegādes garantija + retry.
ETL / ELT
Sērijveida datu ielāde noliktavā (Snowflake, BigQuery, Redshift, lokāls PostgreSQL). Airflow vai dbt kā orchestrator, datu kvalitātes validācija (Great Expectations), izsekojamības monitorings.
Webhooks
Push paziņojumi no avota sistēmas (Stripe, GitHub, Slack, Salesforce) uz mūsu aplikāciju. HMAC paraksta verifikācija, idempotenci, dead-letter queue neveiksmīgām piegādēm.
SOAP / XML
Vecākas enterprise sistēmas (SAP, Oracle, banku pakalpojumi, apdrošināšana) — pilna WSDL, XSD validācijas, WS-Security atbalsts. Adapteris uz moderniem protokoliem pārējai sistēmai.
Datu bāzes — replikācija, CDC
Change Data Capture (Debezium, AWS DMS) izmaiņu plūsmas replikācijai no avota bāzes uz mērķa. PostgreSQL loģiskā replikācija augstai pieejamībai un atskaitēm.
Sešas galvenās ražošanas izaicinājumi
Lietas, uz kurām pievēršam uzmanību katrā integrācijas projektā. Trūkst kāds no šiem elementiem = laika bumba.
Idempotenci
Katrs pieprasījums, kas izpildīts vairākkārt, dod to pašu rezultātu. Idempotentas atslēgas galvenēs, deduplikācija aplikācijas līmenī, transakcijas ap kritiskām operācijām.
Retry un backoff
Pagaidu tīkla kļūdas ir norma. Exponential backoff (1s, 2s, 4s, 8s...), jitter, lai izvairītos no thundering herd, circuit breaker pēc N neveiksmīgiem mēģinājumiem.
Kartēšana un transformācijas
Sistēma A sauc lauku "client_id", sistēma B — "customerId", sistēma C — "id_klienta". Centrāls kartējumu katalogs, transformācijas vienuviet, katras transformācijas testi.
Eventual consistency
Dati divās sistēmās nekad nav 100% konsekventi reālajā laikā. Pieņemam aizkaves (parasti sekundes), uzraugām novirzi, brīdinām pie ilgākām neatbilstībām.
Audits un atbilstība
Katra integrācijas operācija pieraksta: kas/ko/kad/no kurienes/uz kurieni, payload (anonimizēts, ja satur PII), rezultāts. Audita žurnāls atbilst GDPR un ISO 27001 prasībām.
Mērogošana un izmaksas
Integrācijas pieaug līdz ar biznesu. Horizontāla mērogošana (vairāk instanču), rate limiting (aizsardzība pret pārmērīgiem pieprasījumiem), izmaksu monitorings pēc integrācijas.
Kā mēs realizējam integrācijas projektu
- Discovery (1-2 nedēļas): pašreizējo datu plūsmu kartēšana, patiesības avotu identificēšana katrai entītijai, API līgumu apkopošana, risku un atkarību novērtējums.
- Arhitektūras dizains (1 nedēļa): šablonu izvēle (sinhroni vs asinhroni, push vs pull, hub-and-spoke vs point-to-point), audita žurnāla shēma, monitoringa plāns.
- Pilotprojekts vienai entītijai (2-3 nedēļas): realizējam integrāciju vienam datu tipam (piem., klientiem) end-to-end. Līgumu validācija, slodzes testi, dry-run testa vidē.
- Paplašināšana uz pārējām entītijām (4-8 nedēļas): nākamās sinhronizācijas (rēķini, pasūtījumi, produkti) ar to pašu šablonu. Katras izvietošanas priekšā Change Request un regresijas testi.
- Vēsturiskā migrācija (1-3 nedēļas): esošo datu pārcelšana. Dry-run, audits, atcelšanas plāns. Inkrementāla migrācija vai servisa logā.
- Hypercare (4 nedēļas pēc ražošanas): intensīvs monitorings, ātra reakcija uz incidentiem, brīdinājumu pielāgošana. Pēc hypercare pāreja uz standarta uzturēšanu.
Realizēto integrāciju piemēri
KRS + CRBR — RejestrFirm
Mikropakalpojums, kas savieno datus no Polijas valsts tiesu reģistra (KRS, 740k+ uzņēmumi) ar Centrālo faktisko labuma guvēju reģistru (CRBR). Smart caching (24h), divkārša avota saskarne ar automātisku fallback, 15+ REST galapunkti. Tiek izmantots KYC procesos, darījumu partneru verifikācijā, atbilstības atskaišu ģenerēšanā.
SSO ar daudzām aplikācijām
Centrāla Keycloak platforma (realm eskom-ai), integrēta ar vairākām desmitiem klientu aplikāciju. OAuth2/OIDC + PKCE, social login (Google, Microsoft, Apple, Facebook), lietotāju provisioning, norēķini balstīti uz LLM token patēriņu. Single sign-on visiem ESKOM AI produktiem.
Microsoft Graph — kalendāri, e-pasts, OneDrive
Integrācija ar Microsoft 365 kalendāra automatizēšanai (sapulču pierakstīšana caur MI asistentu), transakciju e-pasta sūtīšanai, dokumentu arhivēšanai. OAuth2 ar delegated permissions, refresh tokens Vault glabātuvē, Graph API rate limit monitorings.
LLM Proxy — multi-provider maršrutēšana
Centrāla rinda, kas savieno vairākus LLM piegādātājus (Anthropic, OpenAI, lokāls Ollama). Maršrutēšana pēc uzdevuma (mazi — lokāls modelis, sarežģīti — Claude Opus), atbilžu kešs, izmaksu monitorings pa projektiem, fail-over starp piegādātājiem.
Biežāk uzdotie jautājumi
Ko nozīmē sistēmu integrācija?
Kādas integrāciju tehnoloģijas izmantojat?
Vai integrācijas saplīst pie avota sistēmu atjauninājumiem?
Cik ilgi parasti ilgst integrācija?
Kā ar vēsturiskajiem datiem pie jaunas integrācijas?
Vai integrācijai jādarbojas 24/7?
Kā monitorējat ražošanas integrācijas?
Kā ar drošību pie ārējām integrācijām?
Ar ko integrācija caur ESKOM AI atšķiras no klasiskā ESB (Enterprise Service Bus)?
Vai integrējaties ar Polijas valsts sistēmām (KRS, CRBR, KSeF, ePUAP)?
Vai jums ir integrācijas projekts?
Sākam ar bezmaksas auditu — kartējam pašreizējās datu plūsmas, identificējam šauros punktus un piedāvājam skaidru pakāpenisku plānu.