Pereiti prie pagrindinio turinio
FromNine
Meniu

Inžinerija

Integracijos, kurios palaiko duomenų judėjimą ir parodo, kai jis sustoja.

CRM, ERP, bylų sistemas ir valstybės platformas sujungiame per sutartis, įvykius ir tinkamai įgyvendintą tapatybės valdymą, todėl duomenys juda patikimai, klaidos matomos, o naujos galimybės, įskaitant dirbtinį intelektą (DI), prisijungia saugiai.

Organizacijoms, kurios sujungia sistemas, partnerius ir valstybės platformas Lietuvoje ir kitose ES valstybėse narėse.

Aptarkime Jūsų projektąPlatformos, kurias sujungiame
Integracijos ir API: gebėjimų sluoksniaiKeturi vienas po kito išdėstyti sluoksniai. Iš viršaus į apačią: vartotojai, tokie kaip portalai, programėlės ir agentai, API šliuzas su tapatybės valdymu, įvykių magistralė ir apačioje pirminės sistemos.01Portalai, programėlės ir agentai02API šliuzas ir tapatybė03Įvykių magistralė04Pirminės sistemos
  1. 01Sutartimi pradedamos API su OpenAPI ir AsyncAPI, versijuotos ir dokumentuotos
  2. 02Įvykiai su eiliškumu, idempotentiškumu, neįteiktų pranešimų tvarkymu ir pakartotiniu apdorojimu
  3. 03Srautai stebimi nuo pradžios iki galo, o klaidų eiles valdo konkrečios komandos

01 Problemos

Integracijos problemos, dėl kurių į mus kreipiamasi

  1. 01

    Tiesioginės jungtys, kurių niekas nedrįsta keisti

    Dešimtys tiesioginių jungčių tarp CRM, ERP ir individualių sistemų. Vieno lauko pakeitimas reiškia dešimties sąsajų testavimą.

  2. 02

    Dublikatai ir tylūs gedimai

    Pakartotinis bandymas sukuria antrą užsakymą. Nepavykęs pranešimas dingsta. Verslo naudotojai apie tai sužino iš klientų.

  3. 03

    Kiekvienas naujas kanalas reiškia naują integracijos darbą

    Portalui, mobiliajai programėlei, o dabar ir DI asistentui reikia tų pačių duomenų, ir kiekvienas gauna savo ištrauką.

  4. 04

    Jungtis prie valstybės sistemų tampa atskiru projektu

    Prisijungimas prie valstybės duomenų mainų platformos ar elektroninės atpažinties sistemos kaskart pareikalauja kelių mėnesių saugumo ir prijungimo darbų.

02 Ką pateikiame

