EximeeBPMS jest rozwijane zgodnie z praktykami bezpieczeństwa stosowanymi w największych polskich bankach. Architektura platformy wspiera wymagania stawiane systemom o znaczeniu krytycznym, a zespół aktywnie monitoruje i eliminuje podatności w kolejnych wydaniach. Bezpieczeństwo jest jednym z głównych obszarów rozwoju produktu, a wszystkie wdrożenia realizowane są z zachowaniem bankowych standardów i procedur.

EximeeBPMS sysematycznie eliminuje podatności w ramach roadmapy bezpieczeństwa:

• Wydanie 1.1.1 było dedykowanym wydaniem security, usuwającym cztery podatności wysokiej istotności (CVE) w zależnościach, m.in. w Spring Framework, Spring Security i Apache Commons FileUpload.
• Wersja 1.3.0 wprowadza Script Guard – mechanizm blokujący wektory ataków RCE pochodzące z definicji procesów, egzekwowany zarówno podczas parsowania modeli BPMN, jak i w trakcie ich wykonywania – oraz mechanizm backpressure dla External Tasks, zwiększający odporność platformy na przeciążenia.

Począwszy od wydań po 1.3.0 każda poprawka bezpieczeństwa w changelogu cytuje identyfikator usuwanego CVE, co pozwala bankom jednoznacznie zweryfikować status podatności w procesach audytowych.

Bezpieczeństwo jest wbudowane w cykl wydawniczy EximeeBPMS. Zależności są w sposób ciągły skanowane pod kątem podatności, kod przechodzi analizę statyczną, a każdy publikowany obraz kontenerowy jest skanowany narzędziem Trivy – wykrycie podatności krytycznej blokuje publikację. Obrazy są podpisywane cyfrowo (cosign/Sigstore) i dostarczane z pełnym SBOM w formacie CycloneDX, a manifesty wdrożeniowe są automatycznie weryfikowane pod kątem zgodności z profilami bezpieczeństwa Kubernetes. Efekty prac nad bezpieczeństwem są jawnie dokumentowane w changelogu każdej wersji – m.in. wzmocnienie entropii identyfikatorów (UUID v7), konfigurowalne endpointy OAuth2 czy mechanizm Script Guard – a poprawki podatności cytują identyfikatory CVE. Zgłoszenia podatności przyjmowane są w trybie responsible disclosure zgodnie z opublikowaną polityką bezpieczeństwa projektu.

EximeeBPMS chroni dane w środowiskach on-premises i cloud-ready poprzez mechanizmy ochrony danych zgodne z praktykami sektora bankowego, obejmujące szyfrowanie komunikacji, izolację środowisk, kontrolę dostępu opartą na OAuth2/OIDC oraz architekturę zaprojektowaną tak, by spełniać wymagania systemów o znaczeniu krytycznym.

Dzięki temu platforma wspiera bezpieczne uwierzytelnianie, mapowanie użytkowników i grup, kontrolę dostępu oraz mechanizmy SSO/SSO logout, a także konfigurację tożsamości i autoryzacji zarówno w środowiskach on-premises, jak i cloud-ready.

Migracja z Camunda 7 do EximeeBPMS jest przewidywalna, ponieważ EximeeBPMS zachowuje pełną zgodność z BPMN 2.0, semantyką wykonawczą Camunda 7 oraz jej architekturą komponentów. Platforma korzysta z natywnego silnika BPMN 2.0 działającego w JVM, a jej moduły – REST API, Tasklist, Cockpit, Admin – są analogiczne do znanych z Camunda 7. Modele procesów działają bez zmian, a kod integracyjny jest dostosowywany automatycznie: skrypty migracyjne oparte na OpenRewrite przepisują zależności, pakiety i importy bez ręcznej refaktoryzacji logiki procesowej.

Punktem wyjścia migracji jest Camunda w wersji 7.23.0; projekty na starszych wersjach należy najpierw zaktualizować.

