Zkušenosti s orchestrátorem Camunda

vesterna12

  • ***
  • 124
  • byrokracie zabíjí kreativitu
    • Zobrazit profil
    • E-mail
Zkušenosti s orchestrátorem Camunda
« kdy: 13. 05. 2023, 15:19:38 »
Je tu nekdo kdo pouziva software Camunda?
Jde o BPM orchestrator.
Zajimalo by me co byl duvod pro zavedeni, jaky problem to ve Vasi situaci resilo a co Vam to v zaveru dalo?
« Poslední změna: 13. 05. 2023, 17:22:19 od Petr Krčmář »


Re:Zkušenosti s orchestrátorem Camunda
« Odpověď #1 kdy: 13. 05. 2023, 19:25:30 »
Používá se to jako stavový stroj když jsou někde u nějakých entit složitá flow, hodně stavů, hodně přechodů mezi nima, různé čekací stavy "A tady musí něco potvrdit zodpovědná osoba XYZ". Typicky to používají banky. Výhoda může být, že nějaká ne-skilled obshluha software může vidět co je v jakém stavu graficky, a mít základní přehled co se kde vlastně dělá., a když zpracování nějaké objednávky fajlnulo, tak v jakém stavu to momentálně je.

Re:Zkušenosti s orchestrátorem Camunda
« Odpověď #2 kdy: 14. 05. 2023, 16:17:00 »
tohle je typ SW, kterým se problémy neřeší, ale přidávají.

Tohle je pro enterprise segment, kde je BPM namodelované a potřebuješ ho obsluhovat lidmi, kteří nejsou programátoři a celý proces standardizovat, monitorovat a ovládat. Dá se použít i pouze na orchestraci úkolů, ale u toho člověk umře, je to na to příliš složité.

Tvůj požadavek je příliš obecný, ptáš se na něco, co se  běžně integruje měsíce a týdny s na to školí obsluha.

Re:Zkušenosti s orchestrátorem Camunda
« Odpověď #3 kdy: 14. 05. 2023, 19:56:15 »
Pokud vyvíjíš service, u které víš, že budeš potřebovat mini stavový stroj, třeba na zpracování objednávek, a víš, že tam bude jednou třeba 50 různých stavů a mezi nimi grafové přechody, tak je možné, že Camunda nebo něco podobného problém řeší. Jinak bys totiž musel něco jako je Camunda implementovat sám. 50 stavů už musíš být např. schopen vyrenderovat jako obrázek, aby se v tom i třeba vývojáři vyznali. Možné přechody musíš mít někde deklarativně definovené. A musíš implementovat nějaký reprocessing, křižovatku.
« Poslední změna: 14. 05. 2023, 19:58:56 od registrovany123 »

Re:Zkušenosti s orchestrátorem Camunda
« Odpověď #4 kdy: 16. 05. 2023, 12:49:40 »
Ja v jednom projektu mam Activiti, ktery dela de facto to samy (Camunda je myslim dokence forkem Activiti)

Activiti mi resi prochazeni stavovym diagramem (BPMN)
Stejne musim naprogramovat plneni toho BPM daty (kdo bude delat ukoly, rozhodni se, kterou vetvi jit, atd.) - Toto resim Spring beanem, kterej obsluhuje dany BPMN (jsou tam jeste service tasky)
Taky se musi naprogramovat zpusoby plneni ukolu (formular, kde uzivatel ukol splni), Kazdej typ ukolu se plni jinak (schvaleni/zamitnuti, atd)

Stejne skoncis programovani X vopicaren okolo, ktery zajistej, aby to slapalo
Vyhoda bude hlavne ve chvili, kdy celej proces obsahuje paralelni vetve a zaroven nejde o jednokrokovej proces (tzn. obtizne modelovatelny obycejnym stavovym automatem)


Re:Zkušenosti s orchestrátorem Camunda
« Odpověď #5 kdy: 16. 05. 2023, 17:20:47 »
hele paralelni vetve u stavoveho stroje... Docela by me zajimal pripad, kdy potrebujes neco udelat paralelne a nejde to udelat sekvencne. To by me fakt zajimalo, co by to bylo. Protoze podle me nic. Vsechno jde usporadat za sebou.

Napada me jen jeden pripad, kdy to nejde - kdyz nekdo pouziva Activiti a Cumundu a zbytecne paralelizuje co se paralelizovat nemusi, aneb Hammer a Nail problem.

Re:Zkušenosti s orchestrátorem Camunda
« Odpověď #6 kdy: 16. 05. 2023, 21:29:07 »
registrovany123 když o tom přestaneš přemýšlet jako o stavovém stroji a začneš to vnímat jako to, co to je tj. procesní engine, tak sám vymyslíš 1000+1 paralelních procesů s praktickým využitím.
Ale tak, když už:
nástup nového zaměstnance - paralelně zajistíš přístupy a pracovní vybavení
zakázková výroba nábytku - objednáš velkou krabici pro odeslání židle a zároveň ji začneš vyrábět
apod.

