Přejít na hlavní obsah
FromNine
Nabídka

Vývoj

Integrace, které udrží data v pohybu a ukážou, když se zastaví.

Propojujeme CRM, ERP, agendové systémy a platformy veřejné správy pomocí kontraktů, událostí a správně řešené identity. Data se tak přesouvají spolehlivě, chyby jsou vidět a nové schopnosti včetně AI se mohou bezpečně připojit.

Pro firmy a instituce v Česku, které propojují ERP, CRM a agendové systémy s partnery, úřady a platformami veřejné správy.

Domluvit konzultaciPlatformy, které propojujeme
Integrace a API: vrstvy schopnostíČtyři vrstvy nad sebou. Shora dolů: spotřebitelé jako portály, aplikace a agenti, brána API s identitou, páteř událostí a pod tím evidenční systémy.01Portály, aplikace a agenti02Brána API a identita03Páteř událostí04Evidenční systémy
  1. 01API navržená od kontraktu v OpenAPI a AsyncAPI, verzovaná a zdokumentovaná
  2. 02Události s pořadím, idempotencí, frontou nedoručených zpráv a možností přehrání
  3. 03Toky sledované od začátku do konce, chybové fronty s určenými týmy

01 Problémy

Problémy s integrací, kvůli kterým nás volají

  1. 01

    Přímá propojení, na která si nikdo netroufne sáhnout

    Desítky přímých spojení mezi CRM, ERP a systémy na míru. Změna jednoho pole znamená testovat deset rozhraní.

  2. 02

    Duplicity a tichá selhání

    Opakovaný pokus vytvoří druhou objednávku. Neúspěšná zpráva zmizí. Uživatelé se to dozvědí od zákazníků.

  3. 03

    Každý nový kanál znamená novou integraci

    Portál, mobilní aplikace a teď i asistent s AI potřebují stejná data a každý dostává vlastní export.

  4. 04

    Napojení na veřejnou správu je samostatný projekt

    Připojení k národní platformě pro výměnu dat nebo ke schématu elektronické identity pokaždé znamená měsíce práce na bezpečnosti a připojení.

02 Co dodáváme

Co dodáváme

  1. 01 Strategie a správa API

    Návrh API od kontraktu v OpenAPI a AsyncAPI, pravidla verzování, brána, která je vynucuje, a vývojářský portál, kde týmy najdou a znovu použijí to, co už existuje.

    Co děláme

    • Mapa API a jejich vlastníků
    • Zásady návrhu a postup revize
    • Pravidla brány pro bezpečnost, kvóty a verzování
    • Vývojářský portál a katalog API

    Co dostanete

    • Zásady pro API přijaté vašimi týmy
    • Konfigurace brány jako kód
    • Katalog zdokumentovaných API

  2. 02 Integrace řízená událostmi

    Brokery, zachytávání změn a vzor outbox, včetně detailů, které rozhodují o úspěchu: pořadí, idempotentní spotřebitelé, fronta nedoručených zpráv a přehrání.

    Co děláme

    • Model událostí a konvence pojmenování
    • Outbox a CDC ve zdrojových systémech
    • Idempotence spotřebitelů a záruky pořadí
    • Fronty nedoručených zpráv s nástroji pro přehrání

    Co dostanete

    • Páteř událostí v provozu
    • Registr schémat a pravidla kompatibility
    • Provozní příručka pro přehrání a obnovu

  3. 03 Integrační platformy zvolené pro každý tok

    SAP Integration Suite, MuleSoft i cloudové integrační služby mají své místo. Řekneme vám, kdy iPaaS vyhraje nad vlastním kódem a kdy ne.

    Co děláme

    • Posouzení stávajícího middlewaru
    • Volba platformy s celkovými náklady na vlastnictví
    • Znovupoužitelná mapování a konektory
    • Migrace ze staršího middlewaru

    Co dostanete

    • Záznam o rozhodnutí o integrační platformě
    • Knihovna integračních vzorů
    • Plán migrace stávajících rozhraní

  4. 04 Identita a důvěra mezi systémy

    OAuth 2.0 a OpenID Connect, vzájemné TLS, identita mezi službami a napojení na elektronickou identitu občanů a firem: v Česku Identita občana s eObčankou, mobilním klíčem a Bank iD, v dalších zemích například itsme, DigiD a eHerkenning, BundID, FranceConnect, Cl@ve, SPID a CIE.

    Co děláme

    • Architektura identity pro uživatele a služby
    • Návrh tokenů, rozsahů oprávnění a souhlasů
    • Podpora při připojení k eID a jeho certifikaci
    • Příprava na evropské peněženky digitální identity

    Co dostanete

    • Návrh identity a model hrozeb
    • Napojení na eID v provozu
    • Identity služeb a rotace tajných klíčů v provozu

  5. 05 Propojení s veřejnou správou

    Napojení na národní platformy pro výměnu dat a na evropský technický systém podle zásady „pouze jednou“. V Česku odpovídá za eGovernment, základní registry a elektronickou identifikaci Digitální a informační agentura (DIA). Pro skupiny působící i v zahraničí napojujeme také platformy dalších zemí, například Digikoppeling v Nizozemsku, FIT-Connect v Německu nebo PDND v Itálii.

    Co děláme

    • Připojení ve spolupráci s provozovatelem platformy
    • Mapování na národní datové standardy
    • Požadavky každé výměny na bezpečnost a logování
    • Návrh výměny dokladů podle zásady „pouze jednou“

    Co dostanete

    • Certifikované připojení k výměně dat
    • Dokumentace mapování
    • Provozní postupy dohodnuté s provozovatelem

  6. 06 Provozní přehled pro byznys

    Sledování toků, kterému rozumějí uživatelé z byznysu, odsouhlasení mezi systémy a chybové fronty, které někdo vlastní a skutečně vyřizuje.

    Co děláme

    • Sledování toků na úrovni obchodních procesů
    • Zprávy o odsouhlasení mezi systémy
    • Klasifikace a směrování chyb
    • Upozornění pro vlastníka každého toku

    Co dostanete

    • Integrační dashboard pro každý obchodní proces
    • Kontroly odsouhlasení v provozu
    • Mapa vlastníků všech chybových front