Od wersji 1.2.0 EximeeBPMS działa na Spring Boot 4.x – aplikacje korzystające ze starszych wersji Spring Boot wymagają standardowej migracji opisanej w przewodniku. Projektowanie procesów pozostaje możliwe w Camunda Modeler. 

Szczegółowy opis procesu migracji znajduje się w dokumentacji.

Tak, modele procesów BPMN stworzone dla Camunda 7 działają w EximeeBPMS bez żadnych modyfikacji, ponieważ platforma zachowuje pełną zgodność z semantyką BPMN 2.0 i mechaniką wykonawczą Camunda 7.

Zmianie podlega wyłącznie warstwa kodu aplikacyjnego (pakiety org.camunda → org.eximeebpms), którą w całości automatyzują dostarczane skrypty migracyjne. Logika procesowa nie wymaga zmian.

EximeeBPMS jest w pełni kompatybilny ze schematem bazy danych Camunda 7.23 – wersji, na której bazuje platforma. Migracja nie wymaga konwersji ani przenoszenia danych procesowych: istniejąca baza działa bez zmian.

Do wersji 1.3.0 EximeeBPMS nie wprowadził żadnych modyfikacji w strukturze bazy. Od wersji 1.3.0 jedyne zmiany to dodanie nowych tabel – m.in. na potrzeby funkcjonalności Script Guard – które nie naruszają ani nie modyfikują istniejących struktur. Projekty na starszych wersjach Camunda 7 należy przed migracją zaktualizować do 7.23.0, korzystając ze standardowych mechanizmów aktualizacji Camunda.

Migrację z Camunda 7 do EximeeBPMS wspierają zautomatyzowane narzędzia oparte na OpenRewrite oraz dedykowane skrypty migracyjne przygotowane przez EximeeBPMS. Proces migracji jest wykonywany za pomocą rewrite-maven-plugin, który automatycznie aktualizuje zależności, pakiety, importy oraz konfigurację projektu bez konieczności ręcznej refaktoryzacji kodu.

Najważniejsze narzędzia automatyzujące migrację:

• OpenRewrite – silnik refaktoryzacji kodu, który wykonuje transformacje na podstawie reguł YAML,
• rewrite-maven-plugin – plugin Maven uruchamiający reguły migracyjne,
• Skrypty migracyjne EximeeBPMS – gotowe recepty OpenRewrite przygotowane specjalnie do konwersji projektów Camunda 7 → EximeeBPMS,
• Konfiguracja migracyjna replace-camunda-with-eximeebpms.yml – zestaw reguł zmieniających zależności, pakiety, importy i typy.

Automatyzacja migracji minimalizuje ryzyko, skraca czas przejścia i pozwala zachować pełną zgodność z BPMN 2.0.

Dokładną instrukcję migracji znaleźć można w dokumentacji.

Tak, EximeeBPMS oficjalnie wspiera projektowanie procesów w Camunda Modeler dzięki zgodności z BPMN 2.0 oraz zachowaniu semantyki Camunda 7.

EximeeBPMS eliminuje dług technologiczny poprzez modernizację kluczowych komponentów platformy tak, aby działały na współczesnym, wspieranym i bezpiecznym stosie technologicznym. Obejmuje to pełną migrację backendu na Spring Boot 4.x / Spring Framework 7 oraz optymalizację działania silnika BPMN pod Java 21 LTS, co usuwa ograniczenia odziedziczone po Camunda 7 i pozwala na wieloletnie, bezpieczne utrzymanie platformy. Wsparcie kolejnych wersji Java LTS jest realizowane zgodnie z opublikowaną polityką wspierania środowisk.

EximeeBPMS wymaga Spring Boot 4.x, ponieważ platforma została zmodernizowana tak, aby działać na najnowszym, wspieranym i bezpiecznym stosie technologicznym, eliminując dług technologiczny odziedziczony po Camunda 7. Przejście na Spring Boot 4.x (i Spring Framework 7), wprowadzone w wydaniu 1.2.0, zapewnia zgodność z nowoczesnymi standardami bezpieczeństwa oraz pełną optymalizację działania silnika BPMN na Java 21. Umożliwia to wieloletnie, bezpieczne utrzymanie platformy bez ryzyka wynikającego z przestarzałych bibliotek.