Jinak k tématu, Camunda není jen BPM orchestrátor, ale součástí je i DMN. V kombinaci to pak může dávat zajímavé možnosti, kdy chování procesu lze upravovat přes podmínky rozhodovacích matic. Lze to však využívat i samostatně.

Nám třeba řeší problém, kdy hlavní proces má několik podprocesů, trvá několik týdnů a obsluhuje ho řada mikroservices. Když aplikuješ Camundu jako orchestrátora takového procesu, máš kompletní grafický pohled na chování distribuovaného systému a to včetně historie, vyhledávání konkrétních instancí apod. Do DMN dáš kritéria, které systém používá pro úpravu svého chování a např. po jejich změně pak necháš některé instance reprocesovat (ok to už není úplně triviální, ale jde to).
Třeba to není úplně typický use case, ale je to dost praktické.

Výhody jsou, že spoustu věcí podporuje Camunda nativně nebo přes pluginy. Např. SSO, HA, škálovatelnost, různé typy storages, Rest api, různé integrace a nemusí se to programovat, jen se to konfiguruje. Lze ji použít samostatně nebo třeba jako embeded do Spring Bootu a pořešit si tak třeba nějaké obskurní integrace nebo funkcionality.
A v neposlední řadě, že to hlavní je vyjádřeno graficky. Zlepšuje to nejen komunikaci mezi rolemi projektu, ale je pak i velmi snadná dekompozice funkcionalit jednotlivých aktivit.

Re:Zkušenosti s orchestrátorem Camunda
« Odpověď #7 kdy: 16. 05. 2023, 21:46:58 »
hele paralelni vetve u stavoveho stroje... Docela by me zajimal pripad, kdy potrebujes neco udelat paralelne a nejde to udelat sekvencne. To by me fakt zajimalo, co by to bylo. Protoze podle me nic. Vsechno jde usporadat za sebou.

Napada me jen jeden pripad, kdy to nejde - kdyz nekdo pouziva Activiti a Cumundu a zbytecne paralelizuje co se paralelizovat nemusi, aneb Hammer a Nail problem.

Asi můžeš všechno dát jako sekvenci, ale blokuješ tím celý proces. Příklad kontrola výrobku a kontrola dokumentace k výrobku. Oboje jde paralelní větví, jedno není závislé na druhém. Obě podmiňují QA approval. Další příklad: ffmpeg processing graph: zpracování obrazu a zvuku jde paralelně... atd. Sekvence blokuje.
« Poslední změna: 16. 05. 2023, 21:50:27 od uetoyo »

Re:Zkušenosti s orchestrátorem Camunda
« Odpověď #8 kdy: 17. 05. 2023, 12:27:35 »
Jsem rád, že se někdo chytil. Takže, obojí

- kontrola výrobku
- kontrola dokumentace

Můžeš sloučit do jediného stavu:

- kontrola

Na to nepotřebuješ mít Camundu. Nepotřebuješ mít vehementně 2 stavy. Nepotřebuješ mít vehementně na všechno stav. Jenom na věci které jsou nevyhnutelně nutné.

Re:Zkušenosti s orchestrátorem Camunda
« Odpověď #9 kdy: 17. 05. 2023, 12:54:55 »
Nikdo se přeci nechytil, asi jen ty sám. Psal jsem že lze řešit sekvenčně. Ale pokud chceš mít workflow, které nemá blokující tasky, tak workflow engine a BPM ti nabízí jak to snadno modelovat a udržovat. Pokud je to dlouhoběžící proces tak můžeš mít dávno splněný jeden task1 a čekat na dokončení jiného dlouho běžícího tasku. Mezi tím, ale může běžet další větve, které byly na task1 závislé. Jasně že to můžeš všechno dělat sekvečně, můžeš se klidně vrátit 80 let nazpět, kdy se všechno dělalo sekvenčně.

Četba: https://www.vdaalst.com/, https://link.springer.com/book/10.1007/978-3-662-49851-4
   
« Poslední změna: 17. 05. 2023, 12:57:05 od uetoyo »

Re:Zkušenosti s orchestrátorem Camunda
« Odpověď #10 kdy: 17. 05. 2023, 13:26:04 »
Jsem rád, že se někdo chytil. Takže, obojí

- kontrola výrobku
- kontrola dokumentace

Můžeš sloučit do jediného stavu:

- kontrola

Na to nepotřebuješ mít Camundu. Nepotřebuješ mít vehementně 2 stavy. Nepotřebuješ mít vehementně na všechno stav. Jenom na věci které jsou nevyhnutelně nutné.
Pokud kontrolu vyrobku a kontrolu dokumentace provadeji ruzni lide - coz typicky ano,
je souceni do jednoho tasku velice nevhodne, ba primo hloupe.

