Към основното съдържание
FromNine
Меню

Разработка

Интеграции, които движат данните и показват, когато спрат.

Свързваме CRM, ERP, системи за преписки и държавни платформи чрез договори, събития и правилно изградена идентичност, така че данните да се движат надеждно, грешките да са видими, а нови възможности, включително AI, да се включват безопасно.

За организации, които свързват системи, партньори и публични платформи в повече от една държава членка.

Обсъдете проекта сиВижте платформите
Интеграции и API: слоеве на услугатаЧетири слоя, наредени един зад друг. Отгоре надолу: потребителите на данни като портали, приложения и агенти, API шлюзът с управлението на идентичността, гръбнакът за събития и отдолу основните системи, в които се водят данните.01Портали, приложения и агенти02API шлюз и идентичност03Гръбнак за събития04Основни системи
  1. 01API, проектирани първо като договор с OpenAPI и AsyncAPI, с версии и документация
  2. 02Събития с гарантирана последователност, идемпотентност, опашка за неуспешни съобщения и повторно изпращане
  3. 03Потоци, наблюдавани от край до край, и опашки с грешки, за които отговарят конкретни екипи

01 Проблеми

Проблеми с интеграцията, за които ни търсят

  1. 01

    Директни връзки, които никой не смее да промени

    Десетки директни връзки между CRM, ERP и системи по поръчка. Промяната на едно поле означава тестване на десет интерфейса.

  2. 02

    Дубликати и тихи откази

    Повторен опит създава втора поръчка. Неуспешно съобщение изчезва. Хората в бизнеса научават за това от клиентите.

  3. 03

    Всеки нов канал означава нова интеграционна работа

    Порталът, мобилното приложение, а сега и AI асистентът се нуждаят от едни и същи данни, и всеки получава собствено извлечение.

  4. 04

    Връзките с държавни системи са отделен проект

    Свързването с национална платформа за обмен на данни или със система за електронна идентификация всеки път отнема месеци работа по сигурността и включването.

02 Какво доставяме

Какво доставяме

  1. 01 API стратегия и управление

    Проектиране, при което API идва първо, с договори в OpenAPI и AsyncAPI, правила за версиите, шлюз, който ги налага, и портал за разработчици, така че екипите да намират и използват повторно това, което вече съществува.

    Какво правим

    • Карта на API и отговорниците за тях
    • Указания за проектиране и процес за преглед
    • Правила в шлюза за сигурност, квоти и версии
    • Портал за разработчици и каталог на API

    Какво получавате

    • Указания за API, приети от екипите Ви
    • Конфигурация на шлюза като код
    • Каталог на документираните API

  2. 02 Интеграция чрез събития

    Брокери на съобщения, улавяне на промени в данните и шаблонът outbox, с подробностите, които решават дали всичко работи: последователност, идемпотентни получатели, опашка за неуспешни съобщения и повторно изпращане.

    Какво правим

    • Модел на събитията и правила за именуване
    • Outbox и улавяне на промени в системите източници
    • Идемпотентност на получателите и гаранции за последователността
    • Опашки за неуспешни съобщения с инструменти за повторно изпращане

    Какво получавате

    • Гръбнак за събития в експлоатация
    • Регистър на схемите и правила за съвместимост
    • Ръководство за повторно изпращане и възстановяване

  3. 03 Интеграционни платформи, избрани за всеки поток

    SAP Integration Suite, MuleSoft и вградените интеграционни услуги на облачните платформи имат своето място. Казваме Ви кога iPaaS е по-добър от софтуер по поръчка и кога не е.

    Какво правим

    • Оценка на съществуващия междинен софтуер
    • Избор на платформа с общата цена на притежание
    • Съпоставяния и конектори за многократна употреба
    • Миграция от стар междинен софтуер

    Какво получавате

    • Запис на решението за интеграционна платформа
    • Библиотека с интеграционни шаблони
    • План за миграция на съществуващите интерфейси

  4. 04 Идентичност и доверие между системите

    OAuth 2.0 и OpenID Connect, взаимен TLS, идентичност между услугите и интеграция с националните средства за електронна идентификация на граждани и фирми в различни държави от ЕС, като itsme, DigiD и eHerkenning, BundID, FranceConnect, Cl@ve, SPID и CIE, както и с квалифициран електронен подпис (КЕП).

    Какво правим

    • Архитектура на идентичността за потребители и услуги
    • Проектиране на токени, обхвати и съгласия
    • Подкрепа при включването и сертифицирането за електронна идентификация
    • Подготовка за европейските портфейли за цифрова самоличност

    Какво получавате

    • Проект на идентичността и модел на заплахите
    • Работеща интеграция с електронна идентификация
    • Идентичност на услугите и ротация на тайните

  5. 05 Оперативна съвместимост с държавни системи

    Връзки с национални платформи за обмен на данни, например Federal Service Bus и MAGDA в Белгия, Digikoppeling и Common Ground в Нидерландия, стандартите XÖV и FIT-Connect в Германия, PDND в Италия и API Entreprise във Франция, както и с техническата система на ЕС по принципа „само веднъж“. В България връзките с регистрите на администрацията следват изискванията за оперативна съвместимост на Закона за електронното управление.

    Какво правим

    • Включване съвместно с оператора на платформата
    • Съпоставяне с националните стандарти за данни
    • Изискванията за сигурност и журнали на всяка платформа за обмен
    • Проектиране на обмена на доказателства при еднократно предоставяне на данни

    Какво получавате

    • Сертифицирана връзка с платформата за обмен
    • Документация на съпоставянията
    • Оперативни процедури, уговорени с оператора

  6. 06 Оперативна видимост за бизнеса

    Наблюдение на потоците, което хората в бизнеса могат да разчетат, съгласуване между системите и опашки с грешки, за които някой отговаря и които се обработват.

    Какво правим

    • Наблюдение на потоците на бизнес ниво
    • Доклади за съгласуване между системите
    • Класифициране и насочване на грешките
    • Известия до отговорника за всеки поток

    Какво получавате

    • Табло за интеграциите за всеки бизнес процес
    • Проверки за съгласуване в експлоатация
    • Карта на отговорниците за всяка опашка с грешки