Ką pateikiame

  1. 01 API strategija ir valdymas

    API projektavimas pradedant nuo OpenAPI ir AsyncAPI sutarčių, versijavimo politika, ją užtikrinantis šliuzas ir kūrėjų portalas, kad komandos rastų ir pakartotinai naudotų tai, kas jau yra.

    Ką darome

    • API visumos ir atsakomybės žemėlapis
    • Projektavimo gairės ir peržiūros procesas
    • Šliuzo politikos saugumui, kvotoms ir versijavimui
    • Kūrėjų portalas ir API katalogas

    Ką gaunate

    • Jūsų komandų priimtos API gairės
    • Šliuzo konfigūracija kaip kodas
    • Dokumentuotų API katalogas

  2. 02 Įvykiais grįsta integracija

    Pranešimų brokeriai, pokyčių fiksavimas ir outbox šablonas su detalėmis, kurios lemia, ar tai veiks: eiliškumas, idempotentiški vartotojai, neįteiktų pranešimų tvarkymas ir pakartotinis apdorojimas.

    Ką darome

    • Įvykių modelis ir pavadinimų susitarimai
    • Outbox ir CDC šaltinio sistemose
    • Vartotojų idempotentiškumas ir eiliškumo garantijos
    • Neįteiktų pranešimų eilės su pakartotinio apdorojimo įrankiais

    Ką gaunate

    • Įvykių magistralė gamybinėje aplinkoje
    • Schemų registras ir suderinamumo taisyklės
    • Pakartotinio apdorojimo ir atkūrimo vadovas

  3. 03 Integracijos platformos, parenkamos kiekvienam srautui

    SAP Integration Suite, MuleSoft ir debesijos integracijos paslaugos turi savo vietą. Pasakome, kada iPaaS pranašesnė už individualų kodą, o kada ne.

    Ką darome

    • Esamos tarpinės programinės įrangos vertinimas
    • Platformos pasirinkimas pagal bendrąsias valdymo išlaidas
    • Pakartotinai naudojami susiejimai ir jungtys
    • Perkėlimas nuo senosios tarpinės programinės įrangos

    Ką gaunate

    • Integracijos platformos sprendimo įrašas
    • Integracijos šablonų biblioteka
    • Esamų sąsajų perkėlimo planas

  4. 04 Tapatybė ir pasitikėjimas tarp sistemų

    OAuth 2.0 ir OpenID Connect, abipusis TLS, paslaugų tarpusavio tapatybė ir integracija su gyventojų ir įmonių elektronine atpažintimi: Lietuvoje tai asmens tapatybės kortelė, mobilusis parašas ir Smart-ID, o kitose valstybėse narėse jų nacionalinės schemos.

    Ką darome

    • Naudotojų ir paslaugų tapatybės architektūra
    • Prieigos raktų projektavimas, teisių ribos ir sutikimai
    • Pagalba prijungiant elektroninę atpažintį ir ją sertifikuojant
    • Pasirengimas Europos skaitmeninės tapatybės piniginėms

    Ką gaunate

    • Tapatybės projektas ir grėsmių modelis
    • Elektroninės atpažinties integracija gamybinėje aplinkoje
    • Įdiegtos paslaugų tapatybės ir slaptų duomenų keitimas

  5. 05 Sąveikumas su valstybės sistemomis

    Jungtys su valstybės informacinėmis sistemomis ir Elektroniniais valdžios vartais, e. sąskaitos perkančiosioms organizacijoms per SABIS, kitų valstybių narių duomenų mainų platformos ir ES vienkartinio pateikimo techninė sistema (OOTS).

    Ką darome

    • Prijungimas kartu su platformos valdytoju
    • Susiejimas su nacionaliniais duomenų standartais
    • Kiekvienos mainų platformos saugumo ir registravimo reikalavimai
    • Vienkartinio įrodymų pateikimo mainų projektavimas

    Ką gaunate

    • Patvirtinta jungtis prie mainų platformos
    • Susiejimo dokumentacija
    • Eksploatavimo procedūros, suderintos su valdytoju

  6. 06 Veiklos matomumas verslo naudotojams

    Srautų stebėsena, kurią supranta verslo naudotojai, duomenų suderinimas tarp sistemų ir klaidų eilės, kurias kas nors valdo ir sutvarko.

    Ką darome

    • Srautų stebėsena verslo lygiu
    • Suderinimo ataskaitos tarp sistemų
    • Klaidų klasifikavimas ir nukreipimas
    • Įspėjimai kiekvieno srauto savininkui

    Ką gaunate

    • Integracijos skydelis kiekvienam verslo procesui
    • Suderinimo patikros gamybinėje aplinkoje
    • Kiekvienos klaidų eilės atsakomybės žemėlapis

03 Architektūra

Iliustracinė etaloninė architektūra

Iš pirminių sistemų išeina du keliai. Sinchroninės užklausos eina per sistemų API ir šliuzą, kuris tikrina tapatybę, teisių ribas ir kvotas. Pakeitimai skelbiami kaip įvykiai per outbox ar pokyčių fiksavimą, o vartotojai juos apdoroja idempotentiškai.

Nepavykę pranešimai patenka į neįteiktų pranešimų eilę su pakartotiniu apdorojimu, o ne į žurnalo failą. Stebėsenos juosta kiekvieną srautą rodo verslo sąvokomis, todėl proceso savininkai mato, kada jis sustoja.

Brėžinio sluoksniai