EximeeBPMS wspiera Java 11, 17 i 21. Kompatybilność jest weryfikowana w infrastrukturze QA projektu na Eclipse Temurin JDK. Platforma jest optymalizowana pod Java 21 LTS, co zapewnia długoterminowe wsparcie, przewidywalność audytową i dostęp do ulepszeń JVM w obszarach współbieżności, pamięci i bezpieczeństwa. Zgodnie z polityką wspierania środowisk, nowe wersje Java LTS (w tym Java 25) są obejmowane wsparciem w kolejnych wydaniach minor platformy.

EximeeBPMS wspiera nowoczesne, produkcyjne bazy danych zgodne z ekosystemem Camunda 7. Dzięki temu migracja projektów nie wymaga zmiany bazy danych ani konfiguracji transakcyjnych.

Wspierane bazy danych:

• MySQL 8.0 – w pełni wspierana w środowiskach produkcyjnych,
• Oracle 19c / 23ai – zgodna z wymaganiami dużych instytucji finansowych,
• IBM DB2 11.5 – z wyłączeniem IBM z/OS,
• PostgreSQL 14 / 15 / 16 / 17 – rekomendowana baza dla środowisk chmurowych,
• Amazon Aurora PostgreSQL – kompatybilna z PostgreSQL 14-16,
• Microsoft SQL Server 2017 / 2019 / 2022 – z dedykowanymi notami konfiguracyjnymi,
• Azure SQL – zgodnie z poziomami kompatybilności SQL Server wspieranymi przez EximeeBPMS,
• H2 2.3 – tylko do developmentu; niewskazana w trybie klastrowym.

Powyższą listę wspieranych baz oraz dodatkowe informacje znaleźć można w dokumentacji środowiskowej EximeeBPMS.

Tak. EximeeBPMS jest dostarczany jako lekkie obrazy kontenerowe i może być uruchamiany zarówno w Docker, jak i w Kubernetes/OpenShift. Oficjalne artefakty wdrożeniowe – Helm chart oraz Kustomize – są dostępne w repozytorium eximeebpms-k8s i umożliwiają szybkie uruchomienie środowiska Community Edition oraz konfiguracje produkcyjne.

Domyślne wdrożenie uruchamia pojedynczą replikę z wbudowaną bazą H2 (do celów demo). Dla środowisk produkcyjnych dostępne są gotowe konfiguracje high availability z PostgreSQL, autoscalingiem, PodDisruptionBudget, anti-affinity i dostosowanymi probe’ami.

Wszystkie manifesty spełniają wymagania profilu Pod Security Standards: Restricted oraz kontenerowych kontroli CIS Kubernetes Benchmark. Obrazy są skanowane (Trivy), podpisywane kluczem krótkotrwałym (cosign) i publikowane wraz z SBOM.

Platforma może być również uruchamiana lokalnie w Dockerze – wystarczy pobrać obraz z GHCR i uruchomić go poleceniem docker run. Ten sam obraz jest wykorzystywany w środowiskach Kubernetes/OpenShift.

Architektura cloud-ready EximeeBPMS opiera się na lekkich obrazach kontenerowych i oficjalnych artefaktach wdrożeniowych dla Kubernetes i OpenShift, dzięki czemu platforma działa zarówno on-premises, jak i w środowiskach kontenerowych oraz chmurowych. Modernizacja pod Spring Boot 4.x i Java 21 oraz oficjalne konfiguracje high availability umożliwiają wdrożenia z autoscalingiem (HPA), health checks, rolling updates i politykami odporności (PodDisruptionBudget, anti-affinity). Ten sam obraz może być uruchamiany lokalnie w Docker i produkcyjnie w Kubernetes, co upraszcza ścieżkę od developmentu do produkcji przy zachowaniu wymagań enterprise.