03 Architektura

Ilustrativní referenční architektura

Z evidenčních systémů vedou dvě cesty. Synchronní požadavky jdou přes systémová API a bránu, která kontroluje identitu, rozsah oprávnění a kvóty. Změny se publikují jako události přes outbox nebo zachytávání změn a spotřebitelé je zpracovávají idempotentně.

Neúspěšné zprávy končí ve frontě nedoručených zpráv s možností přehrání, ne v souboru s logem. Pás sledování ukazuje každý tok v obchodních pojmech, takže lidé, kteří proces vlastní, vidí, kdy se zastavil.

Vrstvy v diagramu

Evidenční systémy
ERP, CRM a agendové systémy si ponechávají autoritu nad svými daty.
Synchronní API
Verzovaná systémová API za bránou s OAuth 2.0, mTLS a kvótami.
Události
Outbox, broker, fronta nedoručených zpráv a mapování v integrační platformě.
Spotřebitelé
Portály, aplikace, agenti, partneři a výměny s veřejnou správou, s eID tam, kde jde o občany.
Ilustrativní příklad

  1. Evidenční systémy

    • ERP, CRM a agendové systémy

  2. Synchronní API

    • Systémová API
    • Brána API: OAuth 2.0, mTLS, kvóty

  3. Události

    • Outbox a CDC
    • Broker událostí
    • Nedoručené zprávy a přehrání
    • Mapování v integrační platformě

  4. Spotřebitelé

    • Portály, aplikace a agenti
    • Výměny s partnery a veřejnou správou
    • Identita: OIDC, mTLS, eID

  5. Provoz

    • Sledování toků, odsouhlasení, chybové fronty s vlastníky
API a páteř událostí vedle sebe

Ilustrativní architektura, nikoli systém klienta.

Zobrazit diagram jako text

Hlavní trasa vede z evidenčních systémů přes verzovaná systémová API a bránu API k portálům, aplikacím a agentům.

Souběžně evidenční systémy publikují změny přes outbox a zachytávání změn do brokeru událostí, který je doručuje do výměn dat s partnery a veřejnou správou a do integrační platformy pro mapování. Neúspěšné zprávy jdou do fronty nedoručených zpráv s možností přehrání. Služby identity s OAuth, mTLS a eID zabezpečují výměny s partnery.

Pás sledování vespod ukazuje stav toků, odsouhlasení a chybové fronty s vlastníky.

04 Úvahy a limity

