Preskočite na glavno vsebino
FromNine
Meni

Razvoj in oblak

Integracije, ki ohranjajo pretok podatkov in pokažejo, ko se ustavi.

Sisteme CRM, ERP, sisteme za vodenje zadev in državne platforme povezujemo s pogodbami, dogodki in pravilno urejeno identiteto, da se podatki zanesljivo prenašajo, napake so vidne, nove zmogljivosti, tudi umetna inteligenca (UI), pa se lahko varno priključijo.

Za organizacije v Sloveniji, ki povezujejo sisteme, partnerje in javne platforme, tudi v drugih državah članicah.

Integracije in API-ji: plasti zmogljivostiŠtiri plasti, naložene druga na drugo. Od zgoraj navzdol: uporabniki podatkov, kot so portali, aplikacije in agenti, prehod API z identiteto, hrbtenica dogodkov in izvorni sistemi na dnu.01Portali, aplikacije in agenti02Prehod API in identiteta03Hrbtenica dogodkov04Izvorni sistemi
  1. 01API-ji, zasnovani najprej kot pogodba v OpenAPI in AsyncAPI, z različicami in dokumentacijo
  2. 02Dogodki z vrstnim redom, idempotentnostjo, obravnavo neuspešnih sporočil in ponovnim predvajanjem
  3. 03Tokovi, spremljani od začetka do konca, in vrste napak z imenovanimi ekipami kot lastniki

01 Težave

Težave z integracijami, zaradi katerih nas pokličejo

  1. 01

    Neposredne povezave, ki si jih nihče ne upa spremeniti

    Na desetine neposrednih povezav med CRM, ERP in sistemi po meri. Sprememba enega polja pomeni testiranje desetih vmesnikov.

  2. 02

    Dvojniki in tihe napake

    Ponovni poskus ustvari drugo naročilo. Neuspešno sporočilo izgine. Poslovni uporabniki za to izvedo od strank.

  3. 03

    Vsak nov kanal pomeni novo integracijo

    Portal, mobilna aplikacija in zdaj še asistent UI potrebujejo iste podatke, vsak pa dobi svoj izvoz.

  4. 04

    Povezave z državnimi sistemi so projekt zase

    Povezava z državno platformo za izmenjavo podatkov ali shemo elektronske identitete vsakič zahteva mesece varnostnega dela in vključevanja.

02 Kaj zagotovimo

