İş Akışına mı İş Akışına mı?

Hafif bir sigorta talep sistemi geliştirmeye başlamak üzere olan bir geliştirici ekibinden sorumluyum. Sistem, çok sayıda manuel görev ve iş akışı içerir ve Windows Workflow (.NET 4.0) kullanmaya bakıyoruz.

İş alanına bir örnek aşağıdaki gibidir: Bir poliçe sahibi, bir talepte bulunmak için iletişim merkezini arar. Bu "olay", paralel olarak manüel olarak gerçekleştirilen ve tamamlanması uzun sürebilen iki alt görevi ateşler;

1. Müşteriyi dolandırıcılık açısından kontrol edin - Bir operatörün, dolandırıcı bir müşterinin potansiyelini kontrol etmek ve değerlendirmek için çeşitli kredi şirketlerini aradığı manuel bir süreç. Buradan, alt görev bir dizi alt durum girebilir (Devam ediyor, Başarısız Referans Kontrolü, Başarılı Referans Kontrolü, vb.)
2. Ürünü onarım merkezine gönder - Poliçe sahibinin hak talebinde bulunduğu öğenin düzeltilmesi için onarım merkezine gönderildiği manuel bir süreç. Buradan, alt görev bir dizi alt durum girebilir (Onarım Bekleniyor, Devam Ediyor, Onarıldı, Gönderildi, vb.). Talep, yalnızca her bir alt görevin durumu önceden tanımlanmış bir duruma ulaştığında (iş kurallarına göre) devam edebilir.

Görünüşte İş Akışı gerçekten de en iyi teknoloji seçimi gibi görünüyor; ancak WF 4.0 kullanımıyla ilgili birkaç endişem var.

1. Beceri seti - Ortalama geliştirici beceri setine baktığımda, Workflow'u anlayan veya bilen pek çok geliştirici görmüyorum.
2. Sürdürülebilirlik - Topluluk içinde WF 4.0 projeleri için çok az destek var gibi görünüyor ve bu, beceri setinin eksikliği ile birleştiğinde, sürdürülebilirlik konusunda endişeler uyandırıyor.
3. Giriş engeli - Windows Workflow'un dik bir öğrenme eğrisine sahip olduğunu ve bunu algılamanın her zaman o kadar kolay olmadığını hissediyorum.
4. Yeni ürün - İş Akışı tamamen .NET 4.0 için yeniden yazıldığından, ürünü birinci nesil bir ürün olarak görüyorum ve gerekli kararlılığa sahip olmayabilirim.
5. İtibar - İş Akışı'nın önceki sürümleri iyi karşılanmadı, geliştirilmesinin zor olduğu düşünülüyordu ve kötü iş alımıyla sonuçlanıyordu.

Öyleyse sorum şu, bu durum için Windows Workflow (WF) 4.0 kullanmalı mıyız yoksa kullanılacak alternatif bir teknoloji (örn. Basit Durum Makinesi , vb.) Veya hatta daha iyi bir iş akışı motoru var mı?

Birkaç WF4 projesi yaptım, bu yüzden diğer cevaplara herhangi bir yararlı bilgi ekleyip ekleyemeyeceğimi görelim.

İş probleminizin açıklamasına göre, WF4 iyi bir eşleşme gibi görünüyor, bu yüzden orada sorun yok.

Endişelerinizle ilgili olarak haklısınız. Temelde WF4 yeni bir üründür ve bazı önemli özelliklerden yoksundur ve bazı kaba kenarları vardır. Bir öğrenme eğrisi var, bazı şeyleri farklı yapmanız gerekiyor. Ana nokta uzun çalışma ve serileştirmedir; bu, ortalama bir geliştiricinin alışkın olmadığı bir şeydir ve insanların bir varlık çerçeve veri bağlamını serileştirmede sorun yaşadığını çok sık duyduğum için doğru yapmak için biraz düşünmeyi gerektirir.