Technické úvahy a limity

  • Doručení právě jednou je návrh, ne nastavení

    Jak to řešíme

    Počítáme s tím, že zprávy dorazí dvakrát nebo v jiném pořadí, a spotřebitele navrhujeme jako idempotentní, s klíči a pravidly pořadí dohodnutými pro každý typ události.

    Limity a závislosti

    Některé starší systémy neumějí přijmout klíče idempotence ani ohlásit, co zpracovaly. Kolem nich doplníme odsouhlasení, místo abychom předstírali opak.

  • iPaaS není vždy odpověď

    Jak to řešíme

    Platformy vyhrávají u mnoha standardních konektorů a mapování. Vlastní služby vyhrávají u složité logiky, velkých objemů nebo přísných požadavků na latenci. Volbu dokumentujeme pro každou integraci.

    Limity a závislosti

    Licenční modely se mění. Platforma, která je dnes levná, se může stát největší položkou integračního rozpočtu, proto náklady modelujeme na několik let dopředu.

  • Výměny s veřejnou správou mají vlastní tempo

    Jak to řešíme

    Podklady pro připojení, bezpečnostní doklady a testovací plány připravujeme včas a s provozovatelem platformy spolupracujeme od prvního týdne.

    Limity a závislosti

    Lhůty pro certifikaci a připojení určuje provozovatel, ne my. Plánujeme s nimi a řekneme vám, kde leží na kritické cestě.

  • Spotřebitelé s AI potřebují úzká API

    Jak to řešíme

    Agenti a asistenti dostávají vyhrazená API s omezeným rozsahem, limity a auditním logováním, ne stejně široký přístup jako interní služby.

    Limity a závislosti

    Zpřístupnění API agentovi přidává riziko. Každé takové API proto před spuštěním projdeme s vaším bezpečnostním týmem.

05 Jak pracujeme

Jak pracujeme

Nejdřív rozplétáme, potom stavíme, a každý tok předáme s vlastníkem.

  1. 01

    Zmapovat toky

    Každé rozhraní, jeho objem, historie selhání a vlastník z byznysu.

    VýstupMapa integrací a pořadí podle rizika

  2. 02

    Nastavit pravidla

    Zásady pro API, konvence událostí, model identity a volba platformy.

    VýstupIntegrační zásady a záznamy rozhodnutí

  3. 03

    Přesouvat tok po toku

    Nejrizikovější toky jako první, s odsouhlasením běžícím vedle starého rozhraní, dokud čísla nesedí.

    VýstupPřevedené toky s doklady o odsouhlasení

  4. 04

    Provozovat viditelně

    Dashboardy pro každý obchodní proces a chybové fronty s určenými vlastníky.

    VýstupMapa vlastníků toků a dashboardy

06 Kontrola člověkem

Kde rozhoduje člověk

Integrace běží bez obsluhy. Odpovědnost za to, co se pokazí, ale bez lidí nefunguje.

  • Každá chybová fronta má vlastníka

    Neúspěšné zprávy jdou týmu, který za ně odpovídá, s kontextem a tlačítkem pro přehrání, ne do sdíleného logu.

  • Změny kontraktů se revidují

    Nezpětně kompatibilní změny API nebo událostí projdou před zveřejněním revizí se spotřebiteli.

  • Přehrání je vědomý krok

    Přehrání zpráv do evidenčního systému je oprávněná akce, zaznamenaná včetně toho, kdo ji provedl a proč.

07 Technologie

Technologie, se kterými pracujeme

Integrační platformy
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Integrační služby AWS a Google Cloud
Události a streamování
  • Apache Kafka
  • RabbitMQ
  • Cloudové brokery událostí
  • Debezium pro zachytávání změn
API
  • OpenAPI a AsyncAPI
  • Brány API a vývojářské portály
  • GraphQL tam, kde se hodí
  • Kontraktové testy
Identita
  • OAuth 2.0 a OpenID Connect
  • Vzájemné TLS
  • Keycloak a cloudoví poskytovatelé identit
  • Národní schémata eID

Uvedení technologie popisuje naše inženýrské zkušenosti. Neznamená partnerství s jejím dodavatelem ani jeho doporučení.

08 Příklad

Ilustrativní příklad

Ilustrativní příklad

E-faktury veřejným zadavatelům přímo z ERP

