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

  1. 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.
  2. 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.
  3. 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ē.
  4. 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.
  5. 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ā.
  6. 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?
Sistēmu integrācija ir process, kurā divas vai vairākas aplikācijas tiek savienotas tā, lai tās varētu apmainīties ar datiem, izraisīt notikumus viena otrā un uzturēt informācijas konsekvenci. Praksē: kad klients tiek pievienots CRM, viņš automātiski parādās ERP; kad grāmatvedībā izrakstīts rēķins, dati nonāk CRM un analītikā. Bez integrācijas uzņēmums manuāli žonglē ar datiem (CSV eksporti, kopēšana starp sistēmām), kas rada kļūdas, aizkaves un izmaksas.
Kādas integrāciju tehnoloģijas izmantojat?
Tehnoloģijas izvēle atkarīga no konteksta: REST API un webhooks moderniem mākoņa sistēmām, SOAP/XML vecākiem ERP/banku pakalpojumiem, ziņojumu rindas (RabbitMQ, Redis Streams, Kafka) asinhronai apmaiņai, ETL/ELT datu noliktavu apgādei, GraphQL, kad klients vēlas elastību. Bieži apvienojam pieejas — sinhroni tur, kur lietotājs gaida rezultātu, asinhroni tur, kur svarīga caurlaide.
Vai integrācijas saplīst pie avota sistēmu atjauninājumiem?
Tas ir viens no lielākajiem integrāciju izaicinājumiem — un tieši tāpēc veidojam adapterus ar izolāciju (anti-corruption layer). Ārējā sistēma maina līgumu → mainās tikai adapteris, pārējā integrācija paliek nemainīga. Papildus: līgumi tiek versionēti (v1, v2), integrācijas testi tiek palaisti katru dienu uz sandbox API, Sentry/Wazuh brīdinājumi atbildes formāta izmaiņās. Klients par problēmu uzzina, pirms tā nonāk pie lietotājiem.
Cik ilgi parasti ilgst integrācija?
Vienkāršas integrācijas (viena sistēma ar otru, ~5 galapunkti, viens sinhronizācijas virziens) realizējam 1-2 nedēļās. Sarežģītas (divvirzienu sinhronizācija, vairāki desmiti entītiju, kartējumi, transformācijas, deduplikācija) aizņem 4-8 nedēļas. Integrācijas ar vairākām sistēmām vienlaikus (hub-and-spoke) plānojam fāzēs, sniedzot biznesa vērtību 2-3 nedēļu iterācijās.
Kā ar vēsturiskajiem datiem pie jaunas integrācijas?
Katram integrācijas projektam ir atsevišķs vēsturiskās migrācijas posms. Vispirms pilna analīze: cik ierakstu, kādi datu tipi, kur ir dublikāti, kuri lauki ir obligāti un kuri pēc izvēles. Tad migrācijas skripts ar dry-run, audita pierakstu (kas pārcelts, kas atmests, kāpēc) un atcelšanas plānu. Migrācija tiek veikta servisa logā vai inkrementāli, atkarībā no biznesa riska.
Vai integrācijai jādarbojas 24/7?
Atkarīgs no biznesa kritiskuma. Tiešsaistes procesi (maksājumi, autorizācijas) prasa augstu pieejamību — projektējam tos ar redundanci (load balancer, vairākas instances, health checks, automātiska restartēšana). Nakts procesi (atskaites, sērijveida sinhronizācijas) var darboties servisa logos. Katru integrāciju klasificējam SLA: p95 atbildes laiks, pieļaujamais mēneša downtime, RTO/RPO.
Kā monitorējat ražošanas integrācijas?
Katra integrācija ziņo metriskus Prometheus (request rate, error rate, latency p50/p95/p99), žurnālus uz centrālo SIEM (Wazuh), kļūdas uz Sentry. Brīdinājumi pie caurlaides krituma, error rate pieauguma vai timeout. Dashboard parāda visu integrāciju stāvokli vienuviet — operators redz, ka piem., integrācijai ar piegādātāju X ir 3% kļūdu, kamēr pārējās darbojas raiti.
Kā ar drošību pie ārējām integrācijām?
Katra integrācija izmanto mazākās nepieciešamās atļaujas (least privilege). Atslēgas un tokens glabājam HashiCorp Vault (nevis .env failos, nevis kodā). Komunikācija vienmēr caur TLS 1.2+, sertifikāti tiek verificēti (nekad verify=False). Ienākošajiem webhooks ir HMAC paraksta verifikācija. Pēc tokenu noplūdes — tūlītēja rotācija, audita žurnāls parāda, kas un kad ir izdarīts.
Ar ko integrācija caur ESKOM AI atšķiras no klasiskā ESB (Enterprise Service Bus)?
Klasiskais ESB (Mule, BizTalk, WebMethods) ir monolīta platforma, dārga licencēs, prasa dedicētu komandu. Mūsu modelis: integrāciju mikropakalpojumi, katra integrācija kā atsevišķs komponents ar savu izvietošanu un monitoringu, infrastruktūra balstīta uz open source (FastAPI, RabbitMQ, Redis, PostgreSQL, Vault). Zemākas licenču izmaksas, vieglāka uzturēšana, bez vendor lock-in. Daļai klientu tas ir finanšu arguments, daļai — stratēģisks.
Vai integrējaties ar Polijas valsts sistēmām (KRS, CRBR, KSeF, ePUAP)?
Jā. Ražošanā ir mikropakalpojums, kas integrēts ar KRS un CRBR (rejestrfirm.eskom.ai — 740k+ uzņēmumu dati ar faktisko labuma guvēju datiem). KSeF (e-faktūrēšana) — mums ir gatavi integrācijas komponenti Kontroling projektā. ePUAP, e-piegādes — pieejamas caur Microsoft Graph API un tiešām integrācijām. Pilna atbilstība Polijas tiesību aktiem (GDPR, ziņošanas pienākumi).

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.