IIS / WAS'ta barındırılan iş akışı hizmetlerini kullanmak çoğu zaman bu uzun süreli iş akışlarını gerçekleştirirken en iyi yoldur. Bu, sürüm oluşturma sorununu çözmeyi de zorlaştırmaz, sadece ilk mesajın iş akışı sürümünü döndürmesini sağlayın ve bunu sonraki her mesajın bir parçası yapın. Daha sonra WCF yönlendiricisini, iletiyi sürüme bağlı olarak doğru uç noktaya yönlendiren arasına yerleştirin. Temel olan, mevcut bir iş akışını asla değiştirmemek, her zaman yeni bir tane oluşturmaktır.

Peki size tavsiyem nedir? Bilinmeyen ve sizin için kanıtlanmamış bir teknoloji parçası üzerinde büyük bir kumar oynamayın. WF4 kullanarak küçük, kritik olmayan bir uygulama parçası yapın. Bu şekilde çalışırsa genişletebilirsiniz, ancak başarısız olursa onu söküp daha geleneksel .NET koduyla değiştirebilirsiniz. Bu şekilde, ikinci el bilgilere dayalı bir karar vermek zorunda kalmak yerine, WF4 ile gerçek bir deneyim elde edersiniz ve bu süreçte yeni ve güçlü bir teknoloji öğrenirsiniz. Mümkünse WF4 kursuna katılın, çünkü bu size hızlanmak için çok zaman kazandıracaktır (utanmaz kendi kendine fiş burada ).

Basit Durum Makinesi Hakkında. Kullanmadım ama hafızada, durum makinelerinde kısa süre çalıştığı sanıyordum. WF4'ün ana faydalarından biri uzun vadeli yönleridir.

Bu ikileme birkaç kez geldim ve Work Flow Foundation'ı kullanmamayı seçtim. Bazı hususlar (sizinkine benzer) şunlardı:

1. İlgili iş akışları çok daha basitti (durum makinesi ve sıralı eylemlerin bir kombinasyonu) ve bunu WF'de yapmak, dahil olan çabalar için aşırıya kaçıyor gibi görünüyor.
2. Geliştiricilerin WF'yi anlaması ve etkili bir şekilde kullanması için öğrenme eğrisi yüksek kabul edildi. Geçerli geçişleri ve alınacak eylemleri açıklayan durum geçiş tablosu ek esneklik için kullanılır ve geliştiriciler bu konuda rahattır, kavramı ve amacı kolayca anlar.
3. İş süreci değişikliklerinin şansı zayıftı ve temel değişiklikler geçiş tablosu yardımıyla kolayca mümkün oldu. Geçişteki bir değişiklik, bir veritabanı komut dosyası anlamına gelirken, eylemlerdeki değişiklik yeni sürüm / yama ile sonuçlanacaktır. Bununla birlikte, böyle bir gerçekleşme olasılığı düşük kabul edildi.

13-14 ay sonra geriye dönüp baktığımda, hala WF kullanmama kararının doğru olduğunu düşünüyorum. IMO, WF, iş akışının değişebileceği ve / veya iş kurallarının değişebileceğine dair güçlü bir olasılığın olduğu durumlarda anlamlıdır. WF, iş akışını ayrı bir dosyada izole etmeye izin verir ve bu nedenle kullanıcılar tarafından yapılandırılabilir hale getirmek daha kolay olacaktır.

