İş akışı motorları ne zaman kullanılır?


41

Geçmişte bazı iş akışı motorlarında programcı olarak çalıştım ancak iş akışı motorlarını neden ilk başta seçtiğimize dair hiçbir netlik yoktu. Ve programcı olarak kod yazarken bir şey yapmanın en az 100 yolu olduğunu biliyorum, ancak yöntemlerden yalnızca birkaçı en iyisi!

Hangi kullanım durumlarının, iyi bir DI özellikli uygulama tasarlamadan ziyade iş akışı motorları (veya onların konsepti) ile en iyi şekilde çözüldüğünü hala anlamıyorum. İş akışı motorlarının en iyi seçeneklerden biri olduğu etki alanı-nötr kullanım durumlarının genel özelliklerini arıyorum.

Öyleyse sorum şu: İyi bir iş akışı motorunu seçmek ve etrafını kodlamak için bir sinyal olarak alınabilecek bir gereksinimin genel özellikleri nelerdir?


1
"DI etkin uygulama" nedir?
jnewman

Bağımlılık enjeksiyonuna karar verdim, ama biraz ağır düşünmeye başladı ...
jnewman

1
@ JasonTrue Oh, siz de Windows Workflow Foundation'ı kullandınız!
Gilles

@Gilles nasıl söylersin? : P
JasonTrue

Yanıtlar:


22

Bir iş akışı motoru, başlangıçtan bitişe gitmeniz gerektiğinde kullanışlıdır, ancak oraya ulaşmak için birçok farklı yol / mantık / kural vardır.

Örneğin, içerik yayınlayan bir program yazdığımı varsayalım. Bu nedenle, benim durumumda, yayınlama yasal ve ardından nihai onay sürecinden geçiyor. İşlem mantığımı ve adımları uygulayan programı yazıyorum. Şimdi bu iş benim ve şirketim için harika. Bu yüzden başkalarının programımı kullanması gerektiğine karar verdim.

Ne yazık ki, herkes aynı işlemi kullanarak içerik yayınlamaz, bu nedenle her bir farklı durum için ayrı işlemler yazmak yerine, bir iş akışı süreci uygularız, böylece program herkesi ağırlamak için esnek olur. Bu iki nokta arasında kaç adım, kural veya mantık olursa olsun sonuç aynıdır.

Bu nedenle, baştan sona değişken olan işlemleriniz varsa, bir iş akışı kullanın. Aynı işlem herkes tarafından da kullanılabilirse, bir iş akışına ihtiyacınız yoktur.


Fakat bu gerçek dünyaya nasıl bağlanıyor? Örneğin bir statechart'a göre "işlem kayıtları" izleme durumunu içeren bir veritabanına sahip olabilirsiniz , ancak daha sonra kullanıcı arayüzlerini ve uyarıları kodlamanız, mesajlaşma sistemleri üzerinden I / O mesajı, ETL işleri vb. Bir iletişim merkezinin ortasına doğru ilerleyin ve çalıştırın. "İş akışı motoru", statechart'ı kurmanın ve "çalıştırmanın" süslü bir yolu mu?
David Tonhofer

@David - Bir ölçüde, evet.
Jon Raynor

19

Kullanım durumları istediğinizi biliyorum, ancak tüm olası kullanım durumlarını hayal etmekten daha avantajlı olanları listelemek daha kolay. Elbette avantajları karşılaştırdığınız motor ve dile bağlıdır, fakat genel olarak:

  1. Kuralları kod yerine veri olarak tutmak, yeniden derlemek zorunda olmadığınız anlamına gelir; bu nedenle değişiklikleri hızlı bir şekilde test edebilir, çalışma zamanında değişiklik yapabilirsiniz, vb.

  2. Kullanıcıların kuralları daha makul bir şekilde düzenlemesi beklenebilir. Potansiyel olarak onlarla etkileşimli olarak, programcıların kendileri için kod yazmasını mümkün kılmayan şekillerde çözebilirler.

  3. Kuralları veri olarak tutmak, araçları görselleştirmek ve verileri değiştirmek için yazılmasına izin verir.

  4. Kuralları veri olarak tutmak meta-programlamaya daha kolay olanak sağlar - verileri analiz etmek için kod yazabilir ve daha karmaşık bir şekilde ekleyebilirsiniz; bu kod için çok zor olacaktır.

