Przejdź do treści głównej
FromNine
Menu

Inżynieria

Integracje, które utrzymują przepływ danych i pokazują, gdy się zatrzyma.

Łączymy systemy CRM, ERP, systemy obsługi spraw i platformy publiczne, takie jak KSeF, za pomocą kontraktów, zdarzeń i dobrze zaprojektowanej tożsamości. Dane płyną niezawodnie, błędy są widoczne, a nowe funkcje, w tym AI, można bezpiecznie podłączać.

Dla organizacji w Polsce, które łączą systemy, partnerów i platformy publiczne, od KSeF po logowanie przez login.gov.pl.

Porozmawiajmy o projekciePrzegląd platform
Integracje i API: warstwy kompetencjiCztery warstwy ułożone jedna za drugą. Od góry do dołu: odbiorcy, tacy jak portale, aplikacje i agenci, brama API z tożsamością, szkielet zdarzeń oraz systemy źródłowe pod spodem.01Portale, aplikacje i agenci02Brama API i tożsamość03Szkielet zdarzeń04Systemy źródłowe
  1. 01API projektowane od kontraktu, z OpenAPI i AsyncAPI, wersjonowane i udokumentowane
  2. 02Zdarzenia z zachowaniem kolejności, idempotencją, obsługą komunikatów nieobsłużonych i ponownym odtworzeniem
  3. 03Przepływy monitorowane od początku do końca, kolejki błędów przypisane do wskazanych zespołów

01 Problemy

Problemy z integracją, z którymi się do nas zwracają

  1. 01

    Połączenia punkt do punktu, których nikt nie odważy się zmienić

    Dziesiątki bezpośrednich połączeń między CRM, ERP i systemami na zamówienie. Zmiana jednego pola oznacza testowanie dziesięciu interfejsów.

  2. 02

    Duplikaty i ciche awarie

    Ponowienie tworzy drugie zamówienie. Nieudany komunikat znika. Użytkownicy biznesowi dowiadują się o tym od klientów.

  3. 03

    Każdy nowy kanał to nowa praca integracyjna

    Portal, aplikacja mobilna, a teraz asystent AI potrzebują tych samych danych i każdy dostaje własny eksport.

  4. 04

    Połączenie z platformą publiczną to osobny projekt

    Podłączenie do KSeF, platformy PEF czy logowania przez login.gov.pl za każdym razem wymaga pracy nad bezpieczeństwem, testami i dokumentacją.

02 Co dostarczamy

