Pāriet uz galveno saturu
FromNine
Izvēlne

Inženierija

Integrācijas, kas uztur datu plūsmu un parāda, kad tā apstājas.

Mēs savienojam CRM, ERP, lietu sistēmas un valsts platformas ar pareizi veidotiem līgumiem, notikumiem un identitāti, lai dati plūstu uzticami, kļūdas būtu redzamas un jaunas iespējas, arī MI, varētu droši pieslēgties.

Organizācijām, kas savieno sistēmas, partnerus un valsts platformas Latvijā un citās ES valstīs.

Pieteikt sarunuApskatīt platformas
Integrācijas un API: spēju slāņiČetri slāņi viens aiz otra. No augšas uz leju: lietotāji, piemēram, portāli, lietotnes un aģenti, API vārteja ar identitāti, notikumu mugurkauls un apakšā uzskaites sistēmas.01Portāli, lietotnes un aģenti02API vārteja un identitāte03Notikumu mugurkauls04Uzskaites sistēmas
  1. 01API, kas sākas ar līgumu: OpenAPI un AsyncAPI, ar versijām un dokumentāciju
  2. 02Notikumi ar secību, idempotenci, neapstrādājamo ziņu rindu un atkārtošanu
  3. 03Plūsmas uzraudzītas no sākuma līdz galam, kļūdu rindām ir konkrētas komandas

01 Problēmas

Integrācijas problēmas, kuru dēļ mūs aicina

  1. 01

    Tiešie savienojumi, ko neviens neuzdrošinās mainīt

    Desmitiem tiešu savienojumu starp CRM, ERP un pasūtījuma sistēmām. Viena lauka maiņa nozīmē desmit saskarņu testēšanu.

  2. 02

    Dublikāti un klusas kļūmes

    Atkārtots mēģinājums izveido otru pasūtījumu. Neizdevusies ziņa pazūd. Uzņēmuma darbinieki par to uzzina no klientiem.

  3. 03

    Katrs jauns kanāls nozīmē jaunu integrācijas darbu

    Portālam, mobilajai lietotnei un tagad arī MI asistentam vajadzīgi tie paši dati, un katrs saņem savu datu izguvi.

  4. 04

    Valsts sistēmas un e-rēķini ir atsevišķs projekts

    Pieslēgšanās eParaksts, valsts koplietošanas pakalpojumiem vai e-rēķinu kanāliem katru reizi prasa drošības un pieslēgšanas darbu, kas var ilgt mēnešus.

02 Ko piegādājam

