Ke Alur Kerja atau Tidak ke Alur Kerja?

Saya bertanggung jawab atas tim pengembang yang akan memulai pengembangan sistem klaim asuransi ringan. Sistem ini melibatkan banyak tugas manual dan alur kerja bisnis dan kami sedang menggunakan Windows Workflow (.NET 4.0).

Contoh domain bisnis adalah sebagai berikut: Seorang pemegang polis menghubungi contact center untuk mengajukan klaim. "Peristiwa" ini mengaktifkan dua sub tugas yang secara manual dilakukan secara paralel dan mungkin membutuhkan waktu lama untuk diselesaikan;

1. Periksa pelanggan untuk penipuan - Proses manual di mana operator memanggil berbagai perusahaan kredit untuk memeriksa dan menilai potensi pelanggan yang curang. Dari sini sub tugas dapat memasukkan sejumlah sub-status (Check in progress, Failed Reference Check, Passed Reference Check, dll)
2. Kirim barang ke pusat perbaikan - Proses manual dimana barang yang diklaim oleh pemegang polis dikirim ke pusat perbaikan untuk diperbaiki. Dari sini sub tugas dapat memasukkan sejumlah sub-status (Menunggu Perbaikan, Dalam Proses, Diperbaiki, Diposting, dll). Klaim hanya dapat dilanjutkan setelah status setiap sub tugas mencapai status yang telah ditentukan (berdasarkan aturan bisnis).

Di permukaan, tampaknya Workflow memang merupakan pilihan teknologi terbaik; namun saya memiliki beberapa kekhawatiran dalam menggunakan WF 4.0.

1. Set Keterampilan - Melihat pada kumpulan keterampilan pengembang rata-rata Saya tidak melihat banyak pengembang yang memahami atau mengetahui Alur Kerja.
2. Pemeliharaan - Tampaknya hanya ada sedikit dukungan dalam komunitas untuk proyek WF 4.0 dan ini ditambah dengan kurangnya keahlian yang menimbulkan kekhawatiran seputar pemeliharaan.
3. Penghalang untuk masuk - Saya merasa Windows Workflow memiliki kurva pembelajaran yang curam dan tidak selalu mudah untuk diambil.
4. Produk baru - Karena Alur Kerja telah sepenuhnya ditulis ulang untuk .NET 4.0 Saya melihat produk sebagai produk generasi pertama dan mungkin tidak memiliki stabilitas yang diperlukan.
5. Reputasi - Versi sebelumnya dari Alur Kerja tidak diterima dengan baik, dianggap sulit untuk dikembangkan dan mengakibatkan penyerapan bisnis yang buruk.

Jadi pertanyaan saya adalah haruskah kita menggunakan Windows Workflow (WF) 4.0 untuk situasi ini atau adakah teknologi alternatif (misalnya, Simple State Machine , dll) atau bahkan mesin alur kerja yang lebih baik untuk digunakan?

Saya telah melakukan beberapa proyek WF4 jadi mari kita lihat apakah saya dapat menambahkan info berguna ke jawaban lain.

Dari uraian masalah bisnis Anda, sepertinya WF4 cocok, jadi tidak ada masalah.

Mengenai kekhawatiran Anda, Anda benar. Pada dasarnya WF4 adalah produk baru dan kekurangan beberapa fitur penting dan memiliki beberapa keunggulan. Ada kurva belajar, Anda harus melakukan beberapa hal secara berbeda. Poin utamanya adalah berjalan lama dan serialisasi, yang merupakan sesuatu yang rata-rata pengembang tidak terbiasa dan memerlukan pemikiran untuk mendapatkan yang benar karena saya terlalu sering mendengar bahwa orang memiliki masalah membuat serialisasi konteks kerangka data entitas.

