Bevezetés a Folyékony

1. Áttekintés

A Flowable egy Java-ban írt üzleti folyamatmotor. Ebben az oktatóanyagban áttekintjük az üzleti folyamatok részleteit és megértjük, hogyan használhatjuk fel a Flowable Java API-t egy üzleti üzleti minta létrehozásához és telepítéséhez.

2. Az üzleti folyamatok megértése

Egyszerűen fogalmazva, az üzleti folyamat olyan feladatok összessége, amelyek egy meghatározott sorrendben történő teljesítés után egy meghatározott célt teljesítenek. Az üzleti folyamat minden feladata világosan meghatározza az inputokat és outputokat. Ezek a feladatok emberi beavatkozást igényelhetnek, vagy teljesen automatizáltak lehetnek.

Az OMG (Object Management Group) meghatározta az üzleti folyamatok modelljének és jelölésének (BPMN) nevű szabványt a vállalkozások számára, hogy meghatározzák és kommunikálják folyamataikat. A BPMN széles körben támogatott és elfogadott az iparban. A Flowable API teljes mértékben támogatja a BPMN 2.0 folyamatdefiníciók létrehozását és telepítését.

3. Folyamatdefiníciók létrehozása

Tegyük fel, hogy a cikkek áttekintése előtt egyszerű publikálási folyamatunk van.

Ennek a folyamatnak a lényege, hogy a szerzők benyújtanak egy cikket, a szerkesztők pedig elfogadják vagy elutasítják azt. Ha elfogadják, a cikket azonnal közzéteszik; elutasítás esetén azonban a szerzőt e-mailben értesítjük:

A folyamatdefiníciókat XML fájlokként hozzuk létre a BPMN 2.0 XML szabvány segítségével.

Határozzuk meg egyszerű folyamatunkat a BPMN 2.0 szabvány szerint:

Most itt elég sok olyan elem található, amelyek szabványos XML dolgok, míg mások a BPMN 2.0-ra jellemzőek:

  • A az egész folyamat egy „process” nevű címkébe van csomagolva, ami viszont a „definíciók” nevű címke része
  • A folyamat eseményekből, folyamatokból, feladatokból és átjárókból áll
  • Egy esemény kezdő vagy záró esemény
  • Egy folyamat (ebben a példában egy szekvenciafolyam) összekapcsol más elemeket, például eseményeket és feladatokat
  • A feladatok az a hely, ahol a tényleges munkát végzik; ezek lehetnek többek között „felhasználói feladatok” vagy „szolgáltatási feladatok”
  • A felhasználói feladat megköveteli, hogy egy emberi felhasználó lépjen kapcsolatba a Flowable API-val és tegyen lépéseket
  • A szolgáltatási feladat egy automatikus feladatot jelent, amely lehet Java osztály hívása vagy akár HTTP hívás
  • Az átjáró a „jóváhagyott” attribútum alapján hajt végre; ez a folyamat változója, és később meglátjuk, hogyan állítsuk be őket

Bár bármilyen szövegszerkesztőben létrehozhatunk folyamatdefiníciós fájlokat, ez nem mindig a legkényelmesebb módszer. Szerencsére azonban a Flowable felhasználói felület opciókat is tartalmaz, amelyek ezt Eclipse plugin vagy webalkalmazás segítségével tehetik meg. Ha helyette IntelliJ-t használ, akkor elérhető egy IntelliJ bővítmény is.

4. Munka a Flowable API-val

Most, hogy meghatároztuk egyszerű folyamatunkat egy XML fájlban a BPMN 2.0 szabványnak megfelelően, szükségünk van egy módra annak elküldésére és futtatására. A Flowable biztosítja a Process Engine API-t, hogy kölcsönhatásba lépjen a Flowable Motorokkal. A Flowable nagyon rugalmas, és számos módot kínál az API telepítésére.

Tekintettel arra, hogy a Flowable egy Java API, a folyamatmotort bármely Java alkalmazásba beépíthetjük a szükséges JAR fájlok egyszerű beillesztésével. Nagyon jól kihasználhatjuk Maven-t e függőségek kezelésében.

Ezenkívül a Flowable csomagban szállított API-kkal rendelkezik, amelyek a Flowable HTTP-n keresztül működnek együtt. Ezeket az API-kat nagyjából felhasználhatjuk bármi másra, ami a Flowable API-n keresztül lehetséges.

Végül, A Flowable kiválóan támogatja az integrációt a Spring and Spring Boot! Oktatóanyagunkban a Flowable és Spring Boot integrációt fogjuk használni.