Ko mēs piegādājam

  1. 01 API stratēģija un pārvaldība

    API pirmais projektējums ar OpenAPI un AsyncAPI līgumiem, versiju politika, vārteja, kas to piemēro, un izstrādātāju portāls, lai komandas atrastu un atkārtoti izmantotu esošo.

    Ko mēs darām

    • API ainava un īpašnieku karte
    • Projektēšanas vadlīnijas un pārskatīšanas process
    • Vārtejas politikas drošībai, kvotām un versijām
    • Izstrādātāju portāls un API katalogs

    Ko Jūs saņemat

    • API vadlīnijas, ko pieņēmušas Jūsu komandas
    • Vārtejas konfigurācija kā kods
    • Dokumentētu API katalogs

  2. 02 Uz notikumiem balstīta integrācija

    Ziņu brokeri, izmaiņu datu uztveršana un outbox šablons, ar detaļām, kas nosaka, vai tas darbojas: secība, idempotenti patērētāji, neapstrādājamo ziņu rinda un atkārtošana.

    Ko mēs darām

    • Notikumu modelis un nosaukumu konvencijas
    • Outbox un CDC avota sistēmās
    • Patērētāju idempotence un secības garantijas
    • Neapstrādājamo ziņu rindas ar atkārtošanas rīkiem

    Ko Jūs saņemat

    • Notikumu mugurkauls ekspluatācijā
    • Shēmu reģistrs un saderības noteikumi
    • Atkārtošanas un atjaunošanas rokasgrāmata

  3. 03 Integrācijas platformas, izvēlētas katrai plūsmai

    SAP Integration Suite, MuleSoft un mākoņa integrācijas pakalpojumiem katram ir sava vieta. Mēs pasakām, kad iPaaS ir labāks par pasūtījuma kodu un kad nav.

    Ko mēs darām

    • Esošās starpprogrammatūras novērtējums
    • Platformas izvēle ar kopējām īpašumtiesību izmaksām
    • Atkārtoti izmantojami kartējumi un savienotāji
    • Pāreja no mantotās starpprogrammatūras

    Ko Jūs saņemat

    • Integrācijas platformas lēmuma pieraksts
    • Integrācijas šablonu bibliotēka
    • Pārejas plāns esošajām saskarnēm

  4. 04 Identitāte un uzticēšanās starp sistēmām

    OAuth 2.0 un OpenID Connect, savstarpējs TLS, pakalpojumu identitāte un integrācija ar iedzīvotāju un uzņēmumu eID: Latvijā eParaksts un eID karte, kā arī citu ES valstu nacionālās eID shēmas.

    Ko mēs darām

    • Identitātes arhitektūra lietotājiem un pakalpojumiem
    • Marķieru projektējums, tiesību apjomi un piekrišana
    • Atbalsts eID pieslēgšanai un sertifikācijai
    • Sagatavošanās Eiropas digitālās identitātes makiem

    Ko Jūs saņemat

    • Identitātes projektējums un draudu modelis
    • eID integrācija ekspluatācijā
    • Pakalpojumu identitāte un noslēpumu rotācija darbībā

  5. 05 Sadarbspēja ar valsts sistēmām un e-rēķini

    Savienojumi ar valsts koplietošanas pakalpojumiem, piemēram, e-adresi, ko nodrošina Valsts digitālās attīstības aģentūra (VDAA), strukturēti e-rēķini valsts un pašvaldību iestādēm atbilstoši EN 16931 un Peppol BIS Billing 3.0, citu ES valstu datu apmaiņas platformas un ES tehniskā sistēma pēc principa „tikai vienreiz”.

    Ko mēs darām

    • Pieslēgšanās kopā ar platformas uzturētāju
    • Kartēšana uz nacionālajiem datu standartiem un e-rēķinu formātiem
    • Katras datu apmaiņas drošības un žurnālēšanas prasības
    • Pierādījumu apmaiņas projektējums pēc principa „tikai vienreiz”

    Ko Jūs saņemat

    • Apstiprināts savienojums ar datu apmaiņu
    • Kartēšanas dokumentācija
    • Darbības procedūras kopā ar uzturētāju

  6. 06 Darbības pārskatāmība uzņēmuma lietotājiem

    Plūsmu uzraudzība, ko var izlasīt uzņēmuma darbinieki, saskaņošana starp sistēmām un kļūdu rindas, kurām ir īpašnieks, kas tās izskata.

    Ko mēs darām

    • Plūsmu uzraudzība biznesa līmenī
    • Saskaņošanas pārskati starp sistēmām
    • Kļūdu klasifikācija un nosūtīšana
    • Brīdinājumi katram plūsmas īpašniekam

    Ko Jūs saņemat

    • Integrācijas panelis katram biznesa procesam
    • Saskaņošanas pārbaudes ekspluatācijā
    • Īpašnieku karte katrai kļūdu rindai

03 Arhitektūra

Ilustratīva atsauces arhitektūra

No uzskaites sistēmām iziet divi ceļi. Sinhronie pieprasījumi iet caur sistēmu API un vārteju, kas pārbauda identitāti, tiesību apjomu un kvotas. Izmaiņas tiek publicētas kā notikumi caur outbox vai izmaiņu datu uztveršanu, un patērētāji tās apstrādā idempotenti.

Neizdevušās ziņas nonāk neapstrādājamo ziņu rindā ar atkārtošanu, nevis žurnāla failā. Uzraudzības josla rāda katru plūsmu biznesa terminos, lai procesa īpašnieki redzētu, kad tā apstājas.

Slāņi zīmējumā

Uzskaites sistēmas
ERP, CRM un lietu pārvaldības sistēmas saglabā noteicošo lomu pār saviem datiem.
Sinhronie API
Sistēmu API ar versijām aiz vārtejas ar OAuth 2.0, mTLS un kvotām.
Notikumi
Outbox, brokeris, neapstrādājamo ziņu rinda un integrācijas platformas kartējumi.
Patērētāji
Portāli, lietotnes, aģenti, partneri un valsts datu apmaiņa, ar eID, kur iesaistīti iedzīvotāji.
Ilustratīvs piemērs

  1. Uzskaites sistēmas

    • ERP, CRM un lietu sistēmas

  2. Sinhronie API

    • Sistēmu API
    • API vārteja: OAuth 2.0, mTLS, kvotas

  3. Notikumi

    • Outbox un CDC
    • Notikumu brokeris
    • Neapstrādātās ziņas un atkārtošana
    • Integrācijas platformas kartējumi

  4. Patērētāji

    • Portāli, lietotnes un aģenti
    • Partneru un valsts datu apmaiņa
    • Identitāte: OIDC, mTLS, eID

  5. Darbība

    • Plūsmu uzraudzība, saskaņošana, kļūdu rindas ar īpašniekiem