Co dostarczamy

  1. 01 Strategia i zarządzanie API

    Projektowanie od API z kontraktami OpenAPI i AsyncAPI, polityka wersjonowania, brama, która ją egzekwuje, i portal deweloperski, dzięki któremu zespoły znajdują i ponownie wykorzystują to, co już istnieje.

    Co robimy

    • Mapa API i odpowiedzialności za nie
    • Wytyczne projektowe i proces przeglądu
    • Polityki bramy dla bezpieczeństwa, limitów i wersjonowania
    • Portal deweloperski i katalog API

    Co Państwo otrzymują

    • Wytyczne API przyjęte przez zespoły organizacji
    • Konfiguracja bramy zapisana jako kod
    • Katalog udokumentowanych API

  2. 02 Integracja oparta na zdarzeniach

    Brokery, przechwytywanie zmian i wzorzec outbox, ze szczegółami, od których zależy, czy to działa: kolejnością, idempotentnymi odbiorcami, obsługą komunikatów nieobsłużonych i ponownym odtworzeniem.

    Co robimy

    • Model zdarzeń i konwencje nazewnictwa
    • Outbox i CDC w systemach źródłowych
    • Idempotencja odbiorców i gwarancje kolejności
    • Kolejki komunikatów nieobsłużonych (dead-letter) z narzędziami do odtwarzania

    Co Państwo otrzymują

    • Szkielet zdarzeń w produkcji
    • Rejestr schematów i reguły zgodności
    • Instrukcja odtwarzania i przywracania

  3. 03 Platformy integracyjne dobierane do przepływu

    SAP Integration Suite, MuleSoft i natywne usługi integracyjne chmury mają swoje miejsce. Mówimy wprost, kiedy iPaaS jest lepszy od kodu na zamówienie, a kiedy nie.

    Co robimy

    • Ocena istniejącego middleware
    • Wybór platformy z całkowitym kosztem posiadania
    • Mapowania i konektory wielokrotnego użytku
    • Migracja ze starszego middleware

    Co Państwo otrzymują

    • Zapis decyzji o platformie integracyjnej
    • Biblioteka wzorców integracyjnych
    • Plan migracji istniejących interfejsów

  4. 04 Tożsamość i zaufanie między systemami

    OAuth 2.0 i OpenID Connect, wzajemne uwierzytelnianie TLS, tożsamość usług oraz integracja z logowaniem obywateli i firm: przez Krajowy Węzeł Identyfikacji Elektronicznej (login.gov.pl) aplikacją mObywatel, przez bankowość elektroniczną, e-dowodem lub profilem zaufanym, a także z krajowymi systemami eID innych państw członkowskich.

    Co robimy

    • Architektura tożsamości dla użytkowników i usług
    • Projekt tokenów, zakresów uprawnień i zgód
    • Wsparcie w podłączeniu do systemów eID i ich wymaganiach
    • Przygotowanie do europejskich portfeli tożsamości cyfrowej

    Co Państwo otrzymują

    • Projekt tożsamości i model zagrożeń
    • Integracja eID w produkcji
    • Tożsamość usług i rotacja sekretów

  5. 05 Interoperacyjność z platformami publicznymi

    Połączenia z krajowymi platformami: Krajowym Systemem e-Faktur (KSeF) do wystawiania i odbierania faktur ustrukturyzowanych, Platformą Elektronicznego Fakturowania (PEF) dla faktur do zamawiających publicznych i logowaniem przez login.gov.pl, a także z platformami wymiany danych innych państw członkowskich i z unijnym systemem technicznym opartym na zasadzie jednorazowości (OOTS).

    Co robimy

    • Przygotowanie podłączenia z operatorem platformy
    • Mapowanie na krajowe struktury i standardy danych
    • Wymagania bezpieczeństwa i logowania każdej platformy
    • Projekt wymiany dowodów zgodnie z zasadą jednorazowości

    Co Państwo otrzymują

    • Przetestowane połączenie z platformą
    • Dokumentacja mapowań
    • Procedury operacyjne uzgodnione z operatorem

  6. 06 Widoczność działania dla użytkowników biznesowych

    Monitorowanie przepływów czytelne dla biznesu, uzgadnianie danych między systemami i kolejki błędów, za które ktoś odpowiada i które ktoś obsługuje.

    Co robimy

    • Monitorowanie przepływów na poziomie biznesowym
    • Raporty uzgodnień między systemami
    • Klasyfikacja i kierowanie błędów
    • Alerty dla właściciela każdego przepływu

    Co Państwo otrzymują

    • Pulpit integracji dla każdego procesu biznesowego
    • Kontrole uzgodnień w produkcji
    • Mapa odpowiedzialności za każdą kolejkę błędów

03 Architektura

Poglądowa architektura referencyjna

Z systemów źródłowych wychodzą dwie ścieżki. Zapytania synchroniczne przechodzą przez API systemów i bramę, która sprawdza tożsamość, zakresy uprawnień i limity. Zmiany są publikowane jako zdarzenia przez outbox lub przechwytywanie zmian, a odbiorcy przetwarzają je idempotentnie.

Nieudane komunikaty trafiają do kolejki komunikatów nieobsłużonych z możliwością odtworzenia, a nie do pliku logu. Pas monitorowania pokazuje każdy przepływ w kategoriach biznesowych, więc osoby odpowiedzialne za proces widzą, kiedy się zatrzymuje.

Warstwy na rysunku

