Fórum Root.cz
Hlavní témata => Software => Téma založeno: vesterna12 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?
-
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.
-
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.
-
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.
-
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)
-
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.
-
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.
-
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.
-
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é.
-
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
-
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.
-
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.
-
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.
-
@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.
-
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.
-
Jsi vážně tak omezený? Workflows jsou všude, nemusí to být jen enterprise Java projekt.
Omezenec si ty, jsi programator nebo BPMNista? Typicky problem hlupaku, ze pouzivaji nejaky soft a neumi se na ten problem uz divat jinak. Komplikujes si praci. Dobry napsany software zadnou Camundu nepotrebuje. BPMN muze byt nakreslene tak maximalne nekde v dokumentaci pro zakladni orientaci.
Myslis si ze Faceebok nebo Twitter pouziva nejakou pitomou Camundu? Nebo ze Google to pouziva pri registraci noveho uzivatele do Gmailu? Ze tam sedi nejaky vocas a dela diagram v Camunde, misto aby napsali poradne microservices, dali jim dobre API a udelali smysluplne UI?
-
Jsi vážně tak omezený? Workflows jsou všude, nemusí to být jen enterprise Java projekt.
Omezenec si ty, jsi programator nebo BPMNista? Typicky problem hlupaku, ze pouzivaji nejaky soft a neumi se na ten problem uz divat jinak. Komplikujes si praci. Dobry napsany software zadnou Camundu nepotrebuje. BPMN muze byt nakreslene tak maximalne nekde v dokumentaci pro zakladni orientaci.
Myslis si ze Faceebok nebo Twitter pouziva nejakou pitomou Camundu? Nebo ze Google to pouziva pri registraci noveho uzivatele do Gmailu? Ze tam sedi nejaky vocas a dela diagram v Camunde, misto aby napsali poradne microservices, dali jim dobre API a udelali smysluplne UI?
To je mi vazne jedno co pouzivaji v Googlu. Camunda/Activity vznikly pro jine ucely. Nedelej ze sebe vola a lepsiho programatora jen proto ze nevyuzijes neco co nekdo ano.
Jo já si taky všechno bastlím sám, ale v doméně, kde si to můžu dovolit. Jiný kraj, jiný mrav.
-
Jsi vážně tak omezený? Workflows jsou všude, nemusí to být jen enterprise Java projekt.
Omezenec si ty, jsi programator nebo BPMNista? Typicky problem hlupaku, ze pouzivaji nejaky soft a neumi se na ten problem uz divat jinak. Komplikujes si praci. Dobry napsany software zadnou Camundu nepotrebuje. BPMN muze byt nakreslene tak maximalne nekde v dokumentaci pro zakladni orientaci.
Myslis si ze Faceebok nebo Twitter pouziva nejakou pitomou Camundu? Nebo ze Google to pouziva pri registraci noveho uzivatele do Gmailu? Ze tam sedi nejaky vocas a dela diagram v Camunde, misto aby napsali poradne microservices, dali jim dobre API a udelali smysluplne UI?
Hele, uz jsi opravdu psal neco v tomto oboru, nebo to jsou jenom plky od stolu?
Protoze to tvoje "reseni" s hardcoded podminkama, znamena, ze az si sponzor produktu vzpomene, ze pokud je Utery a Duben, je potreba pridat kontrolu na aktualni rosny bod - pak se to cely prepise, nakam se naprasi ify a po case vice takovych ifu je lepsi od toho utect.
Ja osobne jsem na obdobne ulohy pouzivaval Drools, kde pak stacila uprava konfigurace a na zbytek se sahat nemuselo.