5. Bemutató alkalmazás létrehozása a folyamat motorjával

Hozzunk létre most egy egyszerű alkalmazást, amely egy folyamatmotort burkol a Flowable-ből, és HTTP-alapú API-t kínál a Flowable API-val való interakcióhoz. Lehet, hogy egy web vagy mobil alkalmazás ül az API tetején, hogy jobb legyen az élmény, de ezt az oktatóanyagot kihagyjuk.

A bemutatónkat Spring Boot alkalmazásként készítjük el.

5.1. Függőségek

Először nézzük meg azokat a függőségeket, amelyeket Mavenből kell kihúznunk:

 org.springframework.boot spring-boot-starter-web org.flowable flowable-spring-boot-starter 6.4.1 com.h2database h2 futásidejű 

A szükséges függőségek mind elérhetőek a Maven Central-nál:

  • Spring Boot Starter for Web - ez a Spring Boot standard indítója
  • Folyékony indító a tavaszi csomagtartóhoz - ez szükséges a rugós indító motorokhoz
  • H2 Adatbázis - Az áramláshoz adatbázisra van szükség az adatok tárolásához, és a H2 az alapértelmezett memória-adatbázis

5.2. A folyamat meghatározása

Amikor elindítjuk a Spring Boot alkalmazást, megpróbálja automatikusan betölteni az „erőforrások / folyamatok” mappában található összes folyamatdefiníciót. Ezért hozzunk létre egy XML fájlt a fent definiált folyamatdefinícióval a „article-workflow.bpmn20.xml” névvel, és helyezzük el abba a mappába.

5.3. Konfigurációk

Mivel tisztában vagyunk azzal, hogy a Spring Boot nagy véleményen alapuló megközelítést alkalmaz az alkalmazáskonfigurációval kapcsolatban, ez igaz a Flowable-re is, a Spring Boot részeként. Például, a Flowable a H2-t az osztálypálya egyetlen adatbázis-illesztőprogramjaként észlelve automatikusan konfigurálja használatra.

Nyilvánvaló, hogy minden konfigurálható szempont egyedi módon konfigurálható az alkalmazás tulajdonságain keresztül. Ehhez az oktatóanyaghoz azonban ragaszkodunk az alapértelmezésekhez!

5.4. Java küldöttek

A folyamatdefiníciónkban használtunk néhány Java osztályt, amelyeket állítólag a szolgáltatási feladatok részeként kell meghívni. Ezek az osztályok a JavaDelegate felület és Java Flavable néven ismertek. Most meghatározzuk a dummy osztályokat ezekre a Java küldöttekre:

public class PublishArticleService megvalósítja a JavaDelegate {public void execute (DelegateExecution végrehajtás) {System.out.println ("A jóváhagyott cikk közzététele."); }}
public class SendMailService megvalósítja a JavaDelegate {public void execute (DelegateExecution végrehajtás) {System.out.println ("Elutasító levelek küldése a szerzőnek."); }}

Nyilvánvaló, hogy ezeket a dummy osztályokat tényleges szolgáltatásokkal kell helyettesítenünk egy cikk közzétételéhez vagy e-mail küldéséhez.

5.5. HTTP API-k

Végül hozzunk létre néhány végpontot, amelyek kölcsönhatásba lépnek a folyamat motorjával, és működnek együtt az általunk definiált folyamattal.

Először meghatározunk egy vezérlőt, amely három végpontot tesz ki:

@RestController public class ArticleWorkflowController {@Autowired private ArticleWorkflowService szolgáltatás; @PostMapping ("/ submit") public void submit (@RequestBody Article cikk) {service.startProcess (cikk); } @GetMapping ("/ feladatok") public list getTasks (@RequestParam String megbízott) {return service.getTasks (megbízott); } @PostMapping ("/ review") public void review (@RequestBody Approval jóváhagyás) {service.submitReview (jóváhagyás); }}

Adatkezelőnk kiteszi a végpontokat, hogy küldjenek be egy cikket felülvizsgálatra, hozzanak le egy listát az áttekintendő cikkekről, végül pedig nyújtsanak be egy cikk felülvizsgálatát. Cikk és Jóváhagyás szabványos POJO-k, amelyek megtalálhatók az adattárban.

A munka nagy részét tulajdonképpen erre ruházzuk ArticleWorkflowService:

@Service public class ArticleWorkflowService {@Autowired private RuntimeService runtimeService; @Autowired private TaskService taskService; @Transactional public void startProcess (cikkcikk) {Map variables = new HashMap (); variables.put ("author", article.getAuthor ()); variables.put ("url", article.getUrl ()); runtimeService.startProcessInstanceByKey ("articleReview", változók); } @Transactional public List getTasks (String assignee) {List feladatok = taskService.createTaskQuery () .taskCandidateGroup (megbízott) .list (); return task.stream () .map (task -> {Map variables = taskService.getVariables (task.getId ()); return new Article (task.getId (), (Karakterlánc) variables.get ("author"), ( String) variables.get ("url"));}) .collect (Collectors.toList ()); } @Transactional public void submitReview (Jóváhagyás jóváhagyása) {Térképváltozók = új HashMap (); variables.put ("jóváhagyott", jóváhagyás.isStatus ()); taskService.complete (jóváhagyás.getId (), változók); }}

Most a legtöbb kód itt meglehetősen intuitív, de értsük meg a legfontosabb szempontokat:

  • RuntimeService hogy egy adott benyújtás folyamatát példamutatóvá tegye
  • TaskService feladatok lekérdezéséhez és frissítéséhez
  • Az összes adatbázis-hívás becsomagolása a Spring által támogatott tranzakciókba
  • Részletek, például a szerző és az URL tárolása a Térkép, és mentés a folyamatpéldánnyal; ezeket folyamatváltozóknak nevezzük, és egy folyamatdefiníción belül férhetünk hozzájuk, amint azt korábban láthattuk

Most készen állunk az alkalmazásunk és a folyamatmotor tesztelésére. Miután elindítottuk az alkalmazást, egyszerűen használhatjuk becsavar vagy bármely olyan REST kliens, mint a Postman, hogy kölcsönhatásba lépjen az általunk létrehozott végpontokkal.

6. Egységtesztelési folyamatok

A Flowable támogatja a JUnit különböző verzióit, beleértve a JUnit 5-et is, az üzleti folyamatok egységtesztjeinek létrehozásához. A Spring-hez való folyékony integráció ehhez is megfelelő támogatást nyújt. Lássuk egy folyamat tipikus egységtesztjét tavasszal:

@ExtendWith (FlowableSpringExtension.class) @ExtendWith (SpringExtension.class) public class ArticleWorkflowUnitTest {@Autowired private RuntimeService runtimeService; @Autowired private TaskService taskService; @Test @Deployment (erőforrások = {"process / article-workflow.bpmn20.xml"}) void articleApprovalTest () {Térképváltozók = új HashMap (); variables.put ("szerző", "[e-mail védett]"); variables.put ("url", "//baeldung.com/dummy"); runtimeService.startProcessInstanceByKey ("articleReview", változók); Feladat feladat = taskService.createTaskQuery (). SingleResult (); assertEquals ("Ellenőrizze a beküldött oktatóanyagot", task.getName ()); variables.put ("jóváhagyott", igaz); taskService.complete (task.getId (), változók); assertEquals (0, runtimeService.createProcessInstanceQuery (). count ()); }}

Ennek nagyjából úgy kell kinéznie, mint egy tavaszi egységvizsgálat tavasszal, kivéve néhány hasonló megjegyzést @Bevezetés. Most a @Bevezetés a Flowable feliratozást nyújt a tesztelési módszerek köré telepített folyamatok létrehozásához és törléséhez.

7. A folyamatok telepítésének megértése

Bár ebben a bemutatóban nem térünk ki a folyamat telepítésének részleteire, érdemes néhány fontos szempontot átfogni.

Általában a folyamatokat üzleti archívumként (BAR) archiválják, és egy alkalmazásban telepítik. Telepítés közben ezt az archívumot megvizsgálja a műtermékek - mint például a folyamatdefiníciók - és feldolgozza. Lehet, hogy észrevette a folyamatdefiníció fájl végződését, amely a következővel végződik: “.Bpmn20.xml”.

Noha az oktatóanyagunkban az alapértelmezett memóriában lévő H2 adatbázist használtuk, ez valójában nem használható a valós alkalmazásokban, abból az egyszerű okból, hogy a memóriában lévő adatbázis nem fog semmilyen adatot megőrizni az induló vállalkozások között, és gyakorlatilag fürtözött környezetben lehetetlen használni! Ennélfogva, termelési szintű relációs adatbázist kell használnunk, és meg kell adnunk a szükséges konfigurációkat az alkalmazásban.

Míg a BPMN 2.0-nak nincs fogalma a verzióról, A Flowable létrehoz egy verzióattribútumot a folyamathoz, amelyet az adatbázisban telepítenek. Ha ugyanannak a folyamatnak az „id” attribútum által azonosított frissített verziója kerül telepítésre, akkor egy új bejegyzés jön létre a növelt verzióval. Amikor megpróbálunk egy folyamatot „id” alapján elindítani, a folyamatmotor beolvassa a telepített folyamatdefiníció legújabb verzióját.

