İş Akışı Motorunun kullanım örnekleri

Sizin - SO okuyucusunun - İş Akışı Motorlarını kullanarak çözdüğünüz belirli problemleri ve kendinizinkini oluşturmadıysanız hangi kitaplıkları / çerçeveleri kullandığınızı bilmek istiyorum. Ayrıca, bir İş Akışı Motorunun ne zaman en iyi seçim olmadığını ve durum makinelerini kullanan TaskList / WorkList / Task-Management tipi uygulama gibi daha basit bir şeyi / nasıl seçtiğinizi bilmek isterim.

Sorular:

• Çözmek için iş akışı motorlarını hangi sorunları kullandınız?
• Hangi kitaplıkları / çerçeveleri kullandınız?
• Sistem gibi daha basit bir Durum Makinesi / Görev Yönetimi ne zaman yeterli oldu?
• Bonus: Görev Yönetimi ve İş Akışı Motoru arasındaki ayrımı nasıl yaptınız / yaptınız ?

İlk elden deneyimler arıyorum.

Kontrol ettiğim kaynaklardan bazıları:

• Ruote and State Machine! = İş Akışı Motoru
• StonePath ve Docs
• Oracle ile İş Listesi Görev Planları Oluşturma ve Yönetme
• Bir İş Akışı Motorunun Tasarımı ve Uygulanması - Tez
• Windows Workflow Foundation Ne İçin Kullanılır?
• JBoss jBPM Belgeleri

Ben de önyargılıyım, çünkü StonePath'in ana yazarı benim .

ABD Dışişleri Bakanlığı, Cenevre İnsani Madencilik Merkezi, birkaç servet 500 müşteri ve en son olarak Washington DC Devlet Okul Sistemi için iş akışı uygulamaları geliştirdim. İş süreçleri için tek ana referans olmaya çalışan bir 'iş akışı motoru' gördüğümde, bu araç etrafında çalışmak için kendi kendisiyle savaşan bir organizasyon gördüm. Bunun nedeni, bu çözümlerin her zaman satıcı / ürün odaklı olması ve ardından uygulamayı sürekli olarak besleyen taktik bir 'danışmanlar' ekibiyle sonuçlanması olabilir ... ancak bu nedenle, 'iş akışı tanımlarını tek bir yerde merkezileştirme ve tekrarlanabilir hale getirme' sözü veren süreç tabanlı araçların faydaları.

Bununla birlikte, Ruote'u çok seviyorum - Bu projeyi bir süredir takip ediyorum ve bu tür bir çözüme ihtiyacım olursa, denemeye istekli olacağım bir sonraki araç olacak. StonePath'in ruote'tan çok farklı bir amacı vardır - burada Ruote genel olarak Ruby için yararlıdır, StonePath Ruby'de yazılmış web çerçevesi olan Rails'e yöneliktir. Ruote'un uzun ömürlü iş süreçleri ve bunlarla ilişkili tanımlarla ilgili olduğu yerlerde StonePath, Eyalet tabanlı iş akışını ve görevlendirmeyi yönetmekle ilgilidir. Açıkçası, dışarıdan bakmanın ince olabileceğini düşünüyorum - çoğu zaman aynı türden iş süreçleri her iki şekilde de temsil edilebilir - durum ve görev temelli model zihinsel modelime uyma eğilimindedir.

Eyalet tabanlı bir iş akışının önemli noktalarını anlatmama izin verin. Kısacası, ipotek kredisi veya pasaport yenileme gibi bir şeyin işlenmesi etrafında dönen bir iş akışı hayal edin. Belge 'ofis içinde' hareket ettikçe, eyaletten eyalete geçer. Belgeden sorumlu olduğunuzu ve patronunuzun birkaç saatte bir durum güncellemesini istediğini ve kısa bir cevap istediğini düşünün ... "Veri girişinde" gibi şeyler söyleyeceksiniz ... "Kontrol ediyoruz başvuranın kimlik bilgileri şimdi "..." kalite incelemesini bekliyoruz "..." Bitirdik "... vb. Bunlar, duruma dayalı bir iş akışındaki durumlardır. "Onay", "uygula", geri tepme "," reddet "gibi geçişler aracılığıyla durumdan duruma geçiyoruz. Bunlar eylem fiilleri olma eğilimindedir.

Durum / görev tabanlı iş akışının sonraki bölümü, görevlerin oluşturulmasıdır. Görev, bir iş öğesini (örneğin, kredi başvurusu veya pasaport yenileme) bir kullanıcıya "kutuda" bir kullanıcıya bağlayan, genellikle bir son tarih ve işlem talimatları içeren bir iş birimidir. Görevler birbirine paralel veya sıralı olarak gerçekleşebilir ve durumlara girdiğimizde görevleri otomatik olarak oluşturabiliriz, insanlar yapılması gereken işlerin farkına vardığında görevleri manuel olarak oluşturabilir ve yeni bir duruma geçmeden önce görevlerin tamamlanmasını gerektirebiliriz. Bu tür davranışların tümü isteğe bağlıdır ve iş akışı tanımının bir parçasıdır.