Son birkaç aydır WF 4.0 kullanıyoruz. İş Akışı şeklini düşünmenin zor olduğunu söylemeliyim. Ancak buna değdiğini söyleyebilirim. Başladığımızda çok az şey biliyorduk. WF 4.0 için yardımcı olan yeni başlayan ve profesyonel bir kitap satın aldık. Ben, çevrimiçi olarak birçok video izledim ve PDC 2009'u WF 4.0 hakkındaki son dakika haberleri ve önceki biraz berbat sürümlerden ne kadar farklı olduğu için takip ettim. Bir çözüm önermemiz gereken en önemli şey, özel etkinliklerimizi belirli veri türlerine bağlamadan bir iş akışında İç / Argümanlarımızla başa çıkabilmemiz ve etkinlikler arasında parametrelerin nasıl aktarılacağıdır. Bunun için iyi bir çözüm buldum ve şu ana kadar sahip olduğumuz iş akışı deneyimi hiç de fena değil. Aslında, Giderek büyüyen iş akışı yoğun bir uygulamamız var ve bunu farklı bir ortamda çözeceğimi gerçekten hayal edemiyorum. Sahip olduğu görsel etkiyi seviyorum: if / else etc kurarlarının ayrıntılarından beni uzak tutuyor ve neler olup bittiğini anlamak için sizi kod satırlarına dalmaya zorlamayacak şekilde iş kurallarını belirgin hale getiriyor veya bazı hataların nasıl düzeltileceği. Bu arada, üzerinde çalıştığımız proje anlattıklarınıza çok benziyor ve orta büyüklükte bir proje. Sözlerimden hoşlandığımı söyleyebilirim ve tavsiye ederim, ancak yeni bir teknoloji olduğu için bazı riskler içeriyor ve bazı yenilikçi fikirler üretmeniz gerekiyor. beni if ​​/ else etc inşasının ayrıntılarından uzak tutuyor ve iş kurallarını, neler olup bittiğini veya bazı hataları nasıl düzelteceğinizi bilmek için kod satırlarına dalmaya zorlamayacak şekilde belirgin hale getiriyor. Bu arada, üzerinde çalıştığımız proje anlattıklarınıza çok benziyor ve orta büyüklükte bir proje. Sözlerimden hoşlandığımı söyleyebilirim ve tavsiye ederim, ancak yeni bir teknoloji olduğu için bazı riskler içeriyor ve bazı yenilikçi fikirler üretmeniz gerekiyor. beni if ​​/ else etc inşasının ayrıntılarından uzak tutuyor ve iş kurallarını, neler olup bittiğini veya bazı hataları nasıl düzelteceğinizi bilmek için kod satırlarına dalmaya zorlamayacak şekilde belirgin hale getiriyor. Bu arada, üzerinde çalıştığımız proje anlattıklarınıza çok benziyor ve orta büyüklükte bir proje. Sözlerimden hoşlandığımı söyleyebilirim ve tavsiye ederim, ancak yeni bir teknoloji olduğu için bazı riskler içeriyor ve bazı yenilikçi fikirler üretmeniz gerekiyor.

benim 2 sentim ...

WF 3.5'te üç proje yaptım ve bunun kolay olmadığını söylemeliyim. Özellikle ısrar kullanıldığında sizi yepyeni bir şekilde düşünmeye zorlar. Yüzlerce tamamlanmamış kalıcı iş akışı içeren uygulamayı güncellemek zordur. Serileştirmedeki tek kırılma değişikliği hepsini çöker. Yeni ve eski çalışan iş akışlarını desteklemek için aynı kitaplığın birden çok sürümünün tanıtılması yaygındır. Zorlayıcıydı.

Henüz WF 4.0'ı denemedim, ancak BizTalk ve WF 3.5 deneyimlerime dayanarak benzer olacağını düşünüyorum.

Her neyse, alabileceğiniz en iyi yaklaşım, Kavram Kanıtı yapmaktır. Gereksinimlerinizden tek bir WF alın ve WF 4.0'da uygulamaya çalışın. Bununla biraz zaman geçireceksiniz, ancak bunu WF 4.0'da yapıp yapamayacağınızı ve görünür faydaları olup olmadığını kanıtlayacaksınız.

WF 4.0 kullanmaya karar verirseniz, WF'yi Windows AppFabric'te barındırılan WCF hizmeti olarak çalıştırma olasılığını kontrol etmeniz konusunda ısrar ediyorum. AppFabric, WF'leri barındırmak için bazı kullanıma hazır işlevsellik sağlar.

Bugün WF4'teki İş Akışı hakkında bu tür bir problem için bir teknoloji seçimi olarak bahsetmenin gerçekten mantıklı olmadığını düşünüyorum. Yukarıda Ladislav Mrnka tarafından belirtildiği gibi gerçekten uygun olan, AppFabric'te barındırılan WCF WF Hizmetleri'dir.