Bunların hepsinin doğrudan kodla yapılması mümkündür (örneğin - belirli bir türün tüm kurallarını bulmak ve daha fazla kural için kod üretmek için bir C # ayrıştırıcısı yazın, bunu bir montajın boşaltılması, araçların yazılması için bir araç içine dinamik olarak yerleştirin. görselleştiricinizi ve editörünüzü kullanarak bunu yapabilmek için kullanıcılar) ancak dilinize bağlı olarak çok daha zor olabilir (Lisp kullanan programcılar 1-4 maddelerini "programlama" olarak belirtebilir).


5
Bunların hiçbiri aslında her büyüklükteki makul derecede karmaşık bir projede bir avantaj değildir. Yeterli test veya dokümantasyon olmadan, üretken ortama atılan başkasının kurallarını sonsuz bir şekilde "hata ayıklama" olarak bulacaksınız.
James Anderson

Lisp referansı için +1 - kod veridir ve bunun tersi de geçerlidir.
Michael H.

2
@JamesAnderson: müşteri dışında, yazılım satıcısına bir destek davası açmak zorunda kalmadan kendi kurallarını gidermek için artık programcı olmayanlara (iş akışı danışmanları) ödeme yapabilir.
rwong

3

IMHO SADECE bu tür şeyleri kullanmanız gereken durum, daha az değerli kullanıcılar tarafından yapılandırılabildiği zaman. Sorununuzu onlara bir araç vererek çözebilirseniz, daha önemli bir şey üzerinde çalışmaya geri dönün, sonra bir tane kullanın.

Eğer hala onlar için ayarlamanız gerekiyorsa, o zaman aşina olduğunuz bir araçla aynı sonucu almanın 10 farklı yoldan olduğunu düşünebileceğinizi ve desteklemesi ve özelleştirmesi çok daha kolay olacağını düşünebilirim.


3

Bu eski bir soru gibi görünüyor, ancak vahşi doğada defalarca yüzeye çıkıyor. Jon'un cevabına katılıyorum . İş akışı motorlarını aşağıdaki senaryolarda oldukça üretken buldum:

  1. Yazılımınız aracılığıyla temsil etmeye / uygulamaya çalıştığınız temel bir iş süreci vardır.
  2. Sürecin tüm aşamalarında veya bazılarında üzerinde çalışılmış, tek bir (belki de karma) iş varlığı var. Jon'un verdiği örnekte, bu varlık veya İş Akışı Öğesi içerik veya bir makale olabilir. Hata izlemeyi, bir kullanıcının gerçekleştirdiği bir eyleme dayalı olarak çeşitli durumlar arasında geçiş yapan bir iş akışının başka bir örneği olarak düşünün.
  3. İşlemlerinizi modellemek için İş Akışlarını kullanın, yalnızca iş sürecinin değişmesini beklerseniz, değişiklik yaparak, bir kullanıcı eylemi veya geçişi sonucunda gerçekleştirilen sıralama veya eylemi kastediyorum.

Sorunlu alanınızın / gereksinimlerinizin bir iş süreci olup olmadığını görmek için çok dikkatli olun ve eleştirel olun, iş akışına "sığdırmaya" çalışmayın.


Bu cevaptan hoşlandığım şey, sürecinizi "modelleme", yani bir beyaz tahta üzerine çizim bölümü. Bir iş akışı motorunun uygulanıp uygulanmayacağını (bu cevaplardaki önerilere göre) büyük ölçüde göstereceğini düşünüyorum
dave thieben

1

İş akışı motorlarını önermek için kullandığım birkaç yönergem var.

1) İş analistlerinin kodlama altyapısı yoksa, diyagram çizebilirler.

Modern iş akışı motorları, iş süreci modelleme gösterimini veya SharePoint ve benzeri sistemlerde bulunan daha az yetenekli sürümleri kullanır. Bunlar, teknik olarak yetkin ancak kodlamaya zorlanan ekibin birçok iş akışını tasarlamasına ve geliştirmesine olanak tanır.

2) İşin ilerlemesini izlemeniz gerektiğinde, yürüyen merdivenler uygulayın, bilgisayar kontrollü işlemler ve insan kontrollü işlemler arasında ileri ve geri geçin.

İzleme ve öz referans, modern iş akış motorlarının ayırt edici özellikleridir.


-2

İnsan kaynakları iş açısından bakıldığında, iş akışı motorları çok önemlidir.

  1. Her seferinde aynı olsa bile, yapısal bir süreç sağlarlar.
  2. Şeffaflık sağlarlar

    • Değişikliği kim istedi?
    • Ne zaman istendi
    • Kim onayladı vs.

    Bu şeffaflık süreci yönlendirmeye yardımcı olur ve mülkiyeti teşvik eder.

Formların entegre ve zeki olduğunu varsayarsak, iş mantığını destekler, aynı zamanda zaman çizelgesi, işlem verimliliği ve veri kalitesi üzerinde çarpıcı bir etkiye sahiptir. Güvenlik de dikkate alınmalıdır ve güvenli bir sistemde hassas bilgilerin bulunması, imzalanmayı beklerken etrafta duran kağıt formlara sahip olmaktan daha çok tercih edilir. Aynı zamanda çok daha mobil. Son bir uygulamadan sonra, bir yönetici bana, çok seyahat ederken imzaladığı için kendisine bir şeyleri göndermesiyle ilgili çok fazla güçlük kazandırdığını söyledi.

İK adına: Yaşasın iş akışı !!!

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.