Pirminės sistemos
ERP, CRM ir bylų valdymo sistemos išlieka savo duomenų šeimininkės.
Sinchroninės API
Versijuotos sistemų API už šliuzo su OAuth 2.0, mTLS ir kvotomis.
Įvykiai
Outbox, brokeris, neįteiktų pranešimų eilė ir integracijos platformos susiejimai.
Vartotojai
Portalai, programėlės, agentai, partneriai ir valstybės mainų platformos, su elektronine atpažintimi ten, kur dalyvauja gyventojai.
Iliustracinis pavyzdys

  1. Pirminės sistemos

    • ERP, CRM ir bylų sistemos

  2. Sinchroninės API

    • Sistemų API
    • API šliuzas: OAuth 2.0, mTLS, kvotos

  3. Įvykiai

    • Outbox ir CDC
    • Įvykių brokeris
    • Neįteikti pranešimai ir pakartojimas
    • Integracijos platformos susiejimai

  4. Vartotojai

    • Portalai, programėlės ir agentai
    • Partnerių ir valstybės mainai
    • Tapatybė: OIDC, mTLS, el. atpažintis

  5. Eksploatavimas

    • Srautų stebėsena, suderinimas, klaidų eilės su savininkais
API ir įvykių magistralė greta

Iliustracinė architektūra, ne kliento sistema.

Skaityti diagramą kaip tekstą

Pagrindinė trasa veda nuo pirminių sistemų per versijuotas sistemų API ir API šliuzą iki portalų, programėlių ir agentų.

Lygiagrečiai pirminės sistemos per outbox ir pokyčių fiksavimą skelbia pakeitimus įvykių brokeriui, kuris juos perduoda partnerių ir valstybės mainų platformoms ir integracijos platformai susiejimams. Nepavykę pranešimai patenka į neįteiktų pranešimų eilę su pakartotiniu apdorojimu. Tapatybės paslaugos su OAuth, mTLS ir elektronine atpažintimi apsaugo mainus su partneriais.

Apačioje esanti stebėsenos juosta rodo srautų būseną, suderinimą ir klaidų eiles su savininkais.

04 Aspektai ir ribos

Inžineriniai aspektai ir ribos

  • Lygiai vienas pristatymas yra projektavimo, o ne nustatymo klausimas

    Kaip tai sprendžiame

    Darome prielaidą, kad pranešimai gali ateiti du kartus ar ne iš eilės, ir vartotojus projektuojame idempotentiškus, su raktais ir eiliškumo taisyklėmis, sutartomis kiekvienam įvykio tipui.

    Ribos ir priklausomybės

    Kai kurios senosios sistemos negali priimti idempotentiškumo raktų ar pranešti, ką apdorojo. Aplink jas pridedame suderinimą, o ne apsimetame, kad problemos nėra.

  • iPaaS ne visada yra atsakymas

    Kaip tai sprendžiame

    Platformos laimi daugeliui standartinių jungčių ir susiejimų. Individualios paslaugos laimi sudėtingai logikai, didelėms apimtims ar griežtiems delsos reikalavimams. Pasirinkimą dokumentuojame kiekvienai integracijai.

    Ribos ir priklausomybės

    Licencijavimo modeliai keičiasi. Šiandien pigi platforma gali tapti didžiausia Jūsų integracijos biudžeto eilute, todėl išlaidas modeliuojame keleriems metams.

  • Valstybės mainų platformos nustato savo tempą

    Kaip tai sprendžiame

    Prijungimo dokumentus, saugumo įrodymus ir testų planus parengiame anksti ir su platformos valdytoju dirbame nuo pirmosios savaitės.

    Ribos ir priklausomybės

    Sertifikavimo ir prijungimo terminus nustato valdytojas, ne mes. Planuojame atsižvelgdami į juos ir parodome, kur jie yra kritiniame kelyje.

  • DI vartotojams reikia siaurų API

    Kaip tai sprendžiame

    Agentai ir asistentai gauna atskiras, apribotas API su limitais ir audito žurnalu, o ne tokią pačią plačią prieigą kaip vidinės paslaugos.

    Ribos ir priklausomybės

    API atvėrimas agentui prideda rizikos. Kiekvieną tokią API prieš paleidimą peržiūrime kartu su Jūsų saugumo komanda.

05 Kaip dirbame