API un notikumu mugurkauls līdzās

Ilustratīva arhitektūra, nevis klienta sistēma.

Lasīt diagrammu kā tekstu

Galvenais ceļš ved no uzskaites sistēmām caur sistēmu API ar versijām un API vārteju līdz portāliem, lietotnēm un aģentiem.

Paralēli uzskaites sistēmas publicē izmaiņas caur outbox un izmaiņu datu uztveršanu notikumu brokerim, kas tās nogādā partneru un valsts datu apmaiņām un integrācijas platformai kartēšanai. Neizdevušās ziņas nonāk neapstrādājamo ziņu rindā ar atkārtošanu. Identitātes pakalpojumi ar OAuth, mTLS un eID aizsargā partneru datu apmaiņu.

Uzraudzības josla apakšā rāda plūsmu statusu, saskaņošanu un kļūdu rindas ar īpašniekiem.

04 Apsvērumi un ierobežojumi

Inženierijas apsvērumi un ierobežojumi

  • Tieši vienreiz ir projektējums, nevis iestatījums

    Kā mēs to risinām

    Pieņemam, ka ziņas pienāks divreiz vai nepareizā secībā, un projektējam idempotentus patērētājus ar atslēgām un secības noteikumiem, kas saskaņoti katram notikuma veidam.

    Ierobežojumi un atkarības

    Dažas mantotās sistēmas nevar pieņemt idempotences atslēgas vai ziņot, ko tās apstrādājušas. Ap tām pievienojam saskaņošanu, nevis izliekamies.

  • iPaaS ne vienmēr ir atbilde

    Kā mēs to risinām

    Platformas uzvar daudzu standarta savienotāju un kartējumu gadījumā. Pasūtījuma pakalpojumi uzvar sarežģītai loģikai, lieliem apjomiem vai stingrām aizkaves prasībām. Izvēli dokumentējam katrai integrācijai.

    Ierobežojumi un atkarības

    Licenču modeļi mainās. Platforma, kas šodien ir lēta, var kļūt par lielāko pozīciju Jūsu integrācijas budžetā, tāpēc izmaksas modelējam vairākiem gadiem.

  • Valsts sistēmas nosaka savu tempu

    Kā mēs to risinām

    Pieslēgšanas dokumentus, drošības pierādījumus un testu plānus sagatavojam agri un sadarbojamies ar platformas uzturētāju jau no pirmās nedēļas.

    Ierobežojumi un atkarības

    Sertifikācijas un pieslēgšanas termiņus nosaka uzturētājs, nevis mēs. Plānojam tos un pasakām, kur tie atrodas kritiskajā ceļā.

  • MI patērētājiem vajadzīgi šauri API

    Kā mēs to risinām

    Aģenti un asistenti saņem atsevišķus, ierobežotus API ar limitiem un audita žurnālēšanu, nevis tik plašu piekļuvi kā iekšējie pakalpojumi.

    Ierobežojumi un atkarības

    API atvēršana aģentam palielina risku. Katru no tiem pirms ekspluatācijas pārskatām kopā ar Jūsu drošības komandu.

05 Kā strādājam

Kā mēs strādājam

Vispirms atšķetinām, tad veidojam, un katrai plūsmai atstājam īpašnieku.

  1. 01

    Kartēt plūsmas

    Katra saskarne, tās apjoms, kļūmju vēsture un īpašnieks uzņēmumā.

    RezultātsIntegrāciju ainava un risku secība

  2. 02

    Noteikt noteikumus

    API vadlīnijas, notikumu konvencijas, identitātes modelis un platformas izvēle.

    RezultātsIntegrācijas vadlīnijas un lēmumu pieraksti

  3. 03

    Pārcelt pa plūsmai

    Vispirms riskantākās plūsmas, ar saskaņošanu līdzās vecajai saskarnei, līdz skaitļi sakrīt.

    RezultātsPārceltas plūsmas ar saskaņošanas pierādījumiem

  4. 04

    Darbināt pārskatāmi

    Paneļi katram biznesa procesam un kļūdu rindas ar konkrētiem īpašniekiem.

    RezultātsPlūsmu īpašnieku karte un paneļi