01Situace
Výrobce stavebních prvků fakturuje krajům, obcím a jejich příspěvkovým organizacím. Faktury odcházejí jako PDF e-mailem, část zadavatelů chce ISDOC a faktury se vracejí kvůli chybějícím údajům, například číslu objednávky.
02Co bychom postavili
Integrace z ERP, která z faktury vytvoří e-fakturu podle EN 16931 ve formátu ISDOC nebo Peppol BIS podle dohody se zákazníkem, před odesláním ověří povinné údaje a sleduje doručení.
03Kde rozhoduje člověk
Účtárna schvaluje faktury, které neprojdou kontrolou; mapování polí pro každého zákazníka schvaluje vedoucí účetnictví.
04Co bychom měřili
Podíl faktur vrácených zadavatelem, doba od vystavení po doručení a čas strávený opravami.

09 Podle odvětví

Ve vašem odvětví

  • Veřejná správa

    Výměna údajů podle zásady „pouze jednou“, přihlášení přes Identitu občana a logování, které národní platformy vyžadují. Více o naší práci pro veřejnou správu.

  • Průmysl a výroba

    ERP, MES a dodavatelské portály propojené přes události, aby plánování, výroba i servis viděly stejný obraz.

  • Finanční služby

    Klíčové systémy, CRM a API partnerů propojené se silnou identitou, auditním logováním a odsouhlasením, kterému finanční útvar věří.

Česko

Propojení s českou veřejnou správou i za hranicemi

Digitální služby veřejné správy v Česku stojí na Identitě občana, datových schránkách a základních registrech, za které odpovídá Digitální a informační agentura (DIA), a rámuje je zákon č. 12/2020 Sb., o právu na digitální služby. Veřejní zadavatelé musí přijímat e-faktury podle normy EN 16931. Na úrovni EU přináší eIDAS 2 evropskou peněženku digitální identity, kterou má zpřístupnit každý členský stát, a nařízení o interoperabilní Evropě žádá po veřejných institucích posouzení přeshraniční interoperability.

Integrační vrstvy navrhujeme tak, aby národní výměny dat, schémata identity a formáty e-faktur byly adaptéry za stabilními interními kontrakty. Nové napojení nebo nová země pak znamená přidat adaptér a projít připojením, ne přestavovat systémy za ním.

Časté dotazy k integracím a API

Máme použít integrační platformu, nebo stavět integrace na míru?

Obojí, pro různé toky. Standardní konektory, mapování a připojování partnerů mluví pro platformu. Objemné toky, toky citlivé na latenci nebo toky se složitou logikou často mluví pro vlastní služby. Rozhodujeme pro každý tok zvlášť a zapisujeme proč.

Integrujete Salesforce, SAP a Odoo?

Ano, pravidelně, navzájem i se systémy na míru a systémy veřejné správy. Společnost FromNine má partnerský status u všech tří: Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner. Naše integrační týmy proto pracují bok po boku s platformními specialisty. Viz naše integrační práce pro SAP.

Potřebujeme integraci řízenou událostmi?

Události pomohou, když na stejnou změnu musí reagovat více systémů nebo když potřebujete oddělit cykly vydávání. Pro jednoduchý požadavek a odpověď mezi dvěma systémy často stačí API. Většina prostředí používá obojí.

Umíte integrovat národní schémata eID?

Ano. Napojujeme Identitu občana i schémata elektronické identity dalších zemí a navrhujeme s ohledem na evropské peněženky digitální identity, které mají členské státy podle eIDAS 2 zpřístupnit do 24. prosince 2026. Požadavky na připojení se u jednotlivých schémat liší, proto s nimi počítáme od začátku.

Umíte posílat e-faktury veřejným zadavatelům ve formátu ISDOC?

Ano. Veřejní zadavatelé v Česku musí podle § 221 zákona č. 134/2016 Sb., o zadávání veřejných zakázek, přijímat elektronické faktury podle normy EN 16931, například ve formátu ISDOC, UBL nebo Peppol BIS; dodavatelé je zasílat nemusí. Napojíme vaše ERP tak, aby faktury odcházely ve formátu dohodnutém se zákazníkem, úplné a zkontrolované, a schválení zůstalo u vaší účtárny. Povinnost e-fakturace mezi firmami v Česku pro rok 2026 platná ani oznámená není.

Přineste rozhraní, které selhává nejčastěji

Ukážeme, jak bychom ho udělali sledovatelné, idempotentní a s vlastníkem, a co by stálo udělat totéž se zbytkem.

Domluvit konzultaciAsistence v klientské péči