The form has been successfully submitted.
Please find further information in your mailbox.
Select language
In today’s digitally driven world, maintaining a competitive edge requires streamlined and efficient business processes. Automation stands out as a key solution to achieving this. According to Statista, the business process management (BPM) market ma osiągnąć wartość 14,4 miliarda dolarów amerykańskich do 2025 roku. Rosnąca popularność i zapotrzebowanie na narzędzia BPM, takie jak Camunda, znana ze swojej elastyczności i skalowalności, świadczy o tym trendzie. W miarę jak firmy szukają niezawodnych narzędzi do optymalizacji swoich działań, Camunda wyłania się na czoło, torując drogę dla innowacyjnych, bezawaryjnych rozwiązań automatyzacyjnych w branży.
Mówiąc najprościej, Camunda to platforma open-source do automatyzacji przepływu pracy i decyzji, która łączy użytkowników biznesowych i twórców oprogramowania. Dzięki solidnemu zestawowi narzędzi i funkcji Camunda oferuje sposoby projektowania, wdrażania i optymalizacji przepływów pracy BPMN (Business Process Model and Notation), dzięki czemu operacje biznesowe są płynniejsze i bardziej przejrzyste.
Trzy kluczowe elementy zrewolucjonizowały zarządzanie procesami biznesowymi: Camunda, Spring Boot i BPMN. Każdy z nich wypracował swoje miejsce, oferując unikalne funkcjonalności, które adresują różne aspekty zarządzania procesami. Jednak w połączeniu stają się one niepowstrzymaną siłą, zdolną do zrewolucjonizowania cyfrowych operacji przedsiębiorstw.
Camunda: This isn’t just another tool in the vast BPM toolbox; it’s a standout. As a robust open-source platform, Camunda specializes in workflow and decision automation. Its primary objective? To seamlessly fuse the worlds of business strategists and software developers. By doing so, it ensures that the conceptualization, design, and implementation of business processes are efficient, transparent, and cohesive.
Spring Boot: Spring Boot wykorzystuje mocne strony frameworka Spring i podnosi je na wyższy poziom. Oferując usprawnioną metodę tworzenia samodzielnych aplikacji Java stał się ulubieńcem programistów, którzy chcą zminimalizować kod szablonowy i skupić się bezpośrednio na specyficznych funkcjonalnościach projektu. Jego siła tkwi w elastyczności i podejściu konwencji ponad konfiguracją, które propaguje inteligentne ustawienia domyślne. To podejście pozwala programistom na szybsze budowanie skalowalnych aplikacji, zapewniając terminową dostawę i spójną wydajność.
BPMN: Gdybyśmy mieli spersonifikować BPMN, byłby to elokwentny lingwista świata biznesu. Jako uznany na całym świecie standard, BPMN zapewnia wizualne słownictwo do tworzenia procesów biznesowych, dzięki czemu są one łatwo zrozumiałe dla szerokiego grona interesariuszy. Ten uniwersalny język zapewnia, że techniczne niuanse procesu są możliwe do rozszyfrowania zarówno przez obeznanego z technologią programistę, jak i stratega biznesowego, sprzyjając dialogowi opartemu na współpracy i podejmowaniu bardziej świadomych decyzji.
The synergy of Camunda’s automation capabilities, Spring Boot’s development ease, and BPMN’s standardized notation presents businesses with a dynamic trifecta. Together, they ensure that BPM schemes transition from mere theoretical constructs on paper to actionable, real-world implementations. The end goal? To cultivate business processes that are agile, resilient, and perfectly aligned with the evolving demands of the contemporary digital enterprise landscape.
Dla tych, którzy nie znają BPMN, zrozumienie jego podstawowych komponentów jest kluczowe. Te elementy stanowią fundament każdego diagramu BPMN.
Oznaczają one coś, co dzieje się podczas procesu. Zdarzenia mogą rozpoczynać, przerywać lub kończyć przepływ i często są reprezentowane jako okręgi.
Bramki obsługują podejmowanie decyzji w ramach procesu. W oparciu o warunki kontrolują przepływ procesu, zwykle przedstawianego jako diamenty.
Działania reprezentują wykonywaną pracę. Mogą to być zadania lub podprocesy i są wyświetlane jako zaokrąglone prostokąty.
Elementy te, w tym przepływy sekwencji, przepływy komunikatów i asocjacje, ilustrują sekwencję procesów i przepływ komunikatów.
Klasyfikują elementy BPMN według ról (np. menedżer, księgowy) lub systemów (np. system ERP).
Oferują one dodatkowe informacje o procesie. Typowe artefakty obejmują obiekty danych, grupy i adnotacje.
As with any technological solution, Camunda brings a mix of advantages and challenges. Here’s a comprehensive look into its pros and cons.
Camunda została zaprojektowana tak, aby programiści i analitycy mówili tym samym językiem, ale często rzeczywistość interweniuje.
Mikroserwisy zawodzą, użytkownicy wprowadzają nieprawidłowe dane, wszystko może się zdarzyć. W takim przypadku piękny diagram analityczny zaczyna być upiększany różnymi modułami obsługi błędów, rejestratorami i alternatywnymi ścieżkami. Analityk projektuje piękny, zwięzły i zrozumiały schemat. Ma on kilku delegatów i zapewnia logiczne ścieżki dla przepływu procesu w różnych okolicznościach. Tak wygląda tymczasowy schemat, gdy trafia w ręce dewelopera:
However, there are downsides. Such a scheme might contain a brief task description, like “check the client”, which implies several stages, decision-making based on each outcome, and compiling the derived decisions into a single result, possibly with the subsequent transfer of this result to external systems.
It’s clear that at this point, error handlers, loggers, and technical service elements appear on the diagram or in the code. This way, one “analytical” task in the Java implementation becomes voluminous and complex, or the number of steps on the scheme increases, each being accompanied by handlers and alternative pathways. As a result, the scheme quickly becomes convoluted, difficult for further support and modification, and adding new functionality might entail restructuring a vast area of both the scheme and the delegate code. In essence, it contains a massive number of identical elements.
Here’s how the previous scheme might look in a real deployment:
Oczywiście schemat został rozszerzony i stał się bardziej kłopotliwy. Są jednak zalety: wszystkie zadania stały się atomowe i pojawiły się gałęzie zachowań w przypadku błędów.
Jeśli spróbujemy oddzielić i enkapsulować schemat oraz logikę biznesową kodu Java, możemy zrobić następujące rzeczy:
Aby ułatwić pracę z produktem, lepiej zdekomponować schemat na zadania atomowe, zmniejszyć całkowitą liczbę elementów schematu, zmniejszyć liczbę obsługiwanych usług, zredukować objętość kodu Java w każdym delegacie oraz ponownie wykorzystywać uniwersalnych delegatów, prowadząc natychmiastowy refaktoring w razie potrzeby. Wszystko to automatycznie implikuje pisanie testów jednostkowych dla wszystkich delegatów i głównych ścieżek procesu.
If you look closely at the process application and analyze its nodes, you can see many repetitive functions: queries to external systems, logging, error handling, sending callbacks, etc. In other words, one needs to critically assess the process application, identify objects from it that can be easily encapsulated… But into what? Into Java code? No, that would be illogical, because in this case, the scheme would be closely tied to its Java implementation. In this situation, it makes sense to consider process pools.
A process pool is a scheme of a separate process that will have its own context. It is noteworthy that it’s convenient to extract atomic pieces of functionality from the main process into such pools, as well as all repetitive moments: sending notifications, requests to external systems, etc.
Może istnieć wiele pul procesów i logiczne byłoby pogrupowanie ich tematycznie. Na przykład zapytania do konkretnego mikroserwisu, alertowanie, wysyłanie różnych powiadomień. Interakcje między takimi pulami można łatwo skonfigurować za pomocą komunikatów Camunda. Za każdym razem, gdy taka pula jest wywoływana w silniku Camunda, przekazywana jest pewna wiadomość zawierająca nagłówek warunkowy i numer procesu nadrzędnego do zwrócenia odpowiedzi, a także zestaw danych niezbędnych do działania tej konkretnej małej puli.
Tutaj widzimy, jak główny proces (na dole) wysyła wiadomość, do której subskrybowany jest starter innej puli. Po wystąpieniu zdarzenia druga pula uruchamia nową instancję procesu, wysyła żądanie i wysyła odpowiedź z powrotem do głównego procesu, po czym pomyślnie kończy działanie. W tym czasie proces główny oczekuje na zdarzenie odpowiedzi z puli zewnętrznej, do której wysłał żądanie. Gdy wiadomość nadejdzie, proces jest kontynuowany. Jeśli nie ma odpowiedzi w określonym przedziale czasu, proces rozumie, że obliczenia zewnętrzne są niedostępne lub nie powiodły się, i kończy działanie.
Co to oferuje:
With this division, the process is always in a strictly single state: the response either came, or the process waited and ended. For business, it matters how exactly the process ended: whether it was an error or not. But this will be a proper conclusion, not an incident. This is important because a process not stuck in an incident doesn’t “consume” resources, and errors can be easily logged, statistics gathered, alerts set up, and analyzed.
Here, we can see that in the external pool, multiple tasks are called simultaneously. Let’s delve deeper into this point.
Camunda allows for the concurrent execution of branches of process computations. For this purpose, there’s a special gateway called the Parallel Gateway, using which the flow can be divided into parallels or to merge multiple parallel computations into one stream. It’s clear that to accelerate the flow of a process, it would be advantageous to delegate certain tasks to parallel threads. If the logic is independent, it can be executed in parallel, for example, making simultaneous requests to external systems and waiting for responses from all of them at once:
Each time at such a gateway, there will be overhead costs associated with creating new threads for task division and merging the results. One may encounter various locking exceptions, and, of course, it’s not always necessary or justified to always act this way, especially without testing, but the benefits are evident.
With sequential execution, the total execution time equals the sum of the execution times of each operation. In contrast, with parallel execution, it equates to the execution time of the longest operation. Given the conditions of non-instant responses from external sources, retries, and failures, this difference is far from insignificant. Another undeniable advantage is the form of “free retries”, i.e., while the longest request is being executed, the other tasks hypothetically have the opportunity to fail several times and attempt to redo their actions without impacting the overall task execution time.
Broke? It happens. The out-of-the-box version of Camunda has the capability to retry a failed transaction. By “transaction”, we mean Camunda’s internal mechanism for executing delegate code. The start of a transaction can be, for example, the “async before” or “async after” marker on a task in the modeler. When the engine encounters this marker, it commits its information to the database and starts a new asynchronous thread. This is important. To delve deeper, by “transaction”, we mean the execution section between the calls to the .complete() method in TaskService, followed by recording information to the database. These transactions, like others, are atomic.
Gdy wystąpi wyjątek techniczny, tj. jakikolwiek błąd niebiznesowy, na przykład dzielenie przez zero i zapomnienie o sprawdzeniu wartości null, transakcja wykonuje wycofanie i próbuje rozpocząć od nowa. Domyślnie robi to trzy razy z rzędu bez żadnych przerw. Próba ponowienia rozpoczyna się, gdy pojawi się zwykły wyjątek, który w świecie BPMN nazywany jest wyjątkiem technicznym, a nie BpmnError. Pojawiający się BpmnError zatrzymuje proces bez żadnych prób ponowienia. Wyobraź sobie, jak zwiększa to odporność procesu.
It makes sense to maximize this feature. Therefore, on every delegate that requests an external system, these markers are set, specifying the number of retries and the pause between them, and in the delegate code separates logic for when the process should be terminated and when it shouldn’t. It gives full control over the exception handling and retry mechanisms. As a result, the process tries to redo the failed task several times, and only after a series of failures it produces an error.
Perhaps, the biggest challenge is the handling of technical exceptions and BPMN-related errors, as well as designing the logic of their handling for a continuous flow of the process. We’ve already discussed some errors related to handling responses from external sources when talking about dividing into process pools. We’d like to remind you that the very call was encapsulated into a separate mini-process, and the main one either received a response and proceeded further or, due to a timeout, followed the “I didn’t receive a response” route.
Now, let’s look at that very small process:
Do you see the frame? It’s a subprocess. It contains specific tasks and captures errors thrown by internal tasks. Moreover, on such frames, the job executor is capable of creating a job for the timer, which sets the execution time for everything inside the subprocess.
How does it work? The execution flow reaches the subprocess, creates parallel timer processing, and waits either for the completion of what’s inside or, if the timer runs out first, it will follow the timer route. If an exception is thrown during the process, which the subprocess frame captures, the process will stop its execution on the current branch and follow the error branch.
It’s also evident that there’s an option to create response dispatches for critical requests. Note that error capturing works only for BpmnError with a specific code. Therefore, technically, it’s essential to catch any exception and throw a BpmnError with the required code, which works for the ErrorBoundaryEvent.
Error handling in the main process works similarly. From several tasks, logical units are singled out that can be placed in a subprocess frame, with a listener set up for a specific error code. But there are two nuances here. The first is that creating multiple identical branches with error handling, differing only in code, is inconvenient. If the error handling strategy changes or, for example, logging, then many delegates on the scheme would need to be redesigned, which isn’t desirable. Therefore, one might consider looking into event-based subprocesses.
At its core, this is a separate subprocess of the process pool, which starts only when a certain event it’s subscribed to occurs. For instance, if you subscribe such a subprocess to the BpmnError event with a code, say, MyCustomBusinessError, then when this event occurs, the handler will be triggered, and upon its completion, the process will end correctly. Yes, it didn’t end in success, but it ended correctly. In these subprocesses, you can also implement different handling logic for the same event depending on external conditions, for example, optionally notifying about an application error when the process passes a conditional point.
Drugi niuans jest znacznie bardziej skomplikowany. W prawdziwym życiu cykl życia każdego procesu jest prawdopodobnie podzielony na dwa etapy biznesowe: przed generowaniem leadów i po nim. Jeśli błąd wystąpił przed sformatowaniem danych w leada, proces można było prawdopodobnie po prostu zakończyć, powiadamiając o napotkanych trudnościach. Po wygenerowaniu leada nie jest to już możliwe.
We also don’t recommend ending processes if legal obligations arise during the process, for instance, if a contract is signed. How do we handle such errors? Some technical errors, like those associated with the unavailability of external services, are handled by automatic retries within a pre-agreed timeout. But what if the process crashed, retries have passed, but the hypothetical external microservice is still down?
Dochodzimy do koncepcji ręcznego rozwiązywania lub, znanej również jako, kompensacji.
How does it work? Any errors are caught, delegates are given the opportunity to retry if necessary, and if luck still doesn’t favor them, the process goes into an error state, but with the appropriate code, for instance, COMPENSATION_ERROR. This code is caught by another event-based subprocess, which processes, logs, notifies, and importantly, cannot fail unexpectedly. Only where it’s designed to, it throws an uncatchable technical exception and crashes into an incident.
Why do it this way? For monitoring, you can use EXCAMAD – an external admin panel for Camunda, an analogue to Cockpit, with powerful features. It highlights processes in incidents in red. These processes can be modified or restarted from the desired point. For instance, you can place the necessary variable value in the context and restart the process from the point right after the problematic one. This is convenient, straightforward, and allows for manual problem resolution with minimal effort.
Renowned for its open-source platform and user-friendly interface, Camunda has empowered numerous enterprises to optimize their workflows. Let’s explore a few real-life examples.
Münchener Hypothekenbank eG, niezależny bank hipoteczny, przeszedł na korzystanie z silnika przepływów pracy Camunda, aby poprawić i zautomatyzować wewnętrzne procesy, w szczególności obsługę korespondencji i koordynację wniosków o kredyty między działami. Wcześniej ich system był sztywny, brakowało mu elastyczności, co prowadziło do złożoności, które zwiększały wskaźniki błędów.
Przechodząc na architekturę mikrousług opartą na Javie, firma wybrała Camundę na podstawie wewnętrznych rekomendacji i ściśle współpracowała z WDW Consulting Group. Niektóre korzyści uzyskane natychmiast dzięki Camunda były gotowymi funkcjami, podczas gdy inne wymagały dalszego rozwoju. To przejście zaowocowało scentralizowaną listą zadań używaną przez wszystkich pracowników i zapewniło elastyczność w utrzymywaniu poszczególnych procesów bez wpływu na inne.
Najbardziej zauważalnym rezultatem była znaczna poprawa szybkości przetwarzania wniosków kredytowych. Jest to korzystne zarówno dla pracowników, jak i klientów końcowych. Jako świadectwo sukcesu, inne działy chcą teraz przyjąć Camundę, a bank zatrudnił nawet więcej programistów, aby dalej wspierać jej wdrożenie.
SV Informatik, spółka zależna SV SparkassenVersicherung, specjalizuje się w dostosowanych rozwiązaniach IT dla firm ubezpieczeniowych. Wdrożyli Camundę, aby zautomatyzować różne procesy w działach, co doprowadziło do znacznych oszczędności czasowych i poprawy czasów reakcji na potrzeby klientów. Firma przyjęła Camundę w 2018 roku jako rozwiązanie w poszukiwaniu skutecznego narzędzia do modelowania procesów biznesowych, koncentrując się na poprawie procesów i zwiększeniu współpracy między IT a innymi działami.
Od momentu wdrożenia, Camunda zautomatyzowała takie zadania jak anulowanie polisy ubezpieczenia komunikacyjnego i wnioski o wydanie dokumentów polisy. Godnym uwagi osiągnięciem było zautomatyzowane przetwarzanie zgłoszeń szkód burzowych online przez 80%. Okazało się to szczególnie cenne podczas powodzi i burz w Niemczech w 2021 roku. Narzędzia takie jak Camunda Optimize i Camunda Cockpit ułatwiają monitorowanie i optymalizację procesów.
W 2020 roku grupa SV, operating in Germany, Switzerland, and Austria, launched a disruptive digital platform called ‘likeMagic’ with Camunda’s assistance. This platform provided a seamless guest experience, from booking to check-out, with outcomes including a 95% self-check-in/out rate and a 9 out of 10 guest happiness score. The innovation reduced staffing needs and integrated platforms like Airbnb seamlessly. Recognizing its potential, SV Group offered ‘likeMagic’ to other hospitality providers. By 2023, they expanded from 2 to over 30 customers in the DACH region, with plans for a broader European reach and targeting 15,000 rooms by year-end.
Camunda’s transformative potential lies not just in its core functionalities but in its ability to redefine business operations at a fundamental level. Combined with Spring Boot, it opens a doorway to seamless integrations and enhanced scalability. Understanding the nuts and bolts of BPMN is paramount to leveraging Camunda’s full potential. As businesses evolve in this digital age, tools like Camunda stand out, offering dynamic solutions that can pivot and adapt to ever-changing needs. It’s not just about automating processes, it’s about innovating workflows, enhancing efficiency, and driving tangible results that make a difference. Embrace the power of Camunda, and let your business soar to new horizons.
Oceń ten artykuł:
4.8/5 (45 opinii)
Powiązane treści
Po otrzymaniu i przetworzeniu Twojego zgłoszenia skontaktujemy się z Tobą wkrótce, aby wyszczególnić potrzeby projektu i podpisać umowę o zachowaniu poufności, aby zapewnić poufność informacji.
Po przeanalizowaniu wymagań, nasi analitycy i programiści opracowują projekt z zakresem prac, wielkością zespołu, czasem i kosztami szacunki.
Umówimy się z Tobą na spotkanie, aby omówić ofertę i dojść do porozumienia porozumienia.
Podpisujemy umowę i rozpoczynamy pracę nad projektem tak szybko, jak to możliwe.
Dowiedz się jako pierwszy o innowacjach IT i interesujących studiach przypadków.
© 2007-2024 Innowise. Wszelkie prawa zastrzeżone.
Polityka prywatności. Polityka dotycząca plików cookie.
Innowise Sp. z o.o Ul. Rondo Ignacego Daszyńskiego, 2B-22P, 00-843 Warszawa, Polska
Rejestrując się, wyrażasz zgodę na naszą Politykę Prywatności, w tym korzystanie z plików cookie i przekazywanie Twoich danych osobowych.
Dziękuję!
Wiadomość została wysłana.
We’ll process your request and contact you back as soon as possible.
Dziękuję!
Wiadomość została wysłana.
Przetworzymy Twoją prośbę i skontaktujemy się z Tobą tak szybko, jak to możliwe.