Systemy źródłowe
ERP, CRM i systemy obsługi spraw pozostają nadrzędnym źródłem swoich danych.
API synchroniczne
Wersjonowane API systemów za bramą z OAuth 2.0, mTLS i limitami.
Zdarzenia
Outbox, broker, kolejka komunikatów nieobsłużonych i mapowania platformy integracyjnej.
Odbiorcy
Portale, aplikacje, agenci, partnerzy i platformy publiczne, z eID tam, gdzie uczestniczą obywatele.
Przykład poglądowy

  1. Systemy źródłowe

    • ERP, CRM i systemy obsługi spraw

  2. API synchroniczne

    • API systemów
    • Brama API: OAuth 2.0, mTLS, limity

  3. Zdarzenia

    • Outbox i CDC
    • Broker zdarzeń
    • Komunikaty nieobsłużone i odtwarzanie
    • Mapowania platformy integracyjnej

  4. Odbiorcy

    • Portale, aplikacje i agenci
    • Wymiana z partnerami i platformami publicznymi
    • Tożsamość: OIDC, mTLS, eID

  5. Utrzymanie

    • Monitorowanie przepływów, uzgodnienia, kolejki błędów z właścicielami
API i szkielet zdarzeń obok siebie

Architektura poglądowa, nie system klienta.

Diagram w formie tekstu

Główna ścieżka prowadzi od systemów źródłowych przez wersjonowane API systemów i bramę API do portali, aplikacji i agentów.

Równolegle systemy źródłowe publikują zmiany przez outbox i przechwytywanie zmian do brokera zdarzeń, który dostarcza je do wymiany z partnerami i platformami publicznymi oraz do platformy integracyjnej z mapowaniami. Nieudane komunikaty trafiają do kolejki komunikatów nieobsłużonych z odtwarzaniem. Usługi tożsamości z OAuth, mTLS i eID zabezpieczają wymianę z partnerami.

Pas monitorowania pod spodem pokazuje stan przepływów, uzgodnienia i kolejki błędów z właścicielami.

04 Uwarunkowania i ograniczenia

Uwarunkowania inżynierskie i ograniczenia

  • Przetwarzanie dokładnie raz to projekt, a nie ustawienie

    Jak do tego podchodzimy

    Zakładamy, że komunikaty dotrą dwa razy lub w złej kolejności, i projektujemy idempotentnych odbiorców, z kluczami i regułami kolejności uzgodnionymi dla każdego typu zdarzenia.

    Ograniczenia i zależności

    Niektóre starsze systemy nie przyjmują kluczy idempotencji ani nie raportują, co przetworzyły. Wokół nich dodajemy uzgadnianie danych, zamiast udawać, że problemu nie ma.

  • iPaaS nie zawsze jest odpowiedzią

    Jak do tego podchodzimy

    Platformy sprawdzają się przy wielu standardowych konektorach i mapowaniach. Usługi na zamówienie wygrywają przy złożonej logice, dużych wolumenach lub ścisłych wymaganiach dotyczących opóźnień. Wybór dokumentujemy dla każdej integracji.

    Ograniczenia i zależności

    Modele licencyjne się zmieniają. Platforma tania dziś może stać się największą pozycją w budżecie integracji, dlatego modelujemy koszty w perspektywie kilku lat.

  • Platformy publiczne mają własne tempo

    Jak do tego podchodzimy

    Wcześnie przygotowujemy dokumentację podłączenia, dowody bezpieczeństwa i plany testów i od pierwszego tygodnia współpracujemy z operatorem platformy.

    Ograniczenia i zależności

    Terminy testów i podłączenia ustala operator, a nie my. Planujemy wokół nich i pokazujemy, gdzie leżą na ścieżce krytycznej.

  • Odbiorcy AI potrzebują wąskich API

    Jak do tego podchodzimy

    Agenci i asystenci dostają dedykowane API o ograniczonym zakresie, z limitami i logowaniem audytowym, a nie tak szeroki dostęp jak usługi wewnętrzne.

    Ograniczenia i zależności

    Udostępnienie API agentowi zwiększa ryzyko. Każde takie API przeglądamy z zespołem bezpieczeństwa przed uruchomieniem.

05 Jak pracujemy

Jak pracujemy

