Jak monitorujete tok dokumentů?

[Rnx]

Existuje řešení pro monitorování toku dokumentů? Neptám se na různé "workflow" CRM/ECM řešení, které pracují s dokumenty v rámci jedné aplikace (příklad - schvalování faktur), ale na monitoring toku, třeba:
1. stažení přes ftp -> 2. konverze z doc na pdf -> 3. podepsání dokumentu -> 4. uložení (zálohování) -> 5. odeslání emailem -> 6. notifikace přes REST API
Jak takový tok monitorovat, pokud každý krok je samostatná apliklace, která má úplně jiné logování, chování atp. Především potřebuji znát jestli všechny dokumenty prošly všemi procesy a vědět který krok jak dlouho trvá (nebo alespoň zjistit celkové trvání zpracování jednoho dokumentu). Napadá vás něco?

[Reklama]

[Wavelet]

Obecně asi pomocí zasílání/publikování zpráv. Co třeba Kafka nebo něco podobného? Myslím, že tohle řeší spousta lidí řešením na míru konkrétnímu procesu, ale rád se si vyslechnu názory ostatních.

[_Tomáš_]

v enterprise světě se tohle dělá v BPM (Business process management), často tyhle SW mají vystřčené api, přes které změny uvozuješ.

Tohle si ale můžeš implementovat na koleni, tabulka v databázi, api nebo webové rozhraní pro práci s tím a zanášení změn. Pokud to ale potřebuješ implementovat do tvého existujícího procesu nebo SW, to bude obtížnější.

Stejně tak se na to dá poměrně dobře použít SW pro ticket, např. Jira, TargetProcess aj., sice k tomu nejsou určeny, ale často takovéhle věci jsou už ve firmách, tak proč použití nerozšířit.

Mrkni třeba na https://github.com/kiegroup/jbpm, https://camunda.com, https://www.joget.org, případně řekni co se ti na tom nezdá a pokusím se vymyslet jiné alternativy.

[Rnx]

Řešení na míru je taky odpověď, jenomže jak to udělat? Nebo kdo to umí? Jakékoliv reference beru...
Problém, který řeším je množství - třeba i stovky tisíc dokumentů přes den nelze jakkoliv monitorovat "ručně", nebo přes Jiru.
A pak cokoliv co řídí BPM je supr, ale nelze to aplikovat s čímkoliv, třeba SAP nelze zahodit nebo podřídit. Při procesech před dekádou se s tím nepočítalo a teď je už vcelku pozdě, takže změnit podnikové workflow by bylo likvidační, ne-li nemožné.
Potřebuji monitorovat dokumenty, párovat je podle (různých) ID, být notifikován o bottlenecku a umět dohledat jakýkoliv dokument v jakémkoliv kroku. Ideálně i historicky, s retencí třeba rok, celkově jsou to jednotky TB dat v lozích. Setkal se s tím už někdo přímo v praxi?

[listoper]

Asi to neni primo reseni na tvuj problem, ale napada me instana.
Jsou to reseni na monitoring a alerting.
Treba by to slo nejak ohnout pro tvuj ucel.
Videl sem to pouzity a docela pekne se v tom dalo proklikat cele flow prez nekolik systemu.
Nevim jestli podporujou i SAP a asi to nebude uplne levna zalezitost...
Funguje to tak, ze se do systemu ktery chces monitorovat instalujou agenti a ty pak hlasi udalosti do nejaky centralni databaze ze ktery se pak sklada to webovy klikatko.

Existujou i dalsi.... ale instanu mam v zive pameti.
Tu retenci tam meli nastavenou jen na 7 dni... ale to jde asi zmenit... podle toho kolik dat ti budou ty agenti chrlit...

[Reklama]

[Wavelet]

Problém opravdu nastává, pokud je to nějaký heterogenní systém. Musíš být schopný buď ty jednotlivé procesy (tasky) obalit a koordinovat skrze jiný systém (viz ty BPM) nebo do každého toho programu nějak zakomponovat aby po dokončení publikovali nějakou zprávu na kterou zas jiná část systému může reagovat. Já myslím, že řešíš problém za které si hodně firem nechá draze platit, protože tohle zavádět do existujícího komplexního enterprise  řešení, právě jak ty píšeš, je těžké.

[_Tomáš_]

v tom případě ale musíš počítat s podporou/integrací SW, který teď používáš na zpracování dokumentů, to nelze udělat bez toho. Pokud chceš poradit, musíš tady popsat svoji infrastrukturu a tok dokumentů, podle toho se musí vybrat vhodný nástroj, vhodná integrace a postavit nad tím dohledové workflow.

TB dat nejsou problém, vše záleží jaké vlastní střednědobé náklady očekáváš a kolik do toho chceš investovat. Lze jít cestou vlastního vývoje, dokoupením modulů (na SAP je možné navázat ledacos) nebo pořízením nezávislých aplikací, které budou čerpat data vedlejšími kanály (z logů, api, přímo z databází, ze samotných souborů atd.).

Zkušenosti mám z bankovního sektoru, tam se ale vše řeší kanónem za neskutečné peníze.

[KorporatniLopata]

Je to dost vágní otázka, ale asi by to chtělo zabalit ty dokumenty do zpráv, které mají i nějaká metadata: unikatní id, verzi a stav a payloadem bude vlastní dokument. Posílat ty zprávy přes nějakej messaging a monitoring se příhlásí k odběru na jednotlivých translacích. Pak už se dá snadno dohledat, že systém A publikoval zprávu 1, ale systém B, který ji měl zkonzumovat, transformovat a poslat dál už to neudělal. 
Děláme tohle v bance, ale máme vlastní řešení.

[_Tomáš_]

Je to dost vágní otázka, ale asi by to chtělo zabalit ty dokumenty do zpráv, které mají i nějaká metadata: unikatní id, verzi a stav a payloadem bude vlastní dokument. Posílat ty zprávy přes nějakej messaging a monitoring se příhlásí k odběru na jednotlivých translacích. Pak už se dá snadno dohledat, že systém A publikoval zprávu 1, ale systém B, který ji měl zkonzumovat, transformovat a poslat dál už to neudělal. 
Děláme tohle v bance, ale máme vlastní řešení.

osvědčilo se mi naopak dokumenty nebalit do samotné zpráv (oni některé mohou být opravdu dost velké a víme jaké mají messaging systémy omezení na velikost), ale opatřit elektronickým podpisem/časovým razítkem, které daná metadata nese, je to poté i poměrně transparentní pro uživatele, protože v rámci samotného dokumentu již vše potřebné vidí.

Pokud není možné připojovat podpis do dokumentu (ne všechny formáty to umožňují), stačí jen držet hash a jméno daného dokumentu a ten mít poté uložení v jakémkoliv uložišti. Při jeho zveřejňování je ale nutné vždy ověřit jeho stav a podle toho se zařídit, to zase ne všechny systémy dobře umí.

Banky běžně dokumenty jako jsou smlouvy, výpisy, scoring informace drží jako bloby (často šifrované) a dále pracují pouze s hashem daného dokumentu, ten i prochází různými workflow, přenášet přes roury samotný dokument moc často nevídám, ale víme jak ty systémy jsou diverzifikované, takže asi i tahle varianta někoho napadla.

[Rnx]

Díky za hinty a postřehy, doufám, že mě posunuly správným směrem.