EximeeBPMS jest bezpieczną alternatywą dla Camunda 7 dzięki aktywnemu utrzymaniu platformy: regularnym wydaniom, systematycznemu eliminowaniu podatności (dokumentowanemu w changelogu wraz z identyfikatorami CVE) oraz dedykowanej roadmapie bezpieczeństwa. Dla organizacji wymagających gwarancji kontraktowych dostępny jest model Commercial Support obejmujący SLA i wydania Long-Term Support. Platforma jest rozwijana przez Consdata zgodnie z praktykami sektora bankowego, co eliminuje ryzyko związane z osieroconymi komponentami – problem typowy dla niewspieranej już Camunda 7 CE.

EximeeBPMS redukuje ryzyko wdrożeniowe na trzech poziomach:

• Ciągłość technologiczna: platforma zachowuje sprawdzoną w tysiącach wdrożeń semantykę Camunda 7, więc migracja nie zmienia zachowania procesów.
• Aktywne utrzymanie: regularne wydania, eliminacja podatności dokumentowana identyfikatorami CVE oraz mechanizmy zwiększające odporność na przeciążenia (backpressure dla External Tasks) i na złośliwy kod (Script Guard).
• Przejrzysty łańcuch dostaw: podpisane obrazy, SBOM i skanowanie każdego wydania.

Za platformą stoi Consdata – dostawca systemów procesowych dla największych polskich banków od ponad 10 lat – co zapewnia rozwój zgodny z wymaganiami środowisk o znaczeniu krytycznym.

EximeeBPMS oferuje dwa modele wsparcia: 

• Community Support – bezpłatny – obejmuje otwartą dokumentację, zgłoszenia przez GitHub oraz regularne wydania platformy.
• Commercial Support, świadczony przez Consdata, zapewnia SLA na błędy krytyczne i blokujące, priorytetową obsługę zgłoszeń, krytyczne poprawki bezpieczeństwa oraz wydania Long-Term Support (LTS).

Dzięki temu banki i instytucje finansowe otrzymują gwarantowane czasy reakcji i przewidywalne, regularne dostawy poprawek zgodne z praktykami sektora finansowego.

Banki i instytucje finansowe wybierają EximeeBPMS, ponieważ Camunda 7 CE nie jest już wspierana ani aktualizowana, co generuje realne ryzyka bezpieczeństwa i audytowe.
EximeeBPMS zapewnia aktywnie utrzymywaną platformę zgodną ze standardami bankowymi: ciągłe eliminowanie podatności dokumentowane identyfikatorami CVE, przewidywalne aktualizacje, brak długu technologicznego dzięki modernizacji stosu (Spring Boot 4.x, Java 21) oraz odpowiedzialnego dostawcę z wieloletnim doświadczeniem w sektorze finansowym. W efekcie instytucje otrzymują środowisko procesowe, które jest bezpieczne, rozwijane w sposób ciągły i zgodne z wymaganiami regulatorów.

EximeeBPMS wspiera audyty i zgodność regulacyjną poprzez artefakty, które można bezpośrednio przedstawić audytorowi:

• changelog dokumentujący poprawki bezpieczeństwa wraz z identyfikatorami CVE,
• SBOM (CycloneDX) publikowany z każdym obrazem,
• cyfrowo podpisane obrazy kontenerowe (cosign/Sigstore),
• manifesty wdrożeniowe spełniające profil Pod Security Standards „Restricted” i kontrole CIS Kubernetes Benchmark.

Platforma jest aktywnie utrzymywana i regularnie aktualizowana, co znacząco ułatwia spełnianie wymogów kontroli wewnętrznej i zewnętrznej w instytucjach nadzorowanych.