Sebagian besar waktu menggunakan layanan alur kerja yang dihosting di IIS / WAS adalah rute terbaik saat melakukan jenis alur kerja yang berjalan lama ini. Itu membuat pemecahan masalah pembuatan versi tidak terlalu sulit, cukup minta pesan pertama mengembalikan versi alur kerja dan menjadikannya bagian dari setiap pesan berikutnya. Selanjutnya letakkan router WCF di antara rute pesan tersebut ke titik akhir yang benar berdasarkan versinya. Dasarnya adalah jangan pernah mengubah alur kerja yang sudah ada, selalu buat yang baru.

Jadi apa saran saya untuk Anda? Jangan mengambil risiko besar pada hal yang tidak diketahui, dan untuk Anda yang belum terbukti, sebuah teknologi. Lakukan bagian kecil, tidak kritis, aplikasi menggunakan WF4. Dengan cara itu jika berhasil, Anda dapat mengembangkannya tetapi jika gagal, Anda dapat merobeknya dan menggantinya dengan kode .NET yang lebih tradisional. Dengan cara itu Anda mendapatkan pengalaman nyata dengan WF4 alih-alih harus mendasarkan keputusan pada informasi bekas dan Anda mempelajari teknologi baru dan kuat dalam prosesnya. Jika memungkinkan, ikuti kursus tentang WF4 karena itu akan menghemat banyak waktu untuk mempercepat (pasang sendiri tanpa malu di sini ).

Tentang Mesin Status Sederhana. Saya belum pernah menggunakannya tetapi saya mendapat kesan bahwa itu hanya berjalan sebentar, dalam memori, mesin negara. Salah satu manfaat utama WF4 adalah aspek jangka panjangnya.

Saya telah mengalami dilema ini beberapa kali dan saya memilih untuk tidak menggunakan fondasi Alur Kerja. Beberapa pertimbangan (serupa dengan Anda) adalah

1. Alur kerja yang terlibat jauh lebih sederhana (kombinasi dari mesin negara dan tindakan berurutan) dan melakukannya di WF tampaknya berlebihan untuk upaya yang terlibat.
2. Kurva pembelajaran bagi pengembang untuk memahami dan menggunakan WF secara efektif dianggap tinggi. Tabel transisi status yang mendeskripsikan transisi valid dan tindakan yang akan diambil digunakan untuk fleksibilitas tambahan dan pengembang merasa nyaman dengannya, memahami konsep dan tujuan dengan mudah.
3. Peluang perubahan proses bisnis sangat tipis dan perubahan mendasar dapat dengan mudah dilakukan dengan bantuan tabel transisi. Perubahan dalam transisi berarti skrip database sementara perubahan tindakan akan menghasilkan rilis / patch baru. Namun, kemungkinan terjadinya seperti itu dianggap rendah.

Melihat ke belakang setelah 13-14 bulan, menurut saya keputusan untuk tidak menggunakan WF adalah benar. IMO, WF masuk akal jika ada kemungkinan kuat bahwa alur kerja dapat berubah dan / atau aturan bisnis dapat berubah. WF memungkinkan untuk mengisolasi alur kerja dalam file terpisah sehingga membuatnya dapat dikonfigurasi oleh pengguna akan lebih sederhana.