Tavşan deliği bundan çok daha derinlere inebilir ve bununla ilgili Pragmatic Programmer's Magazine PragPub'ın 4. Sayısı için bir makale yazdım. Söz konusu makalenin güncellenmiş bir PDF'si için yukarıdaki reo bağlantısına bakın.

Son birkaç aydır StonePath ile çalışırken, durum tabanlı modelin dinlendirici web mimarileriyle gerçekten iyi eşleştiğini gördüm - özellikle görevler ve durum geçişleri iç içe geçmiş kaynaklar olarak güzel bir şekilde eşleşiyor. Benden bu konuda gelecek yazıyı görmeyi bekleyin.

Önyargılıyım, berbat yazarlardan biriyim .

varyant 1) bir kaynağa bağlı durum makinesi (belge, sipariş, fatura, kitap, mobilya parçası).

varyant 2) görev adlı sanal bir kaynağa bağlı durum makinesi

varyant 3) iş akışı motoru iş akışı tanımlarını yorumlama

Şimdi sorunuz "BPM" etiketli, "İş Süreçleri yönetimi" olarak genişletilebiliriz. Her bir varyantta bu tür bir yönetim nasıl gerçekleşir?

1. varyantta, iş süreci (veya iş akışı) uygulama içinde dağınıktır. Kaynağa bağlı durum makinesi, iş akışının bazı yönlerini uygular, ancak yalnızca kaynakla ilgili olanları uygular. Aynı iş sürecini izleyen kendi durum makinesine sahip başka kaynaklar da olabilir.

2. varyantta, iş akışı görev kaynağı etrafında yoğunlaştırılabilir ve bu kaynak etrafındaki durum makinesi tarafından temsil edilebilir.

3. varyantta, iş akışı, iş akışı tanımı (veya iş süreci tanımı) olarak adlandırılan bir kaynak yorumlanarak yürürlüğe konulur.

İş süreci değiştiğinde ne olur? İş süreçlerinin yönetilebilir kaynaklar olduğu bir iş akışı motoruna sahip olmaya değer mi?

Durum makinesi kitaplıklarının çoğu 1 set durum + geçişe sahiptir. İş akışı motorları, çoğu iş akışı tanım yorumlayıcılarıdır ve birden çok farklı iş akışının birlikte çalışmasına izin verir.

İş akışını değiştirmenin maliyeti ne olacak?

Varyantlar birbirini dışlamaz. Bir iş akışı motorunun, bazıları durum makineleri tarafından korunan birden çok kaynağın durumunu değiştirdiği birçok örnek gördüm.

Ayrıca insan görevleri için varyant 3 + 2'yi çok kullanıyorum: iş akışı motoru, bir süreç vakasını çalıştırırken bazı noktalarda bir insan katılımcıya bir görev (iş öğesi) verir (kaynak görevi oluşturulur ve 'hazır' durumuna getirilir) .

Yalnızca varyant 2 ile uzun bir yol kat edebilirsiniz (görev yöneticisi varyantı).

Durum makinesinin, iş akışı motorunun olmadığı ve iş süreçlerinin uygulamada dağıldığı ve / veya kodlandığı 0) varyantından da bahsedebiliriz.

Pek çok soru sorabilirsiniz, ancak cevapları okumak için zaman ayırmazsanız ve denemek ve denemek için zaman ayırmazsanız, çok ileri gitmezsiniz ve ne zaman kullanacağınız konusunda asla yetenek kazanamazsınız bu veya bu araç.

Üzerinde çalıştığım önceki bir projede, Healhcare endüstrisindeki bir dizi Hükümet Formuna bazı İş Akışı türü kuralları ekledim.

Formların son kullanıcı tarafından doldurulması gerekiyordu ve bazı cevaplara bağlı olarak diğer Formların daha sonraki bir tarihte doldurulması planlanıyordu. Ayrıca planlanan Formları iptal eden veya yenilerini planlayan harici etkinlikler de vardı.

Örnek Akış:

Hasta Kabul -> İlk Değerlendirmeyi Planla FOrm -> Üç Aylık İnceleme Formunu Planla -> Hasta Öldü -> İncelemeyi İptal Et -> Taburculuk Değerlendirme Formunu Planla

Diğer birçok kural, Hastanın yaşı, hastaneye yatırıldıkları yer gibi şeylere dayanıyordu.