Tak. EximeeBPMS jest w pełni bezpłatny – zarówno do użytku komercyjnego, jak i niekomercyjnego – na licencji Apache 2.0, bez opłat licencyjnych i bez ograniczeń funkcjonalnych. Opcjonalnie dostępny jest płatny Commercial Support świadczony przez Consdata, obejmujący SLA, priorytetowe poprawki bezpieczeństwa i wydania Long-Term Support.

EximeeBPMS jest licencjonowany jako projekt open-source na licencji Apache License 2.0, co oznacza pełną swobodę użycia, modyfikacji, integracji i dystrybucji także w projektach komercyjnych.

EximeeBPMS jest w pełni open-source i udostępniany na licencji Apache 2.0, co daje swobodę korzystania, modyfikowania i dystrybucji także w projektach komercyjnych. Kod źródłowy jest publicznie dostępny w oficjalnym repozytorium GitHub, a dokumentacja oraz narzędzia towarzyszące są otwarte dla użytkowników.

Roadmapa EximeeBPMS opiera się na regularnych wydaniach, których celem jest eliminacja podatności oraz dostarczanie stabilnych, przewidywalnych aktualizacji zgodnych z wymaganiami banków. Wersje 1.2.0 (modernizacja stosu: Spring Boot 4.x) i 1.3.0 (Script Guard, backpressure, UUID v7) stanowią fundament modernizacji backendu. Kolejne wydania rozwijają architekturę zdarzeniową i observability (1.4.0, planowana na wrzesień 2026) oraz nowoczesny interfejs użytkownika (2.0, planowana na Q4 2026).

Szczegółowe informacje o wydaniach EximeeBPMS są dostępne w sekcji Release Notes dokumentacji.

Zgłoszenia błędów i propozycje nowych funkcji należy kierować przez oficjalny Issue Tracker na GitHub. Pytania, dyskusje i wymiana doświadczeń odbywają się w GitHub Discussions. Dla klientów Commercial Support dostępne są dodatkowo dedykowane kanały kontaktu objęte SLA.

EximeeBPMS wspiera procesy krytyczne dzięki takim kluczowym elementom, jak:

• Stabilność pod ekstremalnym obciążeniem – mechanizm Backpressure utrzymuje ciągłość działania nawet przy gwałtownych wzrostach ruchu,
• Architektura dla systemów krytycznych – modułowy, cloud-ready backend wspiera izolację obciążeń, skalowanie i wdrożenia on-premises oraz w chmurze,
• Bezpieczeństwo wykonania – Script Guard blokuje RCE w definicjach procesów, co jest kluczowe dla środowisk regulowanych,
• Nowoczesny stos technologiczny – Java 21 i Spring Boot 4.x zapewniają wieloletnie wsparcie, wysoką wydajność i zgodność z praktykami bankowymi,
• Separacja warstw – niezależny moduł REST API oraz odseparowana warstwa webowa (Cockpit, Tasklist, Admin) zapewniają większą odporność architektury i elastyczność wdrożeń,
• Gotowość kontenerowa – silnik BPMN jest natywnie przygotowany do pracy w JVM, Docker i Kubernetes.

Dzięki temu EximeeBPMS zapewnia ciągłość działania, odporność na skoki obciążenia, przewidywalność operacyjną oraz zgodność z praktykami bankowymi i wymaganiami audytowymi.

Wdrożenie EximeeBPMS w środowisku o wysokiej dostępności (HA) opiera się na praktykach stosowanych w bankach, takich jak: 

• Separacja komponentów – każdy moduł działa niezależnie, co zwiększa odporność i elastyczność,
• Wieloinstancyjność – silnik BPMN, REST API i UI mogą działać w wielu równoległych replikach,
• Gotowość kontenerowa – natywna praca w JVM, Docker i Kubernetes,
• Praktyki HA – zgodność z bankowymi standardami ciągłości działania.

Warstwa persystencji korzysta ze wspieranych baz transakcyjnych, a architektura EximeeBPMS pozwala na wdrożenia zgodne z praktykami HA/DR stosowanymi w instytucjach finansowych.