Kaip dirbame

Prieš kurdami išnarpliojame, ir kiekvienas srautas lieka su savininku.

  1. 01

    Išsiaiškiname srautus

    Kiekviena sąsaja, jos apimtis, gedimų istorija ir verslo savininkas.

    RezultatasIntegracijos visuma ir rizikos reitingas

  2. 02

    Nustatome taisykles

    API gairės, įvykių susitarimai, tapatybės modelis ir platformos pasirinkimas.

    RezultatasIntegracijos gairės ir sprendimų įrašai

  3. 03

    Perkeliame srautą po srauto

    Pirmiausia rizikingiausi srautai, o suderinimas veikia greta senosios sąsajos, kol skaičiai sutampa.

    RezultatasPerkelti srautai su suderinimo įrodymais

  4. 04

    Eksploatuojame matomai

    Skydeliai kiekvienam verslo procesui ir klaidų eilės su konkrečiais savininkais.

    RezultatasSrautų atsakomybės žemėlapis ir skydeliai

06 Žmogaus kontrolė

Kur sprendžia žmonės

Integracija veikia be priežiūros. Atsakomybė už tai, kas nepavyksta, be žmonių neįmanoma.

  • Kiekviena klaidų eilė turi savininką

    Nepavykę pranešimai su kontekstu ir pakartojimo mygtuku patenka į už juos atsakingos komandos eilę, o ne į bendrą žurnalą.

  • Sutarčių pakeitimai peržiūrimi

    Nesuderinami API ar įvykių pakeitimai prieš paskelbiant peržiūrimi kartu su vartotojais.

  • Pakartotinis apdorojimas yra sąmoningas

    Pranešimų pakartojimas pirminėje sistemoje yra leidimo reikalaujantis veiksmas, registruojamas nurodant, kas ir kodėl jį atliko.

07 Technologijos

Technologijos, su kuriomis dirbame

Integracijos platformos
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • AWS ir Google Cloud integracijos paslaugos
Įvykiai ir srautai
  • Apache Kafka
  • RabbitMQ
  • Debesijos įvykių brokeriai
  • Debezium pokyčių fiksavimui
API
  • OpenAPI ir AsyncAPI
  • API šliuzai ir kūrėjų portalai
  • GraphQL ten, kur tinka
  • Sutarčių testavimas
Tapatybė
  • OAuth 2.0 ir OpenID Connect
  • Abipusis TLS
  • Keycloak ir debesijos tapatybės teikėjai
  • Nacionalinės elektroninės atpažinties schemos

Technologijos paminėjimas apibūdina mūsų inžinerinę patirtį. Tai nereiškia partnerystės su jos gamintoju ar gamintojo pritarimo.

08 Pavyzdys

Iliustracinis pavyzdys

Iliustracinis pavyzdys

E. sąskaitos perkančiosioms organizacijoms per SABIS iš ERP sistemos

01Situacija
Įmonė, tiekianti prekes ir paslaugas savivaldybėms ir valstybės įstaigoms, e. sąskaitas SABIS sistemoje suveda rankiniu būdu. Dalyje sąskaitų trūksta sutarties ar užsakymo duomenų, todėl jas tenka taisyti ir pateikti iš naujo, o apmokėjimas vėluoja.
02Ką kurtume
Integracija tarp ERP sistemos ir SABIS, kuri iš ERP duomenų parengia e. sąskaitą, prieš pateikdama patikrina privalomus laukus ir sutarties duomenis ir registruoja kiekvieno pateikimo eigą.
03Žmogaus kontrolė
Buhalterija patvirtina kiekvieną sąskaitą prieš pateikimą, o sąskaitas, kurių nepavyko patikrinti, peržiūri atsakingas darbuotojas.
04Ką matuotume
Be pataisymų priimtų sąskaitų dalis, laikas nuo sąskaitos išrašymo iki pateikimo ir rankinių pataisymų skaičius.

09 Sektoriaus požiūriu