Re:Zkušenosti s orchestrátorem Camunda
« Odpověď #11 kdy: 17. 05. 2023, 13:50:50 »
Citace
registrovany123 když o tom přestaneš přemýšlet jako o stavovém stroji a začneš to vnímat jako to, co to je tj. procesní engine, tak sám vymyslíš 1000+1 paralelních procesů s praktickým využitím.

A k čemu ti ten procesní engine je? Jako vývojářovi ne moc co k čemu. Jediné využití je pro operátory. Vývojáři to nepotřebují, těm to jenom komplikuje práci a to tak, že dost. Je to pro enterprise, a tam jsem viděl validní use case možná jen u bank - a to kdoví jestli.
« Poslední změna: 17. 05. 2023, 13:52:28 od registrovany123 »

Re:Zkušenosti s orchestrátorem Camunda
« Odpověď #12 kdy: 17. 05. 2023, 13:58:14 »
Pokud kontrolu vyrobku a kontrolu dokumentace provadeji ruzni lide - coz typicky ano,
je souceni do jednoho tasku velice nevhodne, ba primo hloupe.

Ale prdlajz, pokud budu vyvíjet microservice a nemám požadavek na to, aby nějácí operátoři viděli flow graficky - protože ještě se může obsluha taky dívat do logu - tak nepotřebuju mít Camundu jenom proto, že mám někde 2 paralelně běžící úkony.

Stačí když mám stav v Enumu

KONTROLA

A když je dodáno potvrzení od oněch 2 lidí, tak můžu přejít do dalšího stavu.

Ale to člověk co si komplikuje život Camundou dost možná těžko pochopí a uvidí.

Vlastně ani ta to nutně 1 stav mít nepotřebuju, stačí mi k tomu atributy té entity:

Vyrobek {
  "kontrolaVyrobku": {"zodpovednaOsoba": "Franta Kumunda", "datumProvedeni": "2023-01-01"},
  "kontrolaDokumentace": null
}

A opět nepotřebuju v mojí microservice zas* Camundu.
« Poslední změna: 17. 05. 2023, 14:04:32 od registrovany123 »

Re:Zkušenosti s orchestrátorem Camunda
« Odpověď #13 kdy: 17. 05. 2023, 14:03:39 »
@registrovany123

Jsi vážně tak omezený? Workflows jsou všude, nemusí to být jen enterprise Java projekt.
Bioinformatika v tom má např. velký  angažmá... https://www.commonwl.org/
BPM sice vzniklo pro enterpise, ale ... např. https://www.researchgate.net/figure/The-mapping-between-BPMN-and-Petri-nets_tbl2_221250389. Ano, banky na to asi mají ideální prostředí. Co vím ING má ve Scale něco podobného jako Camunda, ale postavené právě nad Petriho sítěmi.
« Poslední změna: 17. 05. 2023, 14:06:43 od uetoyo »

Re:Zkušenosti s orchestrátorem Camunda
« Odpověď #14 kdy: 17. 05. 2023, 14:05:45 »
Pokud kontrolu vyrobku a kontrolu dokumentace provadeji ruzni lide - coz typicky ano,
je souceni do jednoho tasku velice nevhodne, ba primo hloupe.

Ale prdlajz, pokud budu vyvíjet microservice a nemám požadavek na to, aby nějácí operátoři viděli flow graficky - protože ještě se může obsluha taky dívat do logu - tak nepotřebuju mít Camundu jenom proto, že mám někde 2 paralelně běžící úkony.

Stačí když mám stav v Enumu

KONTROLA

A když je dodáno potvrzení od oněch 2 lidí, tak můžu přejít do dalšího stavu.

Ale to člověk co si komplikuje život Camundou dost možná těžko pochopí a uvidí.

Vlastně ani ta to nutně 1 stav mít nepotřebuju, stačí mi k tomu atributy té entity:

Vyrobek {
  "kontrolaVyrobku": "OK",
  "kontrolaDokumentace": "OK"
}

A opět nepotřebuju v mojí microservice zas* Camundu.

No jo, tak pokud nám tu chceš ukázat jak nepotřebuješ Camundu, tak to jo. Já třeba nepotřebuju snídat. Někdo jinej ano.

Navíc, ty si fakt nevidíš na špičku nosu: "A když je dodáno potvrzení od oněch 2 lidí, tak můžu přejít do dalšího stavu."
Takže musíš někde udržovat indormaci v jakém stavu task1/2 je a pak jdeš dále... gratuluji, přesně to za tebe bude dělat ten engine -- error handling atd. si budeš řešit zase sám. Pokud nepotřebuješ nic velkého, OK, ale jinak přesně na tohle vznikají enginy.
« Poslední změna: 17. 05. 2023, 14:11:05 od uetoyo »