Kami telah menggunakan WF 4.0 beberapa bulan terakhir. Saya harus mengatakan itu menantang untuk memikirkan cara Alur Kerja. Namun, saya dapat memberi tahu Anda bahwa itu sepadan. Kami hanya tahu sedikit ketika kami mulai. Kami telah membeli buku pemula dan profesional untuk WF 4.0 yang membantu. Saya sendiri, menonton banyak video online dan mengikuti PDC 2009 untuk berita terbaru mereka tentang WF 4.0 dan bagaimana perbedaannya dari versi sebelumnya yang agak buruk. Satu hal utama yang harus kami usulkan solusinya adalah cara kami menangani In / Our Arguments dalam alur kerja tanpa membatasi aktivitas kustom kami ke tipe data tertentu dan cara meneruskan parameter antar aktivitas. Saya telah menemukan solusi yang baik untuk itu, dan pengalaman alur kerja yang kami miliki sejauh ini tidak buruk sama sekali. Sebenarnya, kami memiliki aplikasi intensif alur kerja yang semakin besar dan besar dan saya benar-benar tidak dapat membayangkan diri saya menyelesaikannya di lingkungan yang berbeda. Saya suka efek visual yang dimilikinya: itu membuat saya jauh dari detail konstruksi if / else dll dan membuat aturan bisnis terlihat jelas dengan cara yang tidak membuat Anda dipaksa untuk menyelami baris kode untuk mengetahui apa yang sedang terjadi atau bagaimana memperbaiki beberapa bug. Omong-omong, proyek yang kami kerjakan sangat mirip dengan apa yang Anda gambarkan dan ini adalah proyek berukuran sedang. Anda dapat mengatakan dari kata-kata saya bahwa saya menyukainya dan saya merekomendasikannya meskipun mengandung beberapa risiko karena ini adalah teknologi baru dan Anda harus menemukan beberapa ide inovatif. itu menjauhkan saya dari detail konstruksi if / else etc dan membuat aturan bisnis menjadi jelas dengan cara yang tidak membuat Anda dipaksa untuk menyelami baris kode untuk mengetahui apa yang terjadi atau bagaimana memperbaiki beberapa bug. Omong-omong, proyek yang kami kerjakan sangat mirip dengan apa yang Anda gambarkan dan ini adalah proyek berukuran sedang. Anda dapat mengatakan dari kata-kata saya bahwa saya menyukainya dan saya merekomendasikannya meskipun mengandung beberapa risiko karena ini adalah teknologi baru dan Anda harus menemukan beberapa ide inovatif. itu menjauhkan saya dari detail konstruksi if / else etc dan membuat aturan bisnis menjadi jelas dengan cara yang tidak membuat Anda dipaksa untuk menyelami baris kode untuk mengetahui apa yang terjadi atau bagaimana memperbaiki beberapa bug. Omong-omong, proyek yang kami kerjakan sangat mirip dengan apa yang Anda gambarkan dan ini adalah proyek berukuran sedang. Anda dapat mengatakan dari kata-kata saya bahwa saya menyukainya dan saya merekomendasikannya meskipun mengandung beberapa risiko karena ini adalah teknologi baru dan Anda harus menemukan beberapa ide inovatif.

2 sen saya ...

Saya melakukan tiga proyek di WF 3.5 dan saya harus mengatakan itu tidak mudah. Itu memaksa Anda untuk berpikir dengan cara yang benar-benar baru terutama ketika kegigihan digunakan. Memperbarui aplikasi yang berisi ratusan alur kerja tetap yang tidak lengkap itu menantang. Perubahan tunggal dalam serialisasi membuat semuanya crash. Memperkenalkan beberapa versi pustaka yang sama untuk mendukung alur kerja baru dan lama adalah hal biasa. Itu menantang.

Saya belum pernah mencoba WF 4.0 tapi berdasarkan pengalaman dari BizTalk dan WF 3.5 saya rasa akan serupa.

Bagaimanapun, pendekatan terbaik yang dapat Anda ambil adalah melakukan Pembuktian Konsep. Ambil WF tunggal dari persyaratan Anda dan coba terapkan dalam WF 4.0. Anda akan menghabiskan beberapa waktu dengannya tetapi Anda akan membuktikan apakah Anda mampu melakukannya di WF 4.0 dan jika ada manfaat yang terlihat.

Jika Anda memutuskan untuk menggunakan WF 4.0, saya bersikeras agar Anda memeriksa kemungkinan untuk menjalankan WF sebagai layanan WCF yang dihosting di Windows AppFabric. AppFabric menyediakan beberapa fungsionalitas di luar kotak untuk menghosting WF.

Saya pikir tidak masuk akal hari ini untuk membicarakan Alur Kerja di WF4 sebagai pilihan teknologi untuk masalah semacam ini. Yang benar-benar tepat, seperti yang disebutkan oleh Ladislav Mrnka di atas, adalah Layanan WF WCF yang dihosting di AppFabric.