03 Архитектура

Примерна референтна архитектура

От основните системи излизат два пътя. Синхронните заявки минават през системни API и шлюз, който проверява идентичността, обхватите и квотите. Промените се публикуват като събития чрез outbox или улавяне на промени, а получателите ги обработват идемпотентно.

Неуспешните съобщения попадат в опашка за неуспешни съобщения с възможност за повторно изпращане, а не в журнален файл. Лента за наблюдение показва всеки поток на езика на бизнеса, така че хората, които отговарят за даден процес, да виждат, когато той спре.

Слоеве в диаграмата

Основни системи
ERP, CRM и системите за преписки остават водещи за своите данни.
Синхронни API
Системни API с версии зад шлюз с OAuth 2.0, mTLS и квоти.
Събития
Outbox, брокер, опашка за неуспешни съобщения и съпоставяния в интеграционна платформа.
Потребители
Портали, приложения, агенти, партньори и платформи за обмен с държавни институции, с електронна идентификация, когато участват граждани.
Илюстративен пример

  1. Основни системи

    • ERP, CRM и системи за преписки

  2. Синхронни API

    • Системни API
    • API шлюз: OAuth 2.0, mTLS, квоти

  3. Събития

    • Outbox и улавяне на промени
    • Брокер на събития
    • Неуспешни съобщения и повторно изпращане
    • Съпоставяния в интеграционна платформа

  4. Потребители

    • Портали, приложения и агенти
    • Обмен с партньори и държавни системи
    • Идентичност: OIDC, mTLS, електронна идентификация

  5. Експлоатация

    • Наблюдение на потоците, съгласуване, опашки с грешки и отговорници
API и гръбнак за събития, един до друг

Примерна архитектура, а не система на клиент.

Прочетете диаграмата като текст

Основният маршрут води от основните системи през системни API с версии и API шлюз до портали, приложения и агенти.

Успоредно с това основните системи публикуват промените чрез outbox и улавяне на промени към брокер на събития, който ги доставя до платформите за обмен с партньори и държавни институции и до интеграционна платформа за съпоставянията. Неуспешните съобщения отиват в опашка за неуспешни съобщения с повторно изпращане. Услугите за идентичност с OAuth, mTLS и електронна идентификация защитават обмена с партньорите.