Najpierw rozplątujemy, potem budujemy, a każdy przepływ zostawiamy z właścicielem.

  1. 01

    Mapa przepływów

    Każdy interfejs, jego wolumen, historia awarii i właściciel biznesowy.

    RezultatMapa integracji i ranking ryzyka

  2. 02

    Reguły

    Wytyczne API, konwencje zdarzeń, model tożsamości i wybór platformy.

    RezultatWytyczne integracyjne i zapisy decyzji

  3. 03

    Przepływ po przepływie

    Najpierw przepływy najbardziej ryzykowne, z uzgadnianiem danych obok starego interfejsu, dopóki liczby się nie zgadzają.

    RezultatPrzeniesione przepływy z dowodami uzgodnień

  4. 04

    Widoczne utrzymanie

    Pulpity dla każdego procesu biznesowego i kolejki błędów ze wskazanymi właścicielami.

    RezultatMapa odpowiedzialności za przepływy i pulpity

06 Kontrola człowieka

Gdzie kontrolę zachowuje człowiek

Integracja działa bez nadzoru. Odpowiedzialność za to, co pójdzie źle, już nie.

  • Każda kolejka błędów ma właściciela

    Nieudane komunikaty trafiają do zespołu, który za nie odpowiada, z kontekstem i przyciskiem ponownego odtworzenia, a nie do wspólnego logu.

  • Zmiany kontraktów są przeglądane

    Zmiany API lub zdarzeń, które łamią zgodność, przechodzą przegląd z odbiorcami przed publikacją.

  • Odtworzenia są świadome

    Ponowne wprowadzenie komunikatów do systemu źródłowego to działanie wymagające uprawnień, zapisywane wraz z informacją, kto je wykonał i dlaczego.

07 Technologie

Technologie, z którymi pracujemy

Platformy integracyjne
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Usługi integracyjne AWS i Google Cloud
Zdarzenia i strumienie
  • Apache Kafka
  • RabbitMQ
  • Chmurowe brokery zdarzeń
  • Debezium do przechwytywania zmian
API
  • OpenAPI i AsyncAPI
  • Bramy API i portale deweloperskie
  • GraphQL tam, gdzie pasuje
  • Testy kontraktowe
Tożsamość
  • OAuth 2.0 i OpenID Connect
  • Wzajemne uwierzytelnianie TLS
  • Keycloak i chmurowi dostawcy tożsamości
  • Krajowe systemy eID

Wymienienie technologii opisuje nasze doświadczenie inżynierskie. Nie oznacza partnerstwa z jej dostawcą ani jego rekomendacji.

08 Przykład

Przykład poglądowy

Przykład poglądowy

ERP połączony z KSeF i PEF u producenta sprzedającego firmom i samorządom

01Sytuacja
Producent urządzeń grzewczych sprzedaje hurtowniom, firmom instalacyjnym i jednostkom samorządu terytorialnego. Wysyłka faktur do KSeF działa przez dodatek do systemu ERP, a odrzucone faktury, korekty i faktury dla zamawiających publicznych dział księgowości obsługuje ręcznie, bez wspólnego widoku stanu.
02Co byśmy zbudowali
Warstwa integracji, która wysyła faktury ustrukturyzowane z ERP do KSeF i odbiera faktury zakupowe, wysyła faktury dla zamawiających publicznych przez PEF i pokazuje stan każdej faktury w jednym pulpicie z kolejką błędów.
03Gdzie decyduje człowiek
Dział księgowości zatwierdza korekty i ponowną wysyłkę odrzuconych faktur. Zmiany mapowań danych do struktury faktury zatwierdza kierownictwo działu księgowości.
04Co byśmy mierzyli
Odsetek faktur przyjętych za pierwszym razem, czas od wystawienia do potwierdzenia przyjęcia i liczba faktur obsługiwanych ręcznie.

09 Perspektywa branżowa

