A Camunda Platform egyre nagyobb népszerűségnek örvend a világ számos részén, így Magyarországon is, és nem csak az új worflow-megoldások bevezetésénél merül fel egyre gyakrabban a neve, hanem meglévő, komoly rendszerek kiváltása kapcsán is, hiszen open-source, így szinte ingyen megoldja azt, amit a nagyok csak jó pénzért. A blogcikkünkben annak járunk utána, hogy ez igaz-e, avagy mennyire érdemes egy nagyvállalati core-folyamatot kiváltani egy community megoldással. Vagy inkább az Enterprise verziót kéne megvenni, ami a Camundánál sem annyira olcsó?

Az nem kérdés, hogy a Camunda termékei ki tudnak szolgálni nagyvállalati igényeket is, és hogy szolgáltatásukban felveszik a versenyt a BPM piac nagyhalaival is. A kérdés az, hogy a Community Edition képes-e versenyezni az Enterprise Edition-nel.

A Camunda honlapján (https://camunda.com/enterprise/) található egy jól összeszedett táblázat a két kiadás közti különbségekről. Azonban az egyes termékek, funkciók és szolgáltatások csak címszavakban vannak felsorolva. A kiadások közötti döntést segítendő, az egyes termékek funkcionalitását és lehetséges felhasználási területeit érdemes részletesebben is megvizsgálni, illetve egy mélyebb felbontás mentén csoportosítani.

Folyamatok futtatása

A BPMN Engine és DMN Engine az ingyenes verzió részei, ők teszik lehetővé a folyamatok programozott kezelését. A munka oroszlánrészét a BPMN Engine végzi: activity-k kezelése, job-ok indítása, timer-ek figyelése, események kiváltása, és még sok más további feladat. A DMN Engine-nek a BPMN szabványban lévő business rule task-ok (leegyszerűsítve döntési táblák, amik különböző bemeneti feltételekhez adott kimeneteket rendelnek) modellezésében és kiértékelésében van szerepe.

Folyamatok modellezése

Az ingyenes Modeler alkalmazással grafikus felületen tudjuk a folyamatainkat modellezni. Az itt előállt folyamatdefiníciókat olvassa fel a folyamatmotor. Egy definíció egy XML-fájl, ami két rétegből tevődik össze: BPMN 2.0 szabványnak megfelelő folyamatdefiníció + Camunda specifikus kiegészítések.

Cockpit (Technical Operations)

A Cockpit tulajdonképpen a Camunda műszerfala, technikai üzemeltetői felülete. Elérhető a Community és Enterprise verzióban is. Megtekinthetjük a telepített, futó, szüneteltetett, végbement, hibára futott folyamatainkat és különböző módokon beavatkozhatunk a futásukba azért, hogy megváltoztassuk a lefolyásukat, vagy elhárítsunk egy hibát. Legfontosabb funkciói: folyamatok aktuális állapotának megtekintése, folyamat szüneteltetése, folytatása, leállítása, újraindítása, sikertelen job-ok detektálása és újrapróbálkozás kezdeményezése, folyamat audit trail (history) megtekintése.

Cawemo (Collaboration Platform)

A Cawemo (https://camunda.com/products/camunda-platform/cawemo/) ingyenes és Enterprise kiadásban is megtalálható. Egy webes felületen elérhető kollaboratív modellező eszközről van szó, amely lehetővé teszi, hogy több ember közösen modellezzen folyamatokat. Legegyszerűbben a folyamatmodellezés ’Google Docs’-ának lehet felfogni. Lehetőség van folyamatokat létrehozni, szerkeszteni, csoportosítani, verziózni, folyamatokhoz jegyzeteket írni, beszélgetésfolyamokat nyitni.

A fizetős verzió extra funkciói: folyamatok importálása a modeler-ből és az engine-ből, verziók vizuális összehasonlítása.

Optimize (Reporting, Alerting, Analytics)

A fizetős Optimize (https://docs.camunda.org/optimize/latest) riportolási, monitorozási és alerting lehetőségeket nyújt. Egy Big Data solutionről beszélhetünk, olyan információk kinyerését teszi lehetővé a folyamatainkról, amikre építve üzleti döntéseket lehet hozni és optimalizálni az egyes folyamatokat.

A riportok részletesen konfigurálhatók és segítségükkel különböző nézőpontok mentén vizsgálódhatunk. Többek között a következő típusú kérdésekre kaphatunk választ: melyik user task hányszor lett végrehajtva, milyen gyakran történt incidens, milyen arányban lettek bejárva egy folyamat lefutásai esetén a végrehajtási ágak, minimum/átlagos/maximum végrehajtási idők folyamatlépésekre/folyamatokra adott időintervallumban, kiugróan lassan végbemenő folyamatrészek azonosítása.

Alerting kapcsán riportok eredményeire alapozva lehet például adott email-címekre értesítéseket küldeni. Egy lehetséges konfiguráció: 10 percenként fusson le egy riport, ami meghatározza, hogy az adott napon futott folyamatok hány százaléka esetén keletkezett hiba, ha ez a szám meghalad egy határértéket, akkor küldjön az eszköz értesítő emailt.

Support és SLA

Supportot, és ezzel kapcsolatos SLA-kat csak az Enterprise kiadás esetén vállal a Camunda, ami kritikus core-funkciók esetén fontos lehet nagyvállalati környezetben. Hibabejelentésre telefonon vagy JIRA-n keresztül van lehetőség. Itt említhetjük még, hogy a community kiadásból új verzió 6 havonta kerül kiadásra. Az engine a kiadás pillanatában megegyezik a fizetős verzióval, viszont a fizetős esetén félévközi verziók is lehetnek, amik hibajavításokat tartalmaznak.

Melyik verzió mellett döntsek?

Az ingyenes verzió esetén teljes funkcionalitásában használható BPMN Engine, DMN Engine és Camunda Modeler termékek alapvetően lehetővé teszik azt, hogy valaki egy komolyabb, komplexebb projekt esetén is jól elboldoguljon az ingyenes verzióval. Mivel a motor ugyanaz a két verzió között, ezért a következő aspektusok szempontjából nincsen különbség: performancia, skálázhatóság, rendelkezésre állás.

A Cawemo esetén  tehát leginkább együttműködést támogató funkciókat tartogat az enterprise, ennek hiánya eddig 10-15 fős együttműködő csapatnál nem volt még számunkra nehezítő szempont.

Az Optimize által nyújtott reporting és alerting funkciók egy része akár egyedileg önállóan megvalósítható. Erre az ad lehetőséget, hogy a Camunda adatbázisban tárolja az engine állapotát: folyamatdefiníciók, folyamatok, állapotok, folyamat adatok, stb. Különböző lekérdezéseket írhatunk és lefejleszthetjük az azok eredményét feldolgozó logikákat és alerting funkciókat. A teljes Optimize funkcionalitás házilag való kiváltását nem érdemes megcélozni, ellenben ha jól definiált, véges számú riportra van szükségünk, akkor ezeket könnyen implementálhatjuk. Azonban, ha komplex, a riportot lekérő személy által a felületen dinamikusan összeállított kimutatásokra van szükségünk, akkor valószínűleg érdemesebb a fizetős verzió mellett dönteni.

A Cockpit egyik legfontosabb funkcionalitása az, hogy detektálni tudjuk a hibára futott folyamatokat, sikertelen job-okat. Szó lehet ideiglenes, az alkalmazásunktól kívülálló hibáról (pl: egy hívott REST szolgáltatás nem elérhető), vagy pedig az alkalmazásunk forráskódjában lévő programozói hibáról. A hiba megszűnése/megszüntetése után kezdeményezhetjük az újrapróbálkozást a Cockpit-en keresztül. A funkció az ingyenes verzió része.

Ha szükségesek a riporting jellegű enterprise funkciókra, akkor ahogy az Optimize-nál már említettük, lehetőségünk van ezeket az egyedi lekérdezéseket és riportokat egyedi fejlesztéssel megoldani. Ráadásul, ha ezeket a riportokat magában a Camunda Cockpit-ben szeretnénk látni, lehetőségünk van saját Cockpit plugin-ek fejlesztésére, így bővítve annak funkcionalitását.

A további műveletjellegű Enterprise Cockpit funkcióknak egy része olyan, amit szerintem a legtöbb alkalmazás esetén nem tudunk tényleges használni, vagy akár hibát okozhat a használata. Például a BPMN folyamatok deploy-olása és undeploy-olása, folyamatok újraindítása. A probléma abból fakad, hogy általában a process engine-t egy alkalmazáson keresztül vezéreljük, a folyamatok ott is szerepelnek, megvannak a sajátosságaik és ott is számontartják, lehetnek folyamatmotoron kívüli adataik is. Hiába deploy-olunk egy új folyamatot a Cockpit-ben, ha például egy webes alkalmazásunk felületén nincs lehetőség annak elindítására, vagy ha teljesen UI-interakció nélküli folyamatról van szó, akkor a szerveralkalmazásunkban nincsenek lefejlesztve a hozzá kapcsolódó logikák. Egy újraindítás esetén probléma lehet abból, hogy bizonyos taszkok nincsenek felkészítve arra, hogy többször fussanak le, vagy egyszerűen üzletileg nem futhatnak le többször. Általánosságban elmondható, hogy az alkalmazással való kapcsolatot és egy művelet lehetséges hatásait mindegyik beavatkozás estén át kell gondolni, akár ingyenes, akár Enterprise funkcióról van szó.

Továbbá, ahogy említettük, kérdés, hogy működésbiztonság, jogi védelem és egyéb szempontokból mennyire fontos a megrendelő számára az SLA és a support. Mert persze nem mehetünk el az Enterprise verzió költségei mellett sem, ami ugyan éves szinten többmilliós tétel, de a nagy versenytársakénál olcsóbb, tehát mindenképpen megéri egy-egy drágább megoldás kiváltásában opcióként végiggondolni.-

Az viszont áttekintve a fentieket, egyáltalán nem kérdés, hogy érdemes-e a Community-vel belevágni Enterprise-szintű projektek megvalósításába is, hiszen mindent tud, amire szükség van BPMN-engine terén. Ennél kisebb, kis- és középvállalati szinten pedig elképzelni sem tudunk jelenleg jobb megoldást.

Végül feltesszük a kérdést mi is: vajon a Community Edition lett a túl jó? Vagy túl kevés plusz van az Enterprise-ban? Esetleg egy SLA alapú biztosítás ér ilyen sokat a vállalatoknak? Nektek mi a véleményetek? Írjátok meg a közösségi portálokon kommentbe, vagy küldjétek el számunkra a camunda@nitrowise.com címre. Ugyanitt állunk a rendelkezésetekre, ha szakmai kérdésetek lenne, vagy szeretnétek konzultálni esetleges projektek tartalmáról!

Tamás Pollák

Tomi a Nitrowise Labs egyik vezető fejlesztője. Az elmúlt években a Java spring mellett sokat foglalkozott a BPM témakörével: vezetett fejlesztést Camunda, jBPM4 és Activiti alapokon is. Nem csak a szoftverek, hanem munkatársaink fejlesztésében is nagyon aktív, lelkesen mentorálja junior és medior fejlesztőinket.