Bu konudaki deneyimim, büyük kazançlar sağladığı ve çok zevkli olduğu, ancak başlangıçta sorunlar ortaya çıkıyor, çünkü birçok programcı için bunun bir teknoloji değişiminden daha fazla bir metodoloji değişimi olduğu tam olarak takdir edilmiyor. Öte yandan, uzmanlar ve problem çözme zihniyetine sahip olanlar, WCF WF AppFabric'i bir dizi heyecan verici fırsat olarak gördü. Bu nedenle, projedeki insanların karışımı, günlük OO ve kalıplarına bağlı oldukça muhafazakar C # geliştiriciler ise, bunu tanıtmak zor olacaktır. Ekip daha yenilikçi ise, benimsemek çok daha kolay olacaktır çünkü potansiyel ve yeni kapılar her keşifle çoğalır.

Programcıların bu teknolojiye geçerken karşılaştıkları iki temel kavramsal sorun şuydu: a) Mesaj korelasyonu ve mesajlı değişim modelleri b) İş akışları ve birim testi Örneğin C # standart sistemlerde bir iş akışı nadiren açıktır ve bu nedenle nadiren birim test edilir. Genel iş akışı, kabul senaryoları veya entegrasyon ile teste bırakılır. Açık bir WF'yi bir yazılım eseri olarak tanıtın ve aniden standart geliştiriciler onu denemek ve birim test etmek isterler ki bu genellikle yapmaya değmez.

Mesaj korelasyon yönü, mesaj değişim modellerine aşina olmayanlar için biraz zihniyet değişikliğidir. Çoğu geliştirici, süreç içi ve uzaktan aramalar, web hizmeti ve SOAP ile uğraştı ve genellikle bunlardan birine veya ikisine odaklandı. Her şeyden önce soyutlamak ve genel bir mesaj tabanlı sistemle çalışmak ilk başta kafa karıştırıcı olabilir.

Olumlu tarafı olsa da, sonuç çok zaman kazandıran ve çok fazla fırsat yaratan bir şeydir. Önemli bir nokta şudur ki, worfklow, görsel olarak netse, son kullanıcı, geliştirici ve analist tarafından birlikte üzerinde çalışılabilen, geliştirme yaşam döngüsündeki gereksiz adımları ortadan kaldıran ve tarafları tek bir yapıya odaklayan bir şeydir. Dahası, iş alanı başına WF'de bir iş süreçleri paketini teşvik ederek, özel yapıştırıcı katmanlarıyla özel uygulamalardaki işlevsellik adalarını caydırır. Dahası, AppFabric ile kalıcılık, kayıt tutma ve planlanan aktiviteleri uyandırma için gerekli tesisat sizin için yapılır. WF4 performansı da olağanüstü.

Benim tavsiyem, en yenilikçi veya araştırıcı ekip üyesini bulmak, zor kısımları keşfetmek, temel işlevleri çalıştırmak ve bu ilk kişinin kalan işi bölümlere ayırmaktan sorumlu olmasını sağlamaktır.

Rolleri ve "alt görevleri" içeren herhangi bir karmaşıklıkta bir sigorta tazminat talebi sistemi yapmak için, yalnızca iş akışına değil, gerçekten bir BPM çözümüne ihtiyacınız vardır. Workflow Foundation 4.0 kaygandır, ancak bir BPM ürününün işlevlerine gerçekten yaklaşmaz.

Metastorm BPM, Global360 ve K2.NET gibi BPM çözümleri, sigorta talep sisteminiz gibi iş süreçlerini modelleyebilen ve düzenleyebilen insan merkezli iş akışı, görevler, roller ve sistem entegrasyonu sağlar. Yerleşik tasarımcıları genellikle sınırlı olduğundan ve genellikle ASP.NET web denetimleri kadar tam özellikli olmayan özel oluşturulmuş web denetimlerini kullanmaya zorladığından BPM iş akışı motoruyla tümleşen arabirimi oluşturmak için ASP.NET kullanın.