Pengalaman saya dengan hal ini adalah bahwa hal ini memberikan keuntungan yang besar dan sangat menyenangkan, tetapi masalah muncul pada awalnya karena tidak dihargai dengan baik bahwa bagi banyak programmer ini adalah pergeseran metodologi lebih dari sekedar pergeseran teknologi. Di sisi lain, generalis dan mereka yang memiliki pola pikir pemecahan masalah melihat WCF WF AppFabric sebagai satu set peluang yang menarik. Jadi, jika campuran orang-orang dalam proyek tersebut cukup konservatif C # dev yang terikat pada OO dan pola harian mereka, akan sulit untuk memperkenalkannya. Jika tim lebih inovatif, adopsi akan jauh lebih mudah karena potensi dan pintu baru berlipat ganda dengan setiap penemuan.

Dua masalah konseptual utama yang dimiliki pemrogram saat beralih ke teknologi ini adalah: a) Korelasi pesan dan pola pertukaran pesan b) Alur kerja dan pengujian unit Dalam sistem standar di C # misalnya, alur kerja jarang eksplisit dan karenanya unit jarang diuji. Alur kerja keseluruhan dibiarkan untuk pengujian dengan skenario penerimaan atau integrasi. Perkenalkan WF eksplisit sebagai artefak perangkat lunak dan tiba-tiba pengembang standar ingin mencoba dan mengujinya, yang biasanya tidak layak dilakukan.

Aspek korelasi pesannya adalah sedikit perubahan pola pikir bagi mereka yang tidak terbiasa dengan pola pertukaran pesan. Kebanyakan pengembang telah berurusan dengan proses dan panggilan jarak jauh, layanan web dan SOAP, dan biasanya difokuskan pada satu atau dua di antaranya. Untuk mengabstraksi di atas itu semua dan bekerja dengan sistem berbasis pesan umum dapat membingungkan pada awalnya.

Sisi positifnya, hasil akhirnya adalah sesuatu yang menghemat banyak waktu dan menciptakan banyak peluang. Satu hal utama adalah bahwa worfklow, jika jelas secara visual, adalah sesuatu yang dapat dikerjakan oleh pengguna akhir, pengembang, dan analis bersama-sama, menghilangkan langkah-langkah yang tidak perlu dalam siklus hidup pengembangan dan memfokuskan para pihak pada satu artefak. Lebih lanjut, ini mengurangi fungsi pulau dalam aplikasi khusus, dengan lapisan lem khusus, dengan mendorong rangkaian proses bisnis di WF per domain bisnis. Selanjutnya, dengan AppFabric, pipa ledeng untuk ketekunan, logging, dan aktivitas terjadwal bangun semuanya dilakukan untuk Anda. Kinerja WF4 juga luar biasa.

Rekomendasi saya adalah menemukan anggota tim yang paling inovatif atau eksploratif yang melakukan pengintaian awal untuk menemukan bagian-bagian yang rumit, menjalankan fungsi inti, dan meminta orang pertama tersebut bertanggung jawab untuk kemudian membagi pekerjaan yang tersisa.

Untuk melakukan sistem klaim asuransi dengan kerumitan apa pun yang melibatkan peran dan "sub-tugas", Anda benar-benar memerlukan solusi BPM, bukan hanya alur kerja. Workflow Foundation 4.0 apik tetapi sebenarnya tidak mendekati fungsionalitas produk BPM.

Solusi BPM, seperti Metastorm BPM, Global360, dan K2.NET, menyediakan alur kerja, tugas, peran, dan integrasi sistem yang berpusat pada manusia yang dapat memodelkan dan merampingkan proses bisnis seperti sistem klaim asuransi Anda. Gunakan ASP.NET untuk membangun antarmuka yang terintegrasi dengan mesin alur kerja BPM karena desainer bawaan mereka biasanya terbatas dan memaksa Anda untuk menggunakan kontrol web yang dibuat khusus yang biasanya tidak berfitur lengkap seperti kontrol web ASP.NET.