Лента за наблюдение отдолу показва състоянието на потоците, съгласуването и опашките с грешки и техните отговорници.

04 Съображения и ограничения

Инженерни съображения и ограничения

  • Доставката точно веднъж е въпрос на проектиране, а не на настройка

    Как го решаваме

    Приемаме, че съобщенията пристигат два пъти или в грешен ред, и проектираме получателите да са идемпотентни, с ключове и правила за последователността, уговорени за всеки вид събитие.

    Ограничения и зависимости

    Някои стари системи не могат да приемат ключове за идемпотентност или да отчетат какво са обработили. Около тях добавяме съгласуване, вместо да се преструваме.

  • iPaaS не винаги е отговорът

    Как го решаваме

    Платформите печелят при много стандартни конектори и съпоставяния. Услугите по поръчка печелят при сложна логика, големи обеми или строги изисквания за закъснение. Документираме избора за всяка интеграция.

    Ограничения и зависимости

    Лицензионните модели се променят. Платформа, която днес е евтина, може да стане най-големият разход в бюджета Ви за интеграции, затова моделираме разходите за няколко години.

  • Държавните платформи за обмен задават свое темпо

    Как го решаваме

    Подготвяме рано документите за включване, доказателствата за сигурност и плановете за тестване и работим с оператора на платформата от първата седмица.

    Ограничения и зависимости

    Сроковете за сертифициране и включване се определят от оператора, а не от нас. Планираме около тях и Ви казваме къде са на критичния път.

  • AI потребителите имат нужда от тесни API

    Как го решаваме

    Агентите и асистентите получават отделни API с ограничени права, лимити и одитни журнали, а не същия широк достъп като вътрешните услуги.

    Ограничения и зависимости

    Отварянето на API за агент добавя риск. Преглеждаме всяко такова API с отдела Ви по сигурност, преди да бъде пуснато.

05 Как работим

Как работим

Първо разплитаме, после изграждаме, и оставяме всеки поток с отговорник.

  1. 01

    Описваме потоците

    Всеки интерфейс, неговият обем, историята на отказите му и бизнес отговорникът за него.

    РезултатКарта на интеграциите и класиране по риск

  2. 02

    Определяме правилата

    Указания за API, правила за събитията, модел на идентичността и избор на платформа.

    РезултатУказания за интеграции и записани решения

  3. 03

    Преместваме поток по поток

    Първо най-рисковите потоци, със съгласуване успоредно със стария интерфейс, докато числата съвпаднат.

    РезултатПреместени потоци с доказателства от съгласуването

  4. 04

    Работим с пълна видимост

    Табла за всеки бизнес процес и опашки с грешки с посочени отговорници.

    РезултатКарта на отговорниците за потоците и табла

06 Човешки контрол

Къде контролът остава у хората

Интеграциите работят без надзор. Отговорността за грешките не може да остане без човек.

  • Всяка опашка с грешки има отговорник

    Неуспешните съобщения отиват при екип, който отговаря за тях, с контекст и бутон за повторно изпращане, а не в общ журнал.

  • Промените в договорите се преглеждат

    Несъвместимите промени в API или събития минават през преглед с потребителите им, преди да бъдат публикувани.

  • Повторното изпращане е съзнателно действие

    Повторното изпращане на съобщения към основна система е разрешено действие, което се записва с това кой го е направил и защо.

07 Технологии

Технологии, с които работим

Интеграционни платформи
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Интеграционни услуги на AWS и Google Cloud
Събития и поточни данни
  • Apache Kafka
  • RabbitMQ
  • Облачни брокери на събития
  • Debezium за улавяне на промени в данните
API
  • OpenAPI и AsyncAPI
  • API шлюзове и портали за разработчици
  • GraphQL, където е подходящ
  • Договорни тестове
Идентичност
  • OAuth 2.0 и OpenID Connect
  • Взаимен TLS
  • Keycloak и облачни системи за управление на идентичността
  • Национални системи за електронна идентификация

Посочването на технология описва инженерния ни опит. То не означава партньорство с нейния производител или одобрение от него.

08 Пример

Илюстративен пример

Илюстративен пример

ERP система, подготвена за структурирани електронни фактури

