API integracija su eFTI platforma: architektūros principai

Integracija su eFTI platforma techninėje prasme panaši į kitus B2B duomenų mainus — bet turi keletą specifinių reikalavimų, kuriuos verta suprasti dar prieš rašant pirmąjį užklausimo kodą.

Bendras modelis

┌──────────┐    1. Duomenys     ┌─────────────┐   3. Prieiga   ┌──────────────┐
│ ERP / TMS │ ───────────────► │ eFTI platforma │ ◄──────────── │ Institucijos │
└──────────┘                    └─────────────┘                └──────────────┘
      ▲                               │
      │        2. Unikali nuoroda     │
      └───────────────────────────────┘

Trys duomenų srautai:

1. Vidiniai duomenys → platforma (publikavimas): sugeneruotas ir pasirašytas vežimo duomenų rinkinys perduodamas per API;
2. Platforma → jūsų sistemos (nuorodos ir statusai): unikali identifikavimo nuoroda, institucijų prieigos faktai, patvirtinimai;
3. Institucijos → platforma (patikros): vyksta be jūsų dalyvavimo — tai ir yra eFTI idėja.

Autentifikavimas

Pagal reglamentą reikalinga patvirtinto autentiškumo saugi prieiga. Praktikoje teikėjai naudos:

• API raktus + sertifikatus mašininiam ryšiui (server-to-server);
• Federacinę tapatybę žmonėms (eIDAS priemonės, nacionaliniai e. parašai);
• Abipusį TLS kritiniams srautams.

Architektūriškai planuokite slaptų duomenų valdymą: jokios API prieigos reikšmės kode ar konfigūracijoje repozitorijoje, rotacijos kalendorius, skirtingi raktai testavimo ir produkcinei aplinkoms.

Duomenų srauto principai

Publikavimas — idempotentinis

Tas pats duomenų rinkinys, siunčiamas pakartotinai dėl tinklo trikdžio, neturi sukurti dublių. Naudokite versijavimą ir stabilius identifikatorius iš savo TMS.

Statusai — įvykių pagrindu

Platforma praneš apie institucijų prieigas ir statuso pokyčius (webhook’ai ar apklausos). Suplanuokite šių įvykių saugojimą savo pusėje — veiklos žurnalų logika taikoma ir jums.

Klaidos — aiškios ir veiksmingos

Gerai sukonstruota platforma grąžina validacijos klaidas su nuoroda į konkrečią bendrojo rinkinio vietą (anatomija čia). Jūsų integracija turėtų jas registruoti ir rodyti dispečeriui suprantama kalba.

Testavimo aplinka

Prieš pasirašydami sutartį patikrinkite:

1. Ar teikėjas turi sandbox su realiais scenarijais (sukurti, pasirašyti, parodyti, pateikti institucijai)?
2. Ar galima simuliuoti institucijų prieigą ir matyti, kaip atrodo žurnalas?
3. Ar dokumentuoti limitai (užklausų dažnis, dydis) ir versijų politika?

Integracijos projekto etapai

Praktiniams tiekėjo reikalavimams naudokite ERP integracijos gaires, o pasirengimą vertinkite audito sąraše.

Geriausia integracija — ta, kurios naudotojai nepastebi: duomenys gimsta ten, kur jie jau yra.