W Państwa branży

  • Administracja publiczna

    Wymiana danych zgodnie z zasadą jednorazowości, logowanie obywateli i firm przez login.gov.pl oraz logowanie zdarzeń, którego wymagają platformy krajowe. Więcej w opisie branży Administracja publiczna.

  • Przemysł i produkcja

    ERP, MES i portale dostawców połączone zdarzeniami, a faktury przez KSeF, dzięki czemu planowanie, produkcja i serwis widzą ten sam obraz.

  • Usługi finansowe

    Systemy podstawowe, CRM i API partnerów połączone z silną tożsamością, logowaniem audytowym i uzgodnieniami, którym ufa dział finansów.

Polska

KSeF, PEF i interoperacyjność w UE

Wystawianie faktur w Krajowym Systemie e-Faktur (KSeF) jest obowiązkowe od 1 lutego 2026 r. dla podatników, których sprzedaż w 2024 r. przekroczyła 200 mln zł, i od 1 kwietnia 2026 r. dla pozostałych. Odbieranie faktur przez KSeF jest obowiązkowe od 1 lutego 2026 r., a podatnicy ze sprzedażą udokumentowaną fakturami do 10 000 zł brutto miesięcznie mogą do końca 2026 r. wystawiać faktury poza KSeF.

Zamawiający publiczni mają obowiązek odbierać ustrukturyzowane faktury elektroniczne przesłane przez Platformę Elektronicznego Fakturowania (PEF), a dla wykonawcy wysyłka przez PEF jest dobrowolna. PEF obsługuje także sieć Peppol, a od 1 lutego 2026 r. KSeF i PEF są zintegrowane.

Na poziomie UE akt w sprawie Interoperacyjnej Europy wymaga od podmiotów publicznych oceny transgranicznej interoperacyjności, a eIDAS 2 wprowadza europejskie portfele tożsamości cyfrowej. Projektujemy warstwy integracji, w których krajowe platformy i systemy tożsamości są adapterami za stabilnymi kontraktami wewnętrznymi. Nowy kraj lub nowa platforma to nowy adapter, a nie przebudowa systemów za nim.

Pytania o integracje i API

Platforma integracyjna czy integracje na zamówienie?

Jedno i drugie, dla różnych przepływów. Standardowe konektory, mapowania i podłączanie partnerów przemawiają za platformą. Przepływy o dużym wolumenie, wrażliwe na opóźnienia lub z rozbudowaną logiką często lepiej realizować jako usługi na zamówienie. Decydujemy dla każdego przepływu i dokumentujemy dlaczego.

Czy FromNine integruje Salesforce, SAP i Odoo?

Tak, regularnie, ze sobą nawzajem, z systemami na zamówienie, z platformami publicznymi i z KSeF. FromNine ma status partnera wszystkich trzech platform (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), więc zespoły integracyjne pracują razem ze specjalistami platform. Przykłady integracji opisujemy na stronie SAP.

Czy potrzebujemy integracji opartej na zdarzeniach?

Zdarzenia pomagają, gdy kilka systemów musi reagować na tę samą zmianę albo gdy trzeba rozdzielić cykle wydań. Przy prostym zapytaniu i odpowiedzi między dwoma systemami często wystarczy API. Większość środowisk korzysta z obu podejść.

Czy można zintegrować krajowe systemy eID?

Tak. Integrujemy logowanie obywateli i firm, w Polsce przez login.gov.pl, oraz projektujemy z myślą o europejskich portfelach tożsamości cyfrowej, które państwa członkowskie mają udostępnić do 24 grudnia 2026 r. na podstawie eIDAS 2. Wymagania podłączenia różnią się między systemami, więc planujemy je wcześnie.

Mamy starsze middleware. Czy musimy je wymienić?

Nie od razu. Mapujemy, co na nim działa, najpierw przenosimy najbardziej ryzykowne lub najdroższe przepływy i utrzymujemy uzgadnianie danych, dopóki każdy przeniesiony przepływ się nie sprawdzi.

Interfejs, który zawodzi najczęściej

Pokażemy, jak sprawić, by był obserwowalny, idempotentny i miał właściciela, oraz czego wymagałoby to samo dla pozostałych.

Porozmawiajmy o projekcieWsparcie obsługi