Ha a folyamatdefiníció elkészítéséhez az egyik korábban tárgyalt tervezőt használjuk, akkor már van egy vizualizáció a folyamatunkhoz. Exportálhatjuk a folyamatdiagramot képként, és elhelyezhetjük az XML folyamatdefiníciós fájl mellett. Ha ragaszkodunk a Flowable által javasolt szabványos elnevezési szokáshoz, akkor ezt a képet a folyamatmotor és maga a folyamat fogja feldolgozni. Sőt, ezt a képet API-k segítségével is be tudjuk tölteni!

8. A folyamatpéldányok böngészési előzményei

Az üzleti folyamatok esetében gyakran kulcsfontosságú a múlt történéseinek megértése. Szükségünk lehet erre egyszerű hibakeresés vagy bonyolult jogi ellenőrzés céljából.

Folyamatosan rögzíti, hogy mi történik a folyamat végrehajtása során, és az adatbázisban tartja. Ezenkívül a Flowable elérhetővé teszi ezt az előzményeket az API-n keresztül lekérdezés és elemzés céljából. Hat entitás van, amely alatt a Flowable ezeket rögzíti, és a HistoryService rendelkezik módszerekkel mindet lekérdezni.

Lássunk egy egyszerű lekérdezést a kész folyamatpéldányok lekérésére:

HistoryService historyService = processEngine.getHistoryService (); Lista tevékenységek = historyService .createHistoricActivityInstanceQuery () .processInstanceId (processInstance.getId ()) .finished () .orderByHistoricActivityInstanceEndTime () .asc () .list ();

Ahogy látjuk, a rögzített adatok lekérdezésére szolgáló API elég összetett. Ebben a példában a kész folyamatpéldányokat azonosító szerint kérdezzük le, és a végidő növekvő sorrendjében rendeljük meg őket.

9. Monitoring folyamatok

A figyelés minden üzleti szempontból kritikus alkalmazás kulcsfontosságú eleme, és még inkább a szervezet üzleti folyamatait kezelő alkalmazások számára. A Flowable számos lehetőséggel rendelkezik, amelyek segítségével valós időben figyelhetjük a folyamatokat.

A Flowable olyan MBeans-okat biztosít, amelyekhez hozzáférhetünk a JMX-en keresztül, hogy ne csak megfigyelés céljából gyűjtsön adatokat, hanem számos más tevékenység elvégzésére is. Ezt integrálhatjuk bármilyen szabványos JMX klienssel, beleértve jconsole, amely a standard Java disztribúciók mellett van jelen.

A JMX monitorozásra való használata sok lehetőséget nyit meg, de viszonylag összetett és időigényes. Mivel azonban a Spring Boot-ot használjuk, szerencsénk van!

A Spring Boot az Actuator végpontokat kínálja az alkalmazás metrikáinak összegyűjtésére HTTP-n keresztül. Ezt zökkenőmentesen integrálhatjuk egy olyan eszközkészlettel, mint a Prometheus és a Grafana, hogy minimális erőfeszítéssel létrehozzunk egy gyártási szintű felügyeleti eszközt.

A Flowable egy további aktuátor végpontot nyújt, amely információkat szolgáltat a futó folyamatokról. Ez nem olyan jó, mint az információgyűjtés a JMX-en keresztül, de gyors, egyszerű és főleg elegendő.

10. Következtetés

Ebben az oktatóanyagban megvitattuk az üzleti folyamatokat és annak meghatározását a BPMN 2.0 szabványban. Ezután megvitattuk a folyékony folyamatmotor és az API-k képességeit a folyamatok telepítéséhez és végrehajtásához. Láttuk, hogyan lehet ezt integrálni egy Java alkalmazásba, konkrétan a Spring Boot-ba.

Tovább folytatva megvitattuk a folyamatok egyéb fontos szempontjait, mint a telepítés, a megjelenítés és a monitorozás. Mondanom sem kell, hogy csak megkarcoltuk az üzleti folyamat felületét és egy olyan erőteljes motort, mint a Flowable. A Flowable nagyon gazdag API-val rendelkezik, és elegendő dokumentáció áll rendelkezésre. Ennek az oktatóanyagnak azonban fel kellett volna kelteni az érdeklődésünket a téma iránt!

Mint mindig, a példák kódja elérhető a GitHub oldalon.


$config[zx-auto] not found$config[zx-overlay] not found