01Ситуация
Дистрибутор изпраща фактури на публични възложители по EN 16931, но чрез ръчно експортиране от ERP системата, а фактурите към фирми излизат като PDF по имейл. Законопроектът от 5 ноември 2026 г. предвижда структурирани електронни фактури от 1 юли 2028 г., ако бъде приет.
02Какво бихме изградили
Слой за фактуриране зад стабилен вътрешен договор, който създава фактури в UBL 2.1 или CII по EN 16931, изпраща ги днес до възложителите и може да получи адаптер към бъдещата мрежа, без ERP системата да се променя отново.
03Къде решават хората
Финансовият отдел одобрява съпоставянето на полетата и тестовите фактури; отхвърлените фактури отиват в опашка с посочен отговорник.
04Какво бихме измервали
Дял на фактурите, изпратени без ръчна намеса, брой отхвърлени фактури и време от издаването до потвърждението за получаване.

09 По сектори

Във Вашия сектор

  • Публичен сектор

    Еднократно предоставяне на данни чрез обмен с официалните регистри, електронна идентификация за граждани и фирми и журналите, които изискват държавните платформи. Повече за работата ни: Публичен сектор.

  • Производство и индустрия

    ERP, MES и портали за доставчици, свързани чрез събития, така че планирането, производството и сервизът да работят с една и съща картина.

  • Финансови услуги

    Основни системи, CRM и API за партньори, свързани със силна идентичност, одитни журнали и съгласуване, на което финансовият отдел вярва.

България

Оперативна съвместимост между държавите членки

Трансграничните услуги се сблъскват с различна национална платформа за обмен на данни, система за електронна идентификация и стандарт за данни във всяка държава. Актът за оперативно съвместима Европа изисква от публичните институции да оценяват трансграничната оперативна съвместимост, а eIDAS 2 въвежда европейски портфейли за цифрова самоличност, които всяка държава членка трябва да предостави.

В България възложителите приемат и обработват електронни фактури по европейския стандарт EN 16931 от 1 ноември 2019 г. Законопроект, внесен в Народното събрание на 5 ноември 2026 г., предвижда структурирани електронни фактури от 1 юли 2028 г., обменяни през мрежа на основата на CEF eDelivery AS4; той още не е приет. Свързаните системи на администрацията следват изискванията за оперативна съвместимост на Закона за електронното управление.

Проектираме интеграционни слоеве, в които националните платформи за обмен и системите за идентификация са адаптери зад стабилни вътрешни договори. Добавянето на държава или на нов формат на фактурите тогава означава нов адаптер и включването му, а не преработка на системите зад него.

Въпроси за интеграциите и API

Да използваме ли интеграционна платформа или интеграции по поръчка?

И двете, за различни потоци. Стандартните конектори, съпоставяния и включването на партньори са по-подходящи за платформа. Потоците с големи обеми, чувствителни към закъснение или с много логика често са по-подходящи за услуги по поръчка. Решаваме за всеки поток и документираме защо.

Интегрирате ли Salesforce, SAP и Odoo?

Да, редовно, помежду им и със системи по поръчка и държавни системи. FromNine има партньорски статут и при трите (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), така че интеграционните ни екипи работят заедно със специалисти по платформите. Вижте и работата ни със SAP.

Нужна ли ни е интеграция чрез събития?

Когато няколко системи трябва да реагират на една и съща промяна или когато искате да разделите циклите на новите версии, събитията помагат. За обикновена заявка и отговор между две системи често е достатъчно API. В повечето среди се използват и двете.

Можете ли да интегрирате национални системи за електронна идентификация?

Да. Интегрираме системи за електронна идентификация на граждани и фирми и проектираме с оглед на европейските портфейли за цифрова самоличност, които държавите членки трябва да предоставят по eIDAS 2 до 24 декември 2026 г. Изискванията за включване се различават при всяка система и ги планираме рано.

Имаме стар междинен софтуер. Трябва ли да го заменим?

Не наведнъж. Описваме какво работи на него, преместваме първо най-рисковите или най-скъпите потоци и поддържаме съгласуване, докато всеки преместен поток се докаже.

Покажете ни интерфейса, който отказва най-често

Ще покажем как бихме го направили наблюдаем, идемпотентен и с отговорник и какво би било нужно, за да направим същото за останалите.

Обсъдете проекта сиОбслужване на клиенти