Ekibinizin bildiği ve kendini rahat hissettiği teknolojiyi kullanın. Workflow Foundation, hemen kullanabileceğiniz bir ürün değildir - daha çok, bir iş akışı sistemi oluşturmak için uygulamanıza yerleştirebileceğiniz bir dizi parçadır. IMHO iş akışı mantığı, teknolojinin en önemsiz parçasıdır, her şeyden önce GUI'ye konsantre olmanız gerekir çünkü işletme sahipleri GUI'den başka bir şey görmeyeceklerdir. Ancak sisteminiz başarılıysa, hiç bitmeyen değişiklik taleplerine ve yeni gereksinimlere hazırlıklı olmalısınız, böylece iş mantığınızı uygulamanız gerekir, böylece farklı kullanıcı ihtiyaçlarına uyacak şekilde (bazen çelişkili) farklı süreçlere kolayca değiştirilebilir ve bölünebilir. . BPM, bu göreve yardımcı olur çünkü çeşitli iş gereksinimlerine uygun iş süreçlerinin ayrı, birden çok sürümüne sahip olmanıza olanak tanır. Sen yapmazsın bunun için tam teşekküllü BPM motoruna ihtiyacınız yoktur, ancak iş mantığınızı, sürümlendirilebilmesi ve bireysel iş süreçlerine bölünebilmesi için kodlamak yararlıdır - sahip olunan en kötü şey, 'her şeyi' işleyen, anlaşılmaz ve iç içe geçmiş bir kod bloğudur ve hayır anlayabilir. Bunun için pek çok fikir vardır - durum makineleri, DSL'ler (etki alanına özel diller), komut dosyaları vb. Uygulamanın ne olması gerektiğine siz karar verirsiniz. Ancak her zaman iş süreçleri açısından düşünmeli ve mantığınızı bu süreçleri yansıtacak şekilde düzenlemelisiniz. Ve iş mantığı ve veri yapısının birçok çeşidinin bir arada bulunmasına hazırlıklı olun - bu en zor tasarım görevidir. iş mantığınızı, versiyonlanabilmesi ve ayrı iş süreçlerine bölünebilmesi için kodlamak için kullanışlıdır - sahip olunması gereken en kötü şey, 'her şeyi' yöneten ve kimsenin anlayamayacağı, akıl almaz ve iç içe geçmiş bir kod bloğudur. Bunun için pek çok fikir vardır - durum makineleri, DSL'ler (etki alanına özel diller), komut dosyaları vb. Uygulamanın ne olması gerektiğine siz karar verirsiniz. Ancak her zaman iş süreçleri açısından düşünmeli ve mantığınızı bu süreçleri yansıtacak şekilde düzenlemelisiniz. Ve iş mantığı ve veri yapısının birçok çeşidinin bir arada bulunmasına hazırlıklı olun - bu en zor tasarım görevidir. iş mantığınızı, versiyonlanabilmesi ve ayrı iş süreçlerine bölünebilmesi için kodlamak için kullanışlıdır - sahip olunması gereken en kötü şey, 'her şeyi' yöneten ve kimsenin anlayamayacağı, akıl almaz ve iç içe geçmiş bir kod bloğudur. Bunun için pek çok fikir vardır - durum makineleri, DSL'ler (etki alanına özel diller), komut dosyaları vb. Uygulamanın ne olması gerektiğine siz karar verirsiniz. Ancak her zaman iş süreçleri açısından düşünmeli ve mantığınızı bu süreçleri yansıtacak şekilde düzenlemelisiniz. Ve iş mantığı ve veri yapısının birçok çeşidinin bir arada bulunmasına hazırlıklı olun - bu en zor tasarım görevidir. DSL'ler (etki alanına özel diller), komut dosyaları vb. - uygulamanın ne olması gerektiğine siz karar verirsiniz. Ancak her zaman iş süreçleri açısından düşünmeli ve mantığınızı bu süreçleri yansıtacak şekilde düzenlemelisiniz. Ve iş mantığı ve veri yapısının birçok çeşidinin bir arada bulunmasına hazırlıklı olun - bu en zor tasarım görevidir. DSL'ler (etki alanına özel diller), komut dosyaları vb. - uygulamanın ne olması gerektiğine siz karar verirsiniz. Ancak her zaman iş süreçleri açısından düşünmeli ve mantığınızı bu süreçleri yansıtacak şekilde düzenlemelisiniz. Ve iş mantığı ve veri yapısının birçok çeşidinin bir arada bulunmasına hazırlıklı olun - bu en zor tasarım görevidir.