Gunakan teknologi yang tim Anda kenal dan nyaman. Workflow Foundation bukanlah produk yang dapat Anda gunakan secara langsung - ini lebih merupakan sekumpulan bagian yang dapat Anda sematkan dalam aplikasi Anda untuk membangun sistem alur kerja. IMHO logika alur kerja adalah bagian teknologi yang paling tidak penting, pertama-tama Anda harus berkonsentrasi pada GUI karena pemilik bisnis tidak akan melihat apa pun kecuali GUI. Tetapi jika sistem Anda sukses maka Anda harus siap untuk permintaan perubahan yang tidak pernah berakhir dan persyaratan baru sehingga Anda harus menerapkan logika bisnis Anda sehingga mudah untuk diubah dan mudah untuk dibagi ke dalam proses terpisah untuk menyesuaikan dengan kebutuhan pengguna yang berbeda (terkadang bertentangan) . BPM membantu dalam tugas ini karena memungkinkan Anda untuk memiliki beberapa versi proses bisnis yang terpisah yang sesuai dengan berbagai kebutuhan bisnis. Anda tidak Anda tidak memerlukan mesin BPM yang lengkap untuk itu tetapi berguna untuk membuat kode logika bisnis Anda sehingga dapat diversi dan dibagi menjadi proses bisnis individu - hal terburuk yang harus dimiliki adalah gumpalan kode yang tidak dapat dipertahankan dan saling terkait yang menangani 'semuanya' dan tidak orang bisa mengerti. Ada banyak ide untuk itu - mesin negara, DSL (bahasa khusus domain), skrip, dll - Anda memutuskan apa penerapannya. Tetapi Anda harus selalu berpikir dalam kerangka proses bisnis dan mengatur logika Anda sesuai sehingga mencerminkan proses ini. Dan bersiaplah untuk koeksistensi dari banyak varian logika bisnis dan struktur data - ini adalah tugas desain yang paling sulit. Sangat berguna untuk membuat kode logika bisnis Anda sehingga dapat diversi dan dibagi menjadi proses bisnis individu - hal terburuk yang harus dimiliki adalah gumpalan kode yang tidak dapat dipertahankan dan saling terkait yang menangani 'semuanya' dan tidak ada yang bisa mengerti. Ada banyak ide untuk itu - mesin negara, DSL (bahasa khusus domain), skrip, dll - Anda memutuskan apa penerapannya. Tetapi Anda harus selalu berpikir dalam kerangka proses bisnis dan mengatur logika Anda sesuai sehingga mencerminkan proses ini. Dan bersiaplah untuk koeksistensi dari banyak varian logika bisnis dan struktur data - ini adalah tugas desain yang paling sulit. Sangat berguna untuk membuat kode logika bisnis Anda sehingga dapat diversi dan dibagi menjadi proses bisnis individu - hal terburuk yang harus dimiliki adalah gumpalan kode yang tidak dapat dipertahankan dan saling terkait yang menangani 'semuanya' dan tidak ada yang bisa mengerti. Ada banyak ide untuk itu - mesin negara, DSL (bahasa khusus domain), skrip, dll - Anda memutuskan apa penerapannya. Tetapi Anda harus selalu berpikir dalam kerangka proses bisnis dan mengatur logika Anda sesuai sehingga mencerminkan proses ini. Dan bersiaplah untuk koeksistensi dari banyak varian logika bisnis dan struktur data - ini adalah tugas desain yang paling sulit. DSL (bahasa khusus domain), skrip, dll - Anda yang memutuskan penerapan apa yang seharusnya. Tetapi Anda harus selalu berpikir dalam kerangka proses bisnis dan mengatur logika Anda sesuai sehingga mencerminkan proses ini. Dan bersiaplah untuk koeksistensi dari banyak varian logika bisnis dan struktur data - ini adalah tugas desain yang paling sulit. DSL (bahasa khusus domain), skrip, dll - Anda yang memutuskan penerapan apa yang seharusnya. Tetapi Anda harus selalu berpikir dalam kerangka proses bisnis dan mengatur logika Anda sesuai sehingga mencerminkan proses ini. Dan bersiaplah untuk koeksistensi dari banyak varian logika bisnis dan struktur data - ini adalah tugas desain yang paling sulit.