Bu bir ASP.NET uygulamasıydı, kurallar temelde veritabanındaki bir tablodur. Komut dosyası ekledim, böylece bir komut dosyası, daha sonra ne yapılacağını belirlemek için Form tamamlama üzerinde çalışacaktı. Bu korkunç bir tasarımdı ve uygun bir İş Akışı motoru için mükemmel olurdu.

Yazarlarından biriyim Uber'de geliştirdiğimiz Cadence Workflow Engine'in . Cadence ile mevcut iş akışı motorlarının çoğunluğu arasındaki fark, geliştirici odaklı olması ve son derece esnek ve ölçeklenebilir olmasıdır (saniyede on binlerce güncellemeye ve milyarlarca açık iş akışına kadar). İş akışları, nesne yönelimli programlar olarak yazılır ve motor, ana bilgisayar arızaları durumunda iş parçacığı yığınları ve yerel değişkenler dahil olmak üzere iş akışı nesnelerinin durumunun tamamen korunmasını sağlar.

Çözmek için iş akışı motorlarını hangi sorunları kullandınız? Kadans, tek bir istek yanıtının ötesinde çalışan neredeyse tüm arka uç uygulamaları için kullanılır. Kullanım örnekleri şunlardır:

• Dağıtılmış CRON işleri
• ML / Veri ardışık düzenlerini yönetme
• İş olaylarına tepki verme. Örneğin Uber'deki gezi etkinlikleri. İş akışı, alınan olaylara göre durumu biriktirebilir ve gerektiğinde etkinlikleri yürütebilir.
• Mesos / Kubernetes'e Servis Dağıtımı
• CI Boru Hattı uygulaması
• Bir talep alındığında birden fazla hizmet çağrısının tamamlanmasını sağlamak. SAGA model uygulaması dahil
• İnsan çalışan görevlerini yönetme (Amazon MTurk'e benzer )
• Medya işleme
• Müşteri Desteği Bilet Yönlendirme
• Sipariş düzenleniyor
• ChaosMonkey'e benzer test hizmeti

Ve bircok digerleri

Diğer kullanım senaryoları, mevcut iş akışı motorlarının Cadence üzerinde çalıştırılmasına dayanır. Pratik olarak, herhangi bir motor iş akışı belirtim dili, Cadence üzerinde çalışacak şekilde taşınabilir. Taşınan birden fazla dahili Uber sistemi var. Bu şekilde, tek bir arka uç hizmeti, birden çok etki alanına özgü iş akışı sistemini güçlendirebilir.

Hangi kitaplıkları / çerçeveleri kullandınız?

Cadence, Go with Go ve Java istemci tarafı kitaplıklarında yazılmış bağımsız bir hizmettir . Tek harici bağımlılık depolamadır. Cassandra ve SQL veritabanları desteklenmektedir.

Cadence ayrıca eşzamansız bölgeler arası (AWS terminolojisini kullanarak) çoğaltmayı da destekler.

Sistem gibi daha basit bir Durum Makinesi / Görev Yönetimi ne zaman yeterli oldu?

Uber içinde Cadence hizmeti ekibimiz tarafından yönetilmektedir. Bu nedenle, herhangi bir özel durum makinesi / görev yönetimi oluşturmanın ek yükü her zaman Cadence kullanmaktan daha yüksektir. Şirket dışında bunun için hizmet ve deponun kurulması gerekir. Zaten bir SQL veritabanınız varsa, hizmet dağıtımı bir docker görüntüsü aracılığıyla önemsizdir. Docker ayrıca kişisel bir bilgisayar veya dizüstü bilgisayarda geliştirme için yerel bir Cadence hizmetini çalıştırmak için kullanılır.

Rails_workflow gem'i kontrol edin - Bunun aradığınız şeye yakın olduğunu düşünüyorum.

Imixs-Workflow'un yazarlarından biriyim . Imixs-Workflow, BPMN 2.0 tabanlı açık kaynaklı bir iş akışı motorudur ve Java EE teknoloji yığınına tam olarak entegre edilmiştir.
10 yılı aşkın süredir iş akışı motorlarını kendim geliştiriyorum. Sorunuza kısaca cevap vermeye çalışacağım:

> Hangi sorunları çözmek için iş akışı motorlarını kullandınız?

İş akışı motorları hakkında düşünmeye başladığımda kişisel hedefim, uygulamamdaki iş mantığını sert bir şekilde kodlamaktan kaçınmaktı. Bir iş uygulamasındaki birçok şey yeniden kullanılabilir, bu nedenle yapılandırılabilir durumda tutmak mantıklıdır. Örneğin:

• bir bildirim göndermek
• açık görevleri görüntüle
• bir kişiye bir görev atandı
• mevcut görevi açıklamak

Bu işlev listesinden insan merkezli iş akışlarından bahsettiğimi görebilirsiniz. Kısaca: İnsan merkezli bir iş akışı motoru şu soruları yanıtlıyor: Bir görevden kim sorumlu ve bundan sonra kim bilgilendirilmeli? Ve bunlar iş gereksinimlerindeki tipik sorulardır.

> Hangi kitaplıkları / çerçeveleri kullandınız?

5 yıl önce, BPMN 2.0'a odaklanan Imixs-Workflow motorunu yeniden uygulamaya başladık . BPMN, süreç modelleme için ortak standarttır. Ve benim için şaşırtıcı olan şey, görselleştirilebilen ve yürütülebilen son derece karmaşık iş süreçlerini bile aniden tanımlayabilmemizdi. Herkese iş süreçlerini modellemek için BPMN kullanmasını tavsiye ediyorum.

> Sistem gibi daha basit bir Durum Makinesi / Görev Yönetimi ne zaman yeterli oldu?

Bir iş nesnesinin durumunu izlemek istiyorsanız basit bir durum makinesi yeterlidir. Nesne modelinize "durum" özniteliğini eklemeye başladığınız zaman bu durum söz konusudur. Ancak sorumluluklar, kayıt tutma ve akış kontrolü içeren iş süreçlerine ihtiyacınız varsa, o zaman bir durum makinesi artık yeterli değildir.

> Bonus: Görev Yönetimi ve İş Akışı Motoru arasındaki ayrımı nasıl yaptınız / yaptınız?

Bu tam olarak burada bahsedilen birçok iş akışı motorunun farklı olduğu noktadır. İnsan merkezli bir iş akışı için, görevleri insan aktörler arasında dağıtmak için genellikle bir görev yönetimine ihtiyacınız vardır. Bir proses otomasyonu için bu nokta pek alakalı değildir. Motorun belirli görevleri yerine getirmesi yeterlidir. Görev yönetimi ve iş akışı motorları karşılaştırılamaz çünkü görev yönetimi her zaman bir iş akışı motorunun bir işlevidir.

Belgelerin aşamalı olarak işlenmesini desteklemek için kendi iş akışı motorumu kullandım - kataloglama, görüntü işleme için gönderme (redaksiyon sw ile çalışıyoruz), gerekirse doğrulama için gönderme, ardından yayınlama ve sonunda müşteriye geri gönderme. Bizim durumumuzda işlenecek bir kamyon dolusu belgemiz var, bu nedenle bazen teslimatı ve kaynak kullanımını kontrol etmek için her hizmeti ayrı ayrı çalıştırmamız gerekir. Konsept olarak basit, ancak yüksek performans ve dağıtılmış işlem gerekiyor ve bizim için faturaya uygun herhangi bir hazır ürün bulamadık.

Activiti'yi kullanma deneyimim varAğ düğümlerinden oluşan bir altyapıda yüksek performanslı ve yüksek verimli veri aktarım süreçlerini yönetmek için BPMN 2.0 motorunu . Temel görev, bu tür aktarım süreçlerinin konfigürasyonuna ve izlenmesine izin vermek ve her ağ düğümünü kontrol etmekti (yani düğüm 1'den, belirli bir taşıma katmanı aracılığıyla düğüm2'ye bir veri dosyası göndermesini istemek).

Bir seferde çalışan binlerce işlem ve genel olarak günde onbinlerce veya az yüzbinlerce işlem olabilir.

Bir sürü farklı süreç tanımı vardı, ancak bir sistem operatörünün özel iş akışları oluşturabilmesi gerekli değildi. Dolayısıyla, BPM motorunun birincil kullanım durumu, sağlam, ölçeklenebilir ve her işlem akışının izlenmesine olanak sağlamasıydı.

Sonunda temelde işe yaradı, ancak bu projeden öğrendiğimiz şey bir BPMN platformunun veya daha doğrusu Activiti motorunun bu kadar yüksek verimli bir sistem için en iyi bahis olmadığıydı.

Başlıca zorluklar, görev yürütme önceliklendirmesi, DB kilitleme, BPM'nin kendisiyle ilgili birkaç tanesini adlandırmak için yürütme yeniden denemeleriydi. Bu nedenle, bunların özel olarak işlenmesini geliştirmemiz gerekiyordu, örneğin:

• Bir düğümün verilen görev için ücretsiz çalışanı olmadığı veya düğümün hiç çalışmadığı durumlar için BPM'de yeniden denemelerin işlenmesi.
• Paralel transfer görevlerinin tek bir işlemde yürütülmesi ve sonuçların senkronizasyonu (başarı / başarısızlık).

Diğer BPMN motorlarının böyle bir senaryo için daha uygun olup olmayacağını bilmiyorum çünkü BPMN çoğunlukla, performansın bizim durumumuzda olduğu gibi muhtemelen aynı sorun olmadığı kullanıcı etkileşimini içeren uzun süreli iş görevleri için tasarlandı.