EximeeBPMS jest projektowany z myślą o środowiskach regulowanych, dlatego wspiera przewidywalność audytową, ciągłą mitygację podatności oraz zgodność z praktykami sektora finansowego (m.in. aktywne aktualizacje, eliminacja krytycznych CVE, modernizacja stosu technologicznego, kontrola wykonywania skryptów). Dzięki temu ułatwia spełnianie wymagań audytów zewnętrznych i nadzorczych.

EximeeBPMS radzi sobie z ekstremalnym obciążeniem transakcyjnym dzięki skalowalnej architekturze wykonawczej potwierdzonej w produkcji oraz pełnej optymalizacji pod Java 21, które zapewniają nowoczesne mechanizmy współbieżności, wydajną pracę JVM i stabilność LTS.

Kluczową rolę odgrywa ponadto inteligentny mechanizm Backpressure, który zapobiega przeciążeniu workerów i eliminuje błędy blokujące przetwarzanie, dzięki czemu silnik BPMN utrzymuje ciągłość działania nawet przy gwałtownych skokach ruchu. W efekcie platforma zachowuje wysoką przepustowość, przewidywalność operacyjną i odporność na obciążenia typowe dla procesów krytycznych w bankach.

EximeeBPMS posiada szereg cech i mechanizmów wspierających wybrane obszary odporności operacyjnej wymagane przez DORA, których zakres dotyczy głównie warstwy technicznej:

• Wysoka dostępność (HA) w obrębie jednego klastra – skalowanie, sondy zdrowia, replikacja bazy,
• Modularność i konteneryzacja – ułatwiają izolację komponentów i zarządzanie środowiskiem,
• Bezpieczeństwo wykonania – potwierdzone przez:
  • CodeQL (skanowanie Java + JavaScript),
  • Trivy (skanowanie obrazów Docker),
  • Dependabot (monitorowanie zależności Maven, npm, GitHub Actions).

• SBOM – generowany automatycznie w formacie CycloneDX i dostępny w repozytorium,
• Incident reporting – dostępne mechanizmy techniczne,
• Resilience testing – gotowe mechanizmy techniczne ułatwiające integrację z procesami testów odporności, w tym kontrolę zachowania komponentów w warunkach obciążenia i awarii,
• Governance dostawców ICT – transparentny łańcuch dostaw oprogramowania wspierający wymagania nadzoru nad dostawcami technologii.

EximeeBPMS to otwartoźródłowa platforma orkiestracji procesów biznesowych oparta na BPMN 2.0, rozwijana jako fork ostatniej stabilnej wersji Camunda 7. Zapewnia natywny silnik BPMN działający w JVM, REST API oraz aplikacje Cockpit, Tasklist i Admin. Platforma jest rozwijana przez Consdata z myślą o systemach o znaczeniu krytycznym – przede wszystkim w bankowości i finansach – i udostępniana na licencji Apache 2.0. Firmy korzystające z Camunda 7 mogą przejść na EximeeBPMS bez zmiany modeli procesów i bez migracji bazy danych.

Camunda 8 to platforma o całkowicie nowej architekturze (silnik Zeebe), niekompatybilna z Camunda 7 – przejście na nią wymaga przebudowy procesów, integracji i infrastruktury. EximeeBPMS zachowuje architekturę, semantykę wykonawczą i schemat bazy danych Camunda 7, dzięki czemu organizacje używające Camunda 7 mogą dalej rozwijać swoje systemy bez kosztownej migracji – na zmodernizowanym stosie technologicznym (Spring Boot 4.x, Java 21) i z aktywnym usuwaniem podatności.

EximeeBPMS jest w całości rozwijany i utrzymywany przez Consdata S.A. – polską firmę technologiczną z ponad 10-letnim doświadczeniem w budowie systemów procesowych dla sektora bankowego, w tym rozwiązań wykorzystywanych przez największe banki w Polsce. Consdata odpowiada za roadmapę, wydania i bezpieczeństwo platformy, a kod źródłowy jest publicznie dostępny na GitHub.