Saya dalam situasi di mana saya harus menggunakan 4.0 karena .NET 4.5 belum terakreditasi untuk digunakan di lingkungan prod kami. Saya memiliki pemahaman yang sangat menyakitkan secara umum bagaimana mendapatkan alur kerja yang berjalan lama yang sesuai dengan kebutuhan bisnis kami, tetapi akhirnya menemukan solusi yang elegan. Ini bukan sesuatu yang dapat dilakukan oleh siapa saja yang datang kemudian untuk mendukungnya dengan mudah karena ada banyak hal yang harus dipikirkan, tetapi saya percaya pada WF sebagai alat untuk mengelola status alur kerja.

Satu hal besar yang saya ambil masalah dengan WF 4.0 adalah komentar Maurice:

Dasarnya adalah jangan pernah mengubah alur kerja yang sudah ada, selalu buat yang baru

Itu bagus jika Anda hanya menginginkan versi baru, tetapi bagaimana jika Anda memiliki 50.000 alur kerja yang bertahan dan menyadari di beberapa titik bahwa ada bug dalam alur kerja? Anda harus dapat memperbarui xamlx dan masih terhubung dengan instance yang ada. Saya telah mencoba membuka ritsleting berbagai kolom metadata di tabel instance SQL Server untuk menemukan sesuatu yang mengikat instance tersebut ke definisi alur kerja tanpa hasil.

Saya memang menulis aplikasi sinkronisasi untuk mengimpor data dari sistem lama ke sistem baru kami yang digerakkan WF 4.0. Kami pada dasarnya memuat data ke dalam sistem, kemudian menjalankan proses yang secara otomatis memanggil langkah-langkah alur kerja dan memanggil metode validasi, yang pada dasarnya mengejek interaksi pengguna. Ini hanya benar-benar bekerja dengan baik dengan kami karena arsitektur yang kami terapkan untuk akses ke host layanan alur kerja. Ini bagus sebagai satu kali, di mana setelah berjalan Anda dapat melalui dan melakukan pemeriksaan untuk memastikan konsistensi proses migrasi data, tetapi harus menggunakan pendekatan ini untuk kemungkinan ratusan ribu kasus setelah sistem hidup bukanlah pendekatan yang sebenarnya. yang menanamkan kepercayaan diri dan membebani proses integrasi, perbaikan bug sederhana.

Rekomendasi saya adalah Anda menghindari WF 4.0 sama sekali dan langsung menuju ke 4.5 jika lingkungan Anda mendukungnya. Pembaruan Dinamis dan Versi Berdampingan yang disediakannya melayani perbaikan bug dan versi WF semuanya di luar kotak. Saya masih belum menyelidiki dengan tepat bagaimana 4.5 masih belum diakreditasi untuk digunakan oleh klien kami, tetapi sangat menantikan kesempatan ini.

Apa yang sangat saya harapkan adalah bahwa klien kami tidak meminta perubahan pada kebijakan (dan karena itu penyesuaian alur kerja) dan bahwa alur kerja saat ini bertahan tanpa bug. Yang terakhir adalah harapan yang sia-sia dan kosong karena serangga selalu bermunculan.

Saya benar-benar tidak dapat memahami apa yang terjadi di kepala tim pengembang WF untuk merilis sistem di mana di luar kotak Anda tidak dapat memperbaiki bug dengan mudah. Mereka seharusnya telah mengembangkan teknik untuk mengikat ulang sebuah instance ke xamlx baru.