.NET 4.5 henüz üretim ortamımızda kullanım için akredite olmadığından 4.0'ı kullanmak zorunda olduğum bir durumdayım. Genel olarak uzun süreli iş akışlarının iş ihtiyacımıza nasıl uyacağına dair büyük bir anlayışım vardı, ancak sonunda zarif bir çözüm buldum. Daha sonra desteklemeye gelen herkesin kolaylıkla anlayabileceği bir şey değil çünkü düşünecek çok şey var, ancak iş akışı durumlarını yönetmek için bir araç olarak WF'ye inanıyorum.

Yine de WF 4.0 ile ilgili sorun yaşadığım büyük bir şey Maurice'in yorumu:

Temel olan, asla mevcut bir iş akışını değiştirmemek, her zaman yeni bir tane oluşturmaktır.

Sadece yeni bir sürüm istiyorsanız bu harika, ama ya 50.000 kalıcı iş akışınız varsa ve bir noktada iş akışında bir hata olduğunu fark ederseniz? Xamlx'i güncelleyebilmeniz ve hala mevcut örneklere bağlı olmanız gerekir. Herhangi bir şans olmadan örneği iş akışı tanımına bağlayan bir şey bulmak için SQL Server örnekleri tablosundaki çeşitli meta veri sütunlarını açmayı denedim.

Eski bir sistemden yeni WF 4.0 güdümlü sistemimize veri aktarmak için bir senkronizasyon uygulaması yazdım. Temel olarak verileri sisteme yükleriz, ardından iş akışı adımlarını otomatik olarak çağıran ve doğrulama yöntemlerini çağıran, esasen kullanıcı etkileşimiyle alay eden süreci çalıştırırız. Bu, iş akışı hizmeti ana bilgisayarına erişim için uyguladığımız mimari nedeniyle bizimle gerçekten iyi çalıştı. Bir kereye mahsus olmak harikadır, çalıştırdıktan sonra veri taşıma sürecinin tutarlılığını sağlamak için kontroller yapabilirsiniz, ancak bu yaklaşımı bir sistem canlı olduğunda potansiyel olarak yüz binlerce durum için kullanmak zorunda olmak gerçekten bir yaklaşım değildir. güven aşılayan ve entegrasyon sürecini aşırı yükleyen basit hata düzeltmeleri.

Benim tavsiyem, WF 4.0'dan tamamen kaçınmanız ve ortam destekliyorsa doğrudan 4.5'e gitmenizdir. Dinamik Güncellemeler ve Yan Yana Sürüm Oluşturma, kutudan çıktığı gibi hata düzeltme ve WF sürüm belirleme sağlar. Hala 4.5'in müşterimiz tarafından kullanılmak üzere nasıl akredite edilmediğini tam olarak araştırmadım, ancak bu fırsatı hevesle bekliyorum.

Umutsuzca umduğum şey, müşterimizin politikada değişiklik (ve dolayısıyla iş akışı ayarlamaları) talep etmemesi ve mevcut iş akışlarının herhangi bir hata olmadan devam etmesidir. İkincisi, böcekler her zaman ortaya çıktığı için boş ve boş bir umuttur.

Kutudan çıkar çıkmaz hataları kolayca düzeltemeyeceğiniz bir sistemi piyasaya sürmek için WF geliştirme ekibinin kafasından neler geçtiğini gerçekten anlayamıyorum. Bir örneği yeni xamlx'e yeniden bağlamak için bir teknik geliştirmeleri gerekirdi.