06 Cilvēka kontrole

Kur kontrole paliek cilvēkiem

Integrācijas darbojas bez uzraudzības. Atbildību par kļūmēm gan nevar atstāt bez cilvēka.

  • Katrai kļūdu rindai ir īpašnieks

    Neizdevušās ziņas nonāk pie komandas, kas par tām atbild, ar kontekstu un atkārtošanas pogu, nevis kopīgā žurnālā.

  • Līgumu izmaiņas tiek pārskatītas

    Nesaderīgas API vai notikumu izmaiņas pirms publicēšanas pārskata kopā ar patērētājiem.

  • Atkārtošana ir apzināta

    Ziņu atkārtota ievade uzskaites sistēmā ir pilnvarota darbība, ko žurnālē kopā ar to, kas to veica un kāpēc.

07 Tehnoloģijas

Tehnoloģijas, ar kurām strādājam

Integrācijas platformas
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • AWS un Google Cloud integrācijas pakalpojumi
Notikumi un straumēšana
  • Apache Kafka
  • RabbitMQ
  • Mākoņa notikumu brokeri
  • Debezium izmaiņu datu uztveršanai
API
  • OpenAPI un AsyncAPI
  • API vārtejas un izstrādātāju portāli
  • GraphQL, kur tas der
  • Līgumu testēšana
Identitāte
  • OAuth 2.0 un OpenID Connect
  • Savstarpējs TLS
  • Keycloak un mākoņa identitātes nodrošinātāji
  • Nacionālās eID shēmas

Tehnoloģijas nosaukums šajā sarakstā apraksta mūsu inženierijas pieredzi. Tas nenozīmē partnerību ar tās piegādātāju vai tā atbalstu.

08 Piemērs

Ilustratīvs piemērs

Ilustratīvs piemērs

Strukturēti e-rēķini no ERP iestādēm un gatavība 2028. gadam

01Situācija
Būvmateriālu vairumtirgotājs izraksta rēķinus gan uzņēmumiem, gan valsts un pašvaldību iestādēm. Rēķinus iestādēm grāmatvedība sagatavo atsevišķi un daļu pārbauda ar roku, to dati jānodod arī VID, un no 2028. gada 1. janvāra strukturēti e-rēķini būs obligāti arī starp uzņēmumiem.
02Ko mēs izveidotu
Integrācijas slānis, kas no ERP rēķiniem veido e-rēķinus atbilstoši EN 16931 un Peppol BIS Billing 3.0, validē tos pirms nosūtīšanas, nosūta pa katras iestādes noteikto kanālu, piemēram, tiešās pārvaldes iestādēm uz e-adresi, un pārrauga piegādes statusu.
03Kur lemj cilvēki
Grāmatvedība izskata rēķinus, kas neiztur validāciju, un apstiprina katru izmaiņu noteikumos, pēc kuriem rēķinus veido; ERP īpašnieks apstiprina kartējumu.
04Ko mēs mērītu
Bez labojumiem pieņemto rēķinu daļa, laiks no rēķina izrakstīšanas līdz piegādes apstiprinājumam un ar roku apstrādāto rēķinu skaits.

09 Nozares skatījums

Jūsu nozarē

  • Publiskais sektors un valsts pārvalde

    Datu apmaiņa ar autentiskiem avotiem pēc principa „tikai vienreiz”, eParaksts un eID iedzīvotājiem un uzņēmumiem un žurnālēšana, ko prasa valsts platformas. Skatiet mūsu darbu publiskajā sektorā.

  • Ražošana un rūpniecība

    ERP, MES un piegādātāju portāli, savienoti ar notikumiem, lai plānošanai, ražošanai un servisam būtu viens kopskats.

  • Finanšu pakalpojumi

    Pamatsistēmas, CRM un partneru API, savienoti ar stingru identitāti, audita žurnālēšanu un saskaņošanu, kurai uzticas finanšu daļa.

Latvija

Sadarbspēja Latvijā un pāri robežām

Latvijā integrāciju darbam ir skaidrs termiņš. Strukturēti e-rēķini valsts un pašvaldību iestādēm ir obligāti kopš 2025. gada 1. janvāra, brīvprātīga B2B e-rēķinu iesniegšana VID iespējama kopš 2026. gada 1. janvāra, un no 2028. gada 1. janvāra strukturēti e-rēķini ar ziņošanu VID būs obligāti arī starp uzņēmumiem. Valsts iestāžu pakalpojumos centrālā loma ir platformai eParaksts, e-adresei un VDAA koplietošanas pakalpojumiem.

Pārrobežu pakalpojumi katrā valstī sastop citu datu apmaiņu, eID shēmu un datu standartu. Sadarbspējīgas Eiropas akts prasa publiskā sektora iestādēm novērtēt pārrobežu sadarbspēju, un eIDAS 2 ievieš Eiropas digitālās identitātes makus, kas jānodrošina katrai dalībvalstij.

Mēs projektējam integrācijas slāņus, kuros nacionālās datu apmaiņas, e-rēķinu kanāli un identitātes shēmas ir adapteri aiz stabiliem iekšējiem līgumiem. Jaunas valsts pievienošana tad nozīmē jauna adaptera un tā pieslēgšanas pievienošanu, nevis sistēmu pārstrādi.

Jautājumi par integrācijām un API

Izmantot integrācijas platformu vai veidot integrācijas pēc pasūtījuma?

Abus, dažādām plūsmām. Standarta savienotājiem, kartējumiem un partneru pieslēgšanai labāk der platforma. Liela apjoma plūsmām, plūsmām ar stingrām aizkaves prasībām vai sarežģītu loģiku bieži labāk der pasūtījuma pakalpojumi. Lemjam katrai plūsmai un dokumentējam, kāpēc.

Vai integrējat Salesforce, SAP un Odoo?

Jā, regulāri, gan savā starpā, gan ar pasūtījuma un valsts sistēmām. Uzņēmumam FromNine ir partnera statuss visās trijās platformās (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), tāpēc mūsu integrācijas komandas strādā kopā ar platformu speciālistiem. Skatiet mūsu darbu ar SAP integrācijām.

Kas jāņem vērā e-rēķiniem Latvijā?

Valsts un pašvaldību iestādēm rēķini kopš 2025. gada 1. janvāra jāiesniedz kā strukturēti e-rēķini atbilstoši EN 16931 un Peppol BIS Billing 3.0 (darījumiem, kas noslēgti līdz 2024. gada 31. decembrim, ne vēlāk kā no 2026. gada 1. janvāra), un kopš 2026. gada 1. janvāra to dati jānodod arī Valsts ieņēmumu dienestam (VID). Tiešās pārvaldes iestādes e-rēķinus saņem e-adresē, bet ārvalstīs reģistrēti piegādātāji e-rēķinus tām iesniedz, izmantojot Peppol. Kopš 2026. gada 1. janvāra uzņēmumi B2B e-rēķinus VID var iesniegt brīvprātīgi, bet no 2028. gada 1. janvāra strukturēti e-rēķini ar ziņošanu VID būs obligāti arī starp uzņēmumiem. Mēs savienojam Jūsu ERP ar izvēlēto kanālu, validējam rēķinus pirms nosūtīšanas un padarām redzamu katra rēķina statusu.

Vai varat integrēt eParaksts un citas eID shēmas?

Jā. Integrējam eParaksts un eID karti, kā arī citu valstu iedzīvotāju un uzņēmumu eID shēmas, un projektējam risinājumus Eiropas digitālās identitātes makiem, kas dalībvalstīm saskaņā ar eIDAS 2 jānodrošina līdz 2026. gada 24. decembrim. Pieslēgšanās prasības katrai shēmai atšķiras, un mēs tās plānojam agri.

Mums ir mantota starpprogrammatūra. Vai tā jāaizstāj?

Ne visa uzreiz. Kartējam, kas tajā darbojas, vispirms pārceļam riskantākās vai dārgākās plūsmas un saglabājam saskaņošanu, līdz katra pārceltā plūsma ir pierādījusi sevi.

Atnesiet saskarni, kas visbiežāk sabojājas

Mēs parādīsim, kā to padarītu pārraugāmu, idempotentu un ar īpašnieku, un ko prasītu to pašu izdarīt pārējām.

Pieteikt sarunuApskatīt apkalpošanas atbalstu