Jūsų sektoriuje

  • Viešasis sektorius

    Vienkartinis duomenų pateikimas iš autentiškų šaltinių, elektroninė atpažintis gyventojams ir įmonėms ir registravimas, kurio reikalauja valstybės platformos. Plačiau apie mūsų darbą viešajame sektoriuje.

  • Gamyba ir pramonė

    ERP, MES ir tiekėjų portalai, sujungti įvykiais, kad planavimas, gamyba ir aptarnavimas matytų tą patį vaizdą.

  • Finansinės paslaugos

    Pagrindinės sistemos, CRM ir partnerių API, sujungtos su patikimu tapatybės valdymu, audito žurnalu ir suderinimu, kuriuo pasitiki finansų skyrius.

Lietuva

Sąveikumas Lietuvoje ir visoje ES

Lietuvoje gyventojai ir įmonės elektronines paslaugas pasiekia per Elektroninius valdžios vartus, o elektroninei atpažinčiai naudoja asmens tapatybės kortelę, mobilųjį parašą ar Smart-ID. E. sąskaitos perkančiosioms organizacijoms privalomos nuo 2017 m. liepos 1 d. ir šiandien teikiamos per SABIS, o viešieji pirkimai vyksta CVP IS sistemoje.

Tarpvalstybinės paslaugos kiekvienoje šalyje susiduria su kita duomenų mainų platforma, atpažinties schema ir duomenų standartu. Europos sąveikumo aktas įpareigoja viešojo sektoriaus institucijas vertinti tarpvalstybinį sąveikumą, o eIDAS 2 įveda Europos skaitmeninės tapatybės pinigines, kurias kiekviena valstybė narė turi pasiūlyti.

Integracijos sluoksnius projektuojame taip, kad nacionalinės mainų platformos ir atpažinties schemos būtų adapteriai už stabilių vidinių sutarčių. Tada nauja šalis reiškia naują adapterį ir jo prijungimą, o ne už jo esančių sistemų perdarymą.

Klausimai apie integracijas ir API

Naudoti integracijos platformą ar kurti individualias integracijas?

Ir viena, ir kita, tik skirtingiems srautams. Standartinėms jungtims, susiejimams ir partnerių prijungimui labiau tinka platforma. Didelės apimties, delsai jautriems ar sudėtingos logikos srautams dažnai geriau tinka individualios paslaugos. Sprendžiame kiekvienam srautui atskirai ir dokumentuojame kodėl.

Ar integruojate Salesforce, SAP ir Odoo?

Taip, reguliariai: tarpusavyje ir su individualiomis bei valstybės sistemomis. FromNine yra visų trijų platformų partneris: Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner. Todėl mūsų integracijos komandos dirba kartu su platformų specialistais. Plačiau apie mūsų darbą su SAP.

Ar mums reikia įvykiais grįstos integracijos?

Įvykiai padeda, kai kelios sistemos turi reaguoti į tą patį pakeitimą arba kai reikia atskirti išleidimų ciklus. Paprastai užklausai ir atsakymui tarp dviejų sistemų dažnai pakanka API. Dauguma sistemų visumų naudoja abu būdus.

Ar galite integruoti nacionalinę elektroninę atpažintį?

Taip. Integruojame gyventojų ir įmonių elektroninės atpažinties priemones, Lietuvoje asmens tapatybės kortelę, mobilųjį parašą ir Smart-ID, ir projektuojame atsižvelgdami į Europos skaitmeninės tapatybės pinigines, kurias valstybės narės pagal eIDAS 2 turi pasiūlyti iki 2026 m. gruodžio 24 d. Prijungimo reikalavimai kiekvienai schemai skiriasi, todėl juos planuojame anksti.

Turime senąją tarpinę programinę įrangą. Ar turime ją pakeisti?

Ne iš karto. Išsiaiškiname, kas joje veikia, pirmiausia perkeliame rizikingiausius ar brangiausius srautus, o suderinimą paliekame tol, kol kiekvienas perkeltas srautas įrodo, kad veikia.

Atsineškite dažniausiai sutrinkančią sąsają

Parodysime, kaip ją padarytume stebimą, idempotentišką ir turinčią savininką, ir ko reikėtų, kad taip būtų su visomis kitomis.

Aptarkime Jūsų projektąKlientų ir gyventojų aptarnavimas