Kaj zagotovimo

  1. 01 Strategija in upravljanje API-jev

    Zasnova, pri kateri je API na prvem mestu, s pogodbami OpenAPI in AsyncAPI, pravili za različice, prehodom, ki jih uveljavlja, in portalom za razvijalce, da ekipe najdejo in ponovno uporabijo, kar že obstaja.

    Kaj naredimo

    • Pregled API-jev in zemljevid lastništva
    • Smernice za zasnovo in postopek pregleda
    • Pravila prehoda za varnost, kvote in različice
    • Portal za razvijalce in katalog API-jev

    Kaj prejmete

    • Smernice za API-je, ki so jih sprejele vaše ekipe
    • Konfiguracija prehoda kot koda
    • Katalog dokumentiranih API-jev
  2. 02 Integracija na podlagi dogodkov

    Posredniki sporočil, zajem sprememb podatkov in vzorec outbox, s podrobnostmi, ki odločajo o delovanju: vrstni red, idempotentni porabniki, obravnava neuspešnih sporočil in ponovno predvajanje.

    Kaj naredimo

    • Model dogodkov in pravila poimenovanja
    • Outbox in CDC na izvornih sistemih
    • Idempotentnost porabnikov in jamstva vrstnega reda
    • Vrste neuspešnih sporočil z orodji za ponovno predvajanje

    Kaj prejmete

    • Hrbtenica dogodkov v produkciji
    • Register shem in pravila združljivosti
    • Navodila za ponovno predvajanje in obnovo
  3. 03 Integracijske platforme, izbrane za vsak tok

    SAP Integration Suite, MuleSoft in integracijske storitve oblačnih ponudnikov imajo vsaka svoje mesto. Povemo vam, kdaj je iPaaS boljši od kode po meri in kdaj ni.

    Kaj naredimo

    • Ocena obstoječe vmesne programske opreme
    • Izbira platforme s skupnimi stroški lastništva
    • Ponovno uporabne preslikave in konektorji
    • Prehod s starejše vmesne programske opreme

    Kaj prejmete

    • Zapis odločitve o integracijski platformi
    • Knjižnica integracijskih vzorcev
    • Načrt prehoda za obstoječe vmesnike
  4. 04 Identiteta in zaupanje med sistemi

    OAuth 2.0 in OpenID Connect, vzajemni TLS, identiteta med storitvami in povezava z elektronsko identiteto za državljane in podjetja: v Sloveniji SI-PASS z e-osebno izkaznico, aplikacijo eOsebna, kvalificiranimi digitalnimi potrdili in smsPASS, za družbe v drugih državah pa njihove nacionalne sheme.

    Kaj naredimo

    • Arhitektura identitete za uporabnike in storitve
    • Zasnova žetonov, obsegov in privolitev
    • Podpora pri vključitvi v sheme eID in certificiranju
    • Priprava na evropske denarnice za digitalno identiteto

    Kaj prejmete

    • Zasnova identitete in model groženj
    • Povezava z eID v produkciji
    • Vzpostavljena identiteta storitev in menjava skrivnosti
  5. 05 Povezljivost z državnimi sistemi

    Povezave z državnimi portali in platformami za izmenjavo podatkov: v Sloveniji prijava SI-PASS s povezavami na eUpravo in SPOT ter izmenjava e-računov s proračunskimi uporabniki prek UJP, za družbe skupine v drugih državah na primer FIT-Connect v Nemčiji in PDND v Italiji, ter evropski tehnični sistem na podlagi načela »samo enkrat«.

    Kaj naredimo

    • Vključitev v sodelovanju z upravljavcem platforme
    • Preslikava na nacionalne podatkovne standarde
    • Varnostne zahteve in zahteve glede beleženja posamezne izmenjave
    • Zasnova izmenjave dokazil po načelu »samo enkrat«

    Kaj prejmete

    • Potrjena povezava z izmenjavo
    • Dokumentacija preslikav
    • Operativni postopki z upravljavcem
  6. 06 Operativni pregled za poslovne uporabnike

    Spremljanje tokov, ki ga razumejo poslovni uporabniki, usklajevanje med sistemi in vrste napak, ki imajo lastnika, ki jih obdela.

    Kaj naredimo

    • Spremljanje tokov na poslovni ravni
    • Poročila o usklajenosti med sistemi
    • Razvrščanje in usmerjanje napak
    • Opozorila za vsakega lastnika toka

    Kaj prejmete

    • Nadzorna plošča integracij za vsak poslovni proces
    • Preverjanja usklajenosti v produkciji
    • Zemljevid lastništva za vsako vrsto napak

03 Arhitektura

Ponazoritvena referenčna arhitektura

Iz izvornih sistemov vodita dve poti. Sinhrone zahteve gredo prek sistemskih API-jev in prehoda, ki preveri identiteto, obseg pravic in kvote. Spremembe se objavijo kot dogodki prek vzorca outbox ali zajema sprememb podatkov, porabniki pa jih obdelajo idempotentno.

Neuspešna sporočila pristanejo v vrsti neuspešnih sporočil s ponovnim predvajanjem, ne v dnevniški datoteki. Pas spremljanja prikaže vsak tok v poslovnih pojmih, zato ljudje, ki so lastniki procesa, vidijo, ko se ustavi.

Plasti na sliki

Izvorni sistemi
ERP, CRM in vodenje zadev ostanejo merodajni za svoje podatke.
Sinhroni API-ji
Sistemski API-ji z različicami za prehodom z OAuth 2.0, mTLS in kvotami.
Dogodki
Outbox, posrednik, vrsta neuspešnih sporočil in preslikave integracijske platforme.
Porabniki
Portali, aplikacije, agenti, partnerji in državne izmenjave, z eID, kjer sodelujejo državljani.
Ponazoritveni primer
  1. Izvorni sistemi

    • ERP, CRM in sistemi za zadeve
  2. Sinhroni API-ji

    • Sistemski API-ji
    • Prehod API: OAuth 2.0, mTLS, kvote
  3. Dogodki

    • Outbox in CDC
    • Posrednik dogodkov
    • Neuspešna sporočila in ponovitev
    • Preslikave integracijske platforme
  4. Porabniki

    • Portali, aplikacije in agenti
    • Izmenjave s partnerji in državo
    • Identiteta: OIDC, mTLS, eID
  5. Delovanje

    • Spremljanje tokov, usklajevanje, vrste napak z lastniki
API-ji in hrbtenica dogodkov, drug ob drugem

Ponazoritvena arhitektura, ne sistem stranke.

Preberite diagram kot besedilo

Glavna pot vodi od izvornih sistemov prek sistemskih API-jev z različicami in prehoda API do portalov, aplikacij in agentov.

Vzporedno izvorni sistemi objavljajo spremembe prek vzorca outbox in zajema sprememb podatkov posredniku dogodkov, ki jih dostavi izmenjavam s partnerji in državnimi sistemi ter integracijski platformi za preslikave. Neuspešna sporočila gredo v vrsto neuspešnih sporočil s ponovnim predvajanjem. Storitve identitete z OAuth, mTLS in eID varujejo izmenjave s partnerji.

Pas spremljanja spodaj prikazuje stanje tokov, usklajenost in vrste napak z lastniki.

04 Premisleki in omejitve

Tehnični premisleki in omejitve

  • Natanko enkrat je zasnova, ne nastavitev

    Kako to rešujemo

    Predpostavimo, da sporočila prispejo dvakrat ali v napačnem vrstnem redu, zato porabnike zasnujemo idempotentno, s ključi in pravili vrstnega reda, dogovorjenimi za vsako vrsto dogodka.

    Omejitve in odvisnosti

    Nekateri starejši sistemi ne sprejemajo ključev idempotentnosti in ne poročajo, kaj so obdelali. Okoli njih dodamo usklajevanje, namesto da bi se pretvarjali.

  • iPaaS ni vedno odgovor

    Kako to rešujemo

    Platforme so boljše pri številnih standardnih konektorjih in preslikavah. Storitve po meri so boljše pri zahtevni logiki, velikih količinah ali strogih zahtevah glede zakasnitve. Izbiro dokumentiramo za vsako integracijo.

    Omejitve in odvisnosti

    Licenčni modeli se spreminjajo. Platforma, ki je danes poceni, lahko postane največja postavka vašega proračuna za integracije, zato stroške modeliramo za več let.

  • Državne izmenjave določajo svoj tempo

    Kako to rešujemo

    Dokumentacijo za vključitev, varnostna dokazila in testne načrte pripravimo zgodaj in z upravljavcem platforme sodelujemo od prvega tedna.

    Omejitve in odvisnosti

    Roke za certificiranje in vključitev določa upravljavec, ne mi. Načrtujemo okoli njih in vam povemo, kje so na kritični poti.

  • Porabniki UI potrebujejo ozke API-je

    Kako to rešujemo

    Agenti in asistenti dobijo namenske API-je z omejenimi pravicami, limiti in revizijskim beleženjem, ne enako širokega dostopa kot notranje storitve.

    Omejitve in odvisnosti

    Vsak API, ki ga odpremo agentu, pomeni dodatno tveganje. Vsakega pred uvedbo pregledamo z vašo varnostno službo.

05 Kako delamo

Kako delamo

Najprej razpletemo, nato gradimo, in vsakemu toku določimo lastnika.

  1. 01

    Popišemo tokove

    Vsak vmesnik, njegov obseg, zgodovina napak in poslovni lastnik.

    RezultatPregled integracij in razvrstitev tveganj

  2. 02

    Določimo pravila

    Smernice za API-je, pravila za dogodke, model identitete in izbira platforme.

    RezultatSmernice za integracije in zapisi odločitev

  3. 03

    Selimo tok za tokom

    Najprej najbolj tvegani tokovi, z usklajevanjem ob starem vmesniku, dokler se številke ne ujemajo.

    RezultatPreneseni tokovi z dokazi o usklajenosti

  4. 04

    Pregledno delovanje

    Nadzorne plošče za vsak poslovni proces in vrste napak z imenovanimi lastniki.

    RezultatZemljevid lastništva tokov in nadzorne plošče

06 Človeški nadzor

Kje odloča človek

Integracije delujejo samodejno. Odgovornost za to, kar gre narobe, pa mora imeti lastnika.

  • Vsaka vrsta napak ima lastnika

    Neuspešna sporočila gredo ekipi, ki je zanje odgovorna, s kontekstom in gumbom za ponovno predvajanje, ne v skupni dnevnik.

  • Spremembe pogodb se pregledajo

    Nezdružljive spremembe API-jev ali dogodkov gredo pred objavo skozi pregled s porabniki.

  • Ponovna predvajanja so premišljena

    Ponovno predvajanje sporočil v izvorni sistem je pooblaščeno dejanje, zabeleženo s tem, kdo ga je izvedel in zakaj.

07 Tehnologije

Tehnologije, s katerimi delamo

Integracijske platforme
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Integracijske storitve AWS in Google Cloud
Dogodki in pretakanje
  • Apache Kafka
  • RabbitMQ
  • Oblačni posredniki dogodkov
  • Debezium za zajem sprememb podatkov
API-ji
  • OpenAPI in AsyncAPI
  • Prehodi API in portali za razvijalce
  • GraphQL, kjer je primeren
  • Pogodbeno testiranje
Identiteta
  • OAuth 2.0 in OpenID Connect
  • Vzajemni TLS
  • Keycloak in ponudniki identitete v oblaku
  • Nacionalne sheme eID, tudi SI-PASS

Navedba tehnologije opisuje naše inženirske izkušnje. Ne pomeni partnerstva z njenim ponudnikom ali njegove podpore.

08 Primer

Ponazoritveni primer

Ponazoritveni primer

ERP, povezan s ponudnikom e-poti pred 1. januarjem 2028

01Izhodišče
Proizvodno podjetje s hčerinskima družbama na Hrvaškem in v Avstriji izdaja račune iz ERP kot datoteke PDF po e-pošti, prejete račune pa ročno vnaša. Od 1. januarja 2028 si mora z drugimi poslovnimi subjekti za dobave v Sloveniji izmenjevati samo e-račune.
02Kaj bi zgradili
Integracijska plast med sistemom ERP in ponudnikom e-poti ali dostopno točko Peppol, ki izdane in prejete e-račune obdeluje v standardu e-SLOG ali v sintaksi, skladni z evropskim standardom, prejete račune pa poveže z naročilnicami in prevzemi.
03Kje odloča človek
Računovodstvo potrdi preslikavo podatkov in odobri prejete račune, ki se ne ujemajo z naročilom; ponudnika e-poti izbere podjetje samo.
04Kaj bi merili
Delež računov, izmenjanih v strukturirani obliki, čas od prejema do knjiženja in število ročno popravljenih računov.

09 Panoge

V vaši panogi

  • Izmenjava podatkov z avtentičnimi viri po načelu »samo enkrat«, prijava SI-PASS za državljane in podjetja ter beleženje, ki ga zahtevajo upravljavci državnih platform. Več o našem delu za javni sektor.

  • ERP, MES in portali za dobavitelje, povezani z dogodki, da imajo načrtovanje, proizvodnja in servis enako sliko, ter e-računi s kupci in dobavitelji od 1. januarja 2028.

  • Osrednji sistemi, CRM in API-ji za partnerje, povezani z zanesljivo identiteto, revizijskim beleženjem in usklajevanjem, ki mu finance zaupajo.

Slovenija

E-računi od leta 2028 in povezljivost čez meje

Od 1. januarja 2028 si poslovni subjekti, to so vse enote v Poslovnem registru Slovenije in fizične osebe, ki opravljajo dejavnost, za dobave blaga in storitev v Sloveniji izmenjujejo samo e-račune (ZIERDED). Uporabljajo standard e-SLOG ali sintakse, skladne z evropskim standardom, izmenjava pa poteka prek registriranih ponudnikov e-poti, omrežja Peppol in certificiranih dostopnih točk Peppol ali neposredno. Pošiljanje po e-pošti ni dovoljeno, PDF pa ni e-račun. Izmenjanih e-računov se Finančni upravi ne poroča.

Seznam ponudnikov e-poti, ki ga vodi UJP, bo vzpostavljen 1. oktobra 2027. Proračunski uporabniki že od 1. januarja 2015 prejemajo samo e-račune, prek UJP kot enotne vstopne in izstopne točke; pravna podlaga je danes Zakon o plačilnih in javnofinančnih storitvah (ZPJS, Uradni list RS, št. 85/25).

Čezmejne storitve v vsaki državi naletijo na drugačno izmenjavo podatkov, shemo eID in podatkovni standard. Akt o interoperabilni Evropi od javnih organov zahteva oceno čezmejne interoperabilnosti, eIDAS 2 pa prinaša evropske denarnice za digitalno identiteto. Integracijske plasti zasnujemo tako, da so nacionalne izmenjave in sheme identitete adapterji za stabilnimi notranjimi pogodbami, zato nova država pomeni nov adapter, ne predelave sistemov v ozadju.

Vprašanja o integracijah in API-jih

Ali naj uporabimo integracijsko platformo ali razvijemo integracije po meri?

Oboje, za različne tokove. Za standardne konektorje, preslikave in vključevanje partnerjev je boljša platforma. Tokovi z velikimi količinami, strogimi zahtevami glede zakasnitve ali zahtevno logiko so pogosto bolje rešeni s storitvami po meri. Odločimo se za vsak tok posebej in zapišemo zakaj.

Ali povezujete Salesforce, SAP in Odoo?

Da, redno, med seboj ter s sistemi po meri in državnimi sistemi. FromNine je partner vseh treh (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), zato naše ekipe za integracije delajo skupaj s specialisti za platforme. Oglejte si naše delo z integracijami SAP.

Ali potrebujemo integracijo na podlagi dogodkov?

Dogodki pomagajo, kadar se mora na isto spremembo odzvati več sistemov ali kadar želite ločiti cikle izdaj. Za preprosto zahtevo in odgovor med dvema sistemoma pogosto zadošča API. Večina okolij uporablja oboje.

Ali lahko povežete SI-PASS in druge nacionalne sheme eID?

Da. Povezujemo sheme elektronske identitete za državljane in podjetja, pri slovenskih storitvah prijavo prek SI-PASS, in se pripravljamo na evropske denarnice za digitalno identiteto, ki jih po eIDAS 2 uvajajo države članice. Zahteve za vključitev se med shemami razlikujejo, zato jih načrtujemo zgodaj.

Imamo starejšo vmesno programsko opremo. Jo moramo zamenjati?

Ne vse naenkrat. Popišemo, kaj teče na njej, najprej prenesemo najbolj tvegane ali najdražje tokove, usklajevanje pa ohranimo, dokler se vsak preneseni tok ne izkaže.

Prinesite vmesnik, ki najpogosteje odpove

Pokazali vam bomo, kako bi ga naredili opazljivega, idempotentnega in z lastnikom, ter kaj bi bilo potrebno, da enako storimo za ostale.