Đối với Dòng công việc hay Không đối với Dòng công việc?

Tôi chịu trách nhiệm về một nhóm các nhà phát triển, những người sẽ bắt đầu phát triển hệ thống yêu cầu bảo hiểm trọng lượng nhẹ. Hệ thống liên quan đến nhiều tác vụ thủ công và quy trình công việc và chúng tôi đang xem xét việc sử dụng Quy trình làm việc của Windows (.NET 4.0).

Ví dụ về miền doanh nghiệp như sau: Một chủ hợp đồng gọi điện đến trung tâm liên hệ để yêu cầu bồi thường. “Sự kiện” này kích hoạt hai nhiệm vụ phụ được thực hiện song song theo cách thủ công và có thể mất nhiều thời gian để hoàn thành;

1. Kiểm tra xem khách hàng có gian lận - Một quy trình thủ công, theo đó một nhà điều hành gọi các công ty tín dụng khác nhau để kiểm tra và đánh giá khả năng có một khách hàng gian lận. Từ đây, nhiệm vụ phụ có thể nhập một số trạng thái phụ (Đang tiến hành, Kiểm tra tham chiếu không thành công, Kiểm tra tham chiếu đã vượt qua, v.v.)
2. Gửi mặt hàng đến trung tâm sửa chữa - Một quy trình thủ công trong đó mặt hàng mà chủ hợp đồng nộp đơn khiếu nại sẽ được gửi đến trung tâm sửa chữa để sửa. Từ đây, nhiệm vụ phụ có thể nhập một số trạng thái phụ (Đang chờ sửa chữa, Đang tiến hành, Đã sửa chữa, Đã đăng, v.v.). Yêu cầu chỉ có thể tiếp tục khi trạng thái của mỗi nhiệm vụ phụ đạt đến trạng thái xác định trước (dựa trên các quy tắc kinh doanh).

Bề ngoài có vẻ như Workflow thực sự là lựa chọn công nghệ tốt nhất; tuy nhiên, tôi có một vài lo ngại khi sử dụng WF 4.0.

1. Bộ kỹ năng - Nhìn vào bộ kỹ năng nhà phát triển trung bình, tôi không thấy nhiều nhà phát triển hiểu hoặc biết Quy trình làm việc.
2. Khả năng bảo trì - Có vẻ như có rất ít sự hỗ trợ trong cộng đồng đối với các dự án WF 4.0 và điều này cùng với việc thiếu bộ kỹ năng làm dấy lên những lo ngại về khả năng bảo trì.
3. Rào cản để nhập cuộc - Tôi có cảm giác rằng Windows Workflow có một đường cong học tập dốc và nó không phải lúc nào cũng dễ dàng tiếp thu.
4. Sản phẩm mới - Vì Quy trình làm việc đã được viết lại hoàn toàn cho .NET 4.0, tôi thấy sản phẩm là sản phẩm thế hệ đầu tiên và có thể không có độ ổn định cần thiết.
5. Danh tiếng - Các phiên bản trước của Quy trình làm việc không được đón nhận, bị coi là khó phát triển và dẫn đến việc kinh doanh kém hấp dẫn.

Vì vậy, câu hỏi của tôi là chúng ta có nên sử dụng Windows Workflow (WF) 4.0 cho tình huống này hay có công nghệ thay thế (ví dụ: Simple State Machine , v.v.) hoặc thậm chí là một công cụ quy trình làm việc tốt hơn để sử dụng?

Tôi đã thực hiện một số dự án WF4 nên hãy xem liệu tôi có thể thêm bất kỳ thông tin hữu ích nào vào các câu trả lời khác không.

Từ mô tả về vấn đề kinh doanh của bạn, có vẻ như WF4 là một kết hợp tốt, vì vậy không có vấn đề gì ở đó.

Về mối quan tâm của bạn, bạn đã đúng. Về cơ bản WF4 là một sản phẩm mới và thiếu một số tính năng quan trọng và có một số cạnh thô. Có một đường cong học tập, bạn phải làm một số điều khác nhau. Điểm chính là chạy lâu dài và tuần tự hóa, đây là điều mà các nhà phát triển bình thường không quen và yêu cầu một số suy nghĩ để làm đúng vì tôi đã nghe rất thường xuyên rằng mọi người gặp vấn đề với việc tuần tự hóa ngữ cảnh dữ liệu khung thực thể.

Hầu hết thời gian sử dụng các dịch vụ dòng công việc được lưu trữ trong IIS / WAS là cách tốt nhất khi thực hiện các loại dòng công việc chạy dài này. Điều đó làm cho việc giải quyết vấn đề lập phiên bản cũng không khó, chỉ cần có thông báo đầu tiên trả về phiên bản quy trình làm việc và biến nó thành một phần của mỗi thông báo tiếp theo. Tiếp theo đặt bộ định tuyến WCF vào giữa định tuyến thông báo đến đúng điểm cuối dựa trên phiên bản. Điều cơ bản là không bao giờ thay đổi quy trình làm việc hiện có, luôn tạo một quy trình mới.

Vậy lời khuyên của tôi dành cho bạn là gì? Đừng đánh cược lớn vào một thứ chưa biết và đối với bạn, phần công nghệ chưa được chứng minh. Thực hiện một phần nhỏ, không quan trọng, của ứng dụng bằng WF4. Bằng cách đó, nếu nó hoạt động, bạn có thể mở rộng nó nhưng nếu nó không thành công, bạn có thể tách nó ra và thay thế nó bằng mã .NET truyền thống hơn. Bằng cách đó, bạn có được trải nghiệm thực tế với WF4 thay vì phải đưa ra quyết định dựa trên thông tin cũ và bạn học được một công nghệ mới và mạnh mẽ trong quá trình này. Nếu có thể, hãy tham gia một khóa học về WF4 vì điều đó sẽ giúp bạn tiết kiệm rất nhiều thời gian trong việc bắt kịp tốc độ (không biết xấu hổ là gì ở đây ).

Giới thiệu về Máy trạng thái đơn giản. Tôi đã không sử dụng nó nhưng tôi có ấn tượng là nó chạy ngắn, trong bộ nhớ, máy trạng thái. Một trong những lợi ích chính của WF4 là các khía cạnh hoạt động lâu dài.

Tôi đã đến tình huống khó xử này vài lần và tôi đã chọn không sử dụng nền tảng Work Flow. Một số cân nhắc (tương tự như của bạn) là

1. Các luồng công việc có liên quan đơn giản hơn rất nhiều (sự kết hợp của máy trạng thái và các hành động tuần tự) và thực hiện nó trong WF dường như quá mức cần thiết cho những nỗ lực liên quan.
2. Đường cong học tập để các nhà phát triển hiểu và sử dụng WF hiệu quả được coi là cao. Bảng chuyển đổi trạng thái mô tả các chuyển đổi hợp lệ và các hành động cần thực hiện được sử dụng để tăng tính linh hoạt và các nhà phát triển cảm thấy thoải mái với nó, dễ dàng hiểu khái niệm và mục đích.
3. Cơ hội thay đổi quy trình kinh doanh rất mỏng và những thay đổi thô sơ có thể dễ dàng thực hiện với sự trợ giúp của bảng chuyển đổi. Một sự thay đổi trong quá trình chuyển đổi có nghĩa là một tập lệnh cơ sở dữ liệu trong khi thay đổi trong các hành động sẽ dẫn đến bản phát hành / bản vá mới. Tuy nhiên, xác suất xảy ra như vậy được cho là thấp.

Nhìn lại sau 13-14 tháng, tôi vẫn nghĩ rằng quyết định không sử dụng WF là đúng. IMO, WF có ý nghĩa khi có khả năng cao là luồng công việc có thể thay đổi và / hoặc các quy tắc kinh doanh có thể thay đổi. WF cho phép cô lập quy trình làm việc trong một tệp riêng biệt và do đó, việc người dùng có thể định cấu hình sẽ đơn giản hơn.

Chúng tôi đã sử dụng WF 4.0 trong vài tháng qua. Tôi phải nói rằng thật khó để nghĩ theo cách Quy trình làm việc. Tuy nhiên, tôi có thể nói với bạn rằng nó đáng giá. Chúng tôi biết rất ít khi chúng tôi bắt đầu. Chúng tôi đã mua một cuốn sách dành cho người mới bắt đầu và cuốn sách chuyên nghiệp cho WF 4.0. Bản thân tôi đã xem nhiều video trực tuyến và theo dõi PDC 2009 để biết tin tức nóng hổi của họ về WF 4.0 và sự khác biệt của nó so với các phiên bản có phần hấp dẫn trước đó. Một điều quan trọng mà chúng tôi phải đề xuất giải pháp là cách chúng tôi có thể xử lý Đối số trong / của chúng tôi trong quy trình làm việc mà không giới hạn các hoạt động tùy chỉnh của chúng tôi với một số kiểu dữ liệu nhất định và cách chuyển các tham số giữa các hoạt động. Tôi đã đưa ra một giải pháp tốt cho điều đó và trải nghiệm quy trình làm việc mà chúng tôi có cho đến nay không tệ chút nào. Thực ra, chúng tôi có một ứng dụng chuyên sâu về quy trình làm việc ngày càng lớn hơn và tôi thực sự không thể tưởng tượng được mình lại giải quyết nó trong một môi trường khác. Tôi thích hiệu ứng hình ảnh mà nó có: nó giúp tôi tránh xa các chi tiết về cấu trúc if / else, v.v. và làm cho các quy tắc kinh doanh trở nên rõ ràng theo cách không khiến bạn buộc phải đi sâu vào các dòng mã để biết điều gì đang xảy ra hoặc làm thế nào để sửa một số lỗi. Nhân tiện, dự án mà chúng tôi đã làm rất giống với những gì bạn mô tả và đó là một dự án quy mô trung bình. Bạn có thể nói từ tôi rằng tôi thích nó và tôi khuyên bạn nên sử dụng nó mặc dù nó có một số rủi ro vì đây là một công nghệ mới và bạn phải đưa ra một số ý tưởng sáng tạo. nó giúp tôi tránh xa các chi tiết về cấu trúc if / else vv và làm cho các quy tắc kinh doanh rõ ràng theo cách không khiến bạn buộc phải đi sâu vào các dòng mã để biết điều gì đang xảy ra hoặc cách sửa một số lỗi. Nhân tiện, dự án mà chúng tôi đã làm rất giống với những gì bạn mô tả và đó là một dự án quy mô trung bình. Bạn có thể nói từ tôi rằng tôi thích nó và tôi khuyên bạn nên sử dụng nó mặc dù nó có một số rủi ro vì đây là một công nghệ mới và bạn phải đưa ra một số ý tưởng sáng tạo. nó giúp tôi tránh xa các chi tiết về cấu trúc if / else vv và làm cho các quy tắc kinh doanh rõ ràng theo cách không khiến bạn buộc phải đi sâu vào các dòng mã để biết điều gì đang xảy ra hoặc cách sửa một số lỗi. Nhân tiện, dự án mà chúng tôi đã làm rất giống với những gì bạn mô tả và đó là một dự án quy mô trung bình. Bạn có thể nói từ tôi rằng tôi thích nó và tôi khuyên bạn nên sử dụng nó mặc dù nó có một số rủi ro vì đây là một công nghệ mới và bạn phải đưa ra một số ý tưởng sáng tạo.

2 xu của tôi ...

Tôi đã thực hiện ba dự án trong WF 3.5 và tôi phải nói rằng nó không hề dễ dàng. Nó buộc bạn phải suy nghĩ theo cách hoàn toàn mới, đặc biệt là khi tính kiên trì được sử dụng. Cập nhật ứng dụng chứa hàng trăm quy trình làm việc liên tục không hoàn chỉnh là một thách thức. Thay đổi phá vỡ một lần trong tuần tự hóa làm hỏng tất cả. Việc giới thiệu nhiều phiên bản của cùng một thư viện để hỗ trợ các dòng công việc đang chạy mới và cũ là điều phổ biến. Đó là một thử thách.

Tôi chưa thử WF 4.0 nhưng dựa trên kinh nghiệm từ BizTalk và WF 3.5, tôi nghĩ nó sẽ tương tự.

Dù sao thì cách tốt nhất bạn có thể thực hiện là làm Proof-of-Concept. Lấy WF đơn lẻ từ các yêu cầu của bạn và cố gắng cấy ghép nó trong WF 4.0. Bạn sẽ dành một chút thời gian cho nó nhưng bạn sẽ chứng minh được liệu bạn có thể làm được điều đó trong WF 4.0 hay không và nếu có bất kỳ lợi ích rõ ràng nào.

Nếu bạn quyết định sử dụng WF 4.0, tôi nhấn mạnh rằng bạn nên kiểm tra khả năng chạy WF dưới dạng dịch vụ WCF được lưu trữ trong Windows AppFnai. AppFnai cung cấp một số chức năng ngoài hộp để lưu trữ các WF.

Tôi nghĩ ngày nay không thực sự có ý nghĩa khi nói về Quy trình làm việc trong WF4 như một lựa chọn công nghệ cho loại vấn đề này. Điều thực sự thích hợp, như Ladislav Mrnka đã đề cập ở trên, là Dịch vụ WCF WF được lưu trữ trong AppFnai.

Kinh nghiệm của tôi về điều này là nó trả cổ tức rất lớn và rất thú vị, nhưng các vấn đề nảy sinh ngay từ đầu vì nó không được đánh giá đúng mức đối với nhiều lập trình viên đây là một sự thay đổi phương pháp luận hơn là một sự thay đổi công nghệ. Mặt khác, những người theo chủ nghĩa tổng quát và những người có tư duy giải quyết vấn đề đã coi WCF WF AppFnai là một tập hợp các cơ hội thú vị. Vì vậy, nếu hỗn hợp những người trong dự án là các nhà phát triển C # khá bảo thủ gắn liền với tập hợp OO và các mẫu hàng ngày của họ, thì sẽ rất khó để giới thiệu. Nếu nhóm đổi mới hơn, thì việc áp dụng sẽ dễ dàng hơn nhiều vì tiềm năng và những cánh cửa mới sẽ nhân lên với mỗi khám phá.

Hai vấn đề khái niệm chính mà các lập trình viên gặp phải khi chuyển sang công nghệ này là: a) Tương quan thông điệp và các mẫu trao đổi lộn xộn b) Quy trình làm việc và kiểm thử đơn vị Trong các hệ thống tiêu chuẩn trong C #, quy trình làm việc hiếm khi rõ ràng và do đó hiếm khi kiểm tra đơn vị. Quy trình tổng thể còn lại để kiểm tra theo các kịch bản chấp nhận hoặc tích hợp. Giới thiệu một WF rõ ràng như một tạo tác phần mềm và đột nhiên các nhà phát triển tiêu chuẩn muốn thử và kiểm tra đơn vị nó, điều này thường không đáng làm.

Khía cạnh tương quan thông điệp của nó là một chút thay đổi tư duy đối với những người không quen thuộc với các mẫu trao đổi thông điệp. Hầu hết các nhà phát triển đã xử lý các cuộc gọi theo quy trình và từ xa, dịch vụ web và SOAP, và thường tập trung vào một hoặc hai trong số đó. Để trừu tượng hóa trên tất cả và làm việc với một hệ thống dựa trên thông điệp chung có thể gây nhầm lẫn lúc đầu.

Tuy nhiên, về mặt tích cực, kết quả cuối cùng là thứ tiết kiệm được nhiều thời gian và tạo ra rất nhiều cơ hội. Một điều chính là quy trình từ khóa, nếu rõ ràng về mặt trực quan, là thứ có thể được thực hiện bởi người dùng cuối, nhà phát triển và nhà phân tích cùng nhau, loại bỏ các bước không cần thiết trong vòng đời phát triển và tập trung các bên vào một tạo tác. Hơn nữa, nó không khuyến khích các đảo chức năng trong các ứng dụng chuyên dụng, với các lớp keo chuyên dụng, bằng cách khuyến khích một bộ quy trình kinh doanh trong WF cho mỗi miền doanh nghiệp. Hơn nữa, với AppFnai, hệ thống ống nước để duy trì hoạt động, ghi nhật ký và đánh thức các hoạt động theo lịch trình đều được thực hiện cho bạn. Hiệu suất WF4 cũng rất xuất sắc.

Đề xuất của tôi là tìm thành viên nhóm sáng tạo hoặc có khả năng khám phá cao nhất thực hiện công việc trinh sát ban đầu để phát hiện ra những phần phức tạp, làm cho các chức năng cốt lõi hoạt động và yêu cầu người ban đầu đó chịu trách nhiệm phân chia công việc còn lại.

Để thực hiện một hệ thống yêu cầu bảo hiểm ở bất kỳ mức độ phức tạp nào liên quan đến các vai trò và "nhiệm vụ phụ", bạn thực sự cần một giải pháp BPM, không chỉ quy trình làm việc. Workflow Foundation 4.0 rất mượt mà nhưng nó thực sự không đến gần với các chức năng của một sản phẩm BPM.

Các giải pháp BPM, như Metastorm BPM, Global360 và K2.NET, cung cấp quy trình làm việc, nhiệm vụ, vai trò và tích hợp hệ thống lấy con người làm trọng tâm, có thể lập mô hình và hợp lý hóa các quy trình kinh doanh như hệ thống yêu cầu bảo hiểm của bạn. Sử dụng ASP.NET để xây dựng giao diện tích hợp với công cụ luồng công việc BPM vì các nhà thiết kế tích hợp sẵn của chúng thường bị hạn chế và buộc bạn phải sử dụng điều khiển web được xây dựng tùy chỉnh của họ thường không có đầy đủ tính năng như điều khiển web ASP.NET.

Sử dụng công nghệ mà nhóm của bạn biết và cảm thấy thoải mái. Workflow Foundation không phải là một sản phẩm mà bạn có thể sử dụng ngay lập tức - nó là một tập hợp các phần bạn có thể nhúng vào ứng dụng của mình để xây dựng một hệ thống quy trình làm việc. IMHO logic quy trình làm việc là phần công nghệ ít quan trọng nhất, trước hết bạn phải tập trung vào GUI vì các chủ doanh nghiệp sẽ không thấy gì ngoài GUI. Nhưng nếu hệ thống của bạn thành công thì bạn phải chuẩn bị cho các yêu cầu thay đổi liên tục và các yêu cầu mới, do đó bạn phải triển khai logic nghiệp vụ của mình để dễ thay đổi và dễ chia thành các quy trình riêng biệt để phù hợp với nhu cầu người dùng khác nhau (đôi khi mâu thuẫn) . BPM giúp ích trong công việc này vì nó cho phép bạn có nhiều phiên bản quy trình kinh doanh riêng biệt, đáp ứng các nhu cầu kinh doanh khác nhau. Bạn không' không cần công cụ BPM chính thức đầy đủ cho điều đó nhưng nó hữu ích để mã hóa logic kinh doanh của bạn để nó có thể được tạo phiên bản và chia thành các quy trình kinh doanh riêng lẻ - điều tồi tệ nhất có là một khối mã không thể sửa chữa và xen kẽ xử lý 'mọi thứ' và điều đó không một người có thể hiểu. Có nhiều ý tưởng cho điều đó - máy trạng thái, DSL (ngôn ngữ miền cụ thể), tập lệnh, v.v. - bạn quyết định việc triển khai nên như thế nào. Nhưng bạn nên luôn suy nghĩ về các quy trình kinh doanh và tổ chức logic của bạn cho phù hợp để nó phản ánh các quy trình này. Và hãy chuẩn bị cho sự tồn tại của nhiều biến thể của cấu trúc dữ liệu và logic nghiệp vụ - đây là nhiệm vụ thiết kế khó nhất. hữu ích để viết mã logic kinh doanh của bạn để nó có thể được tạo phiên bản và chia thành các quy trình kinh doanh riêng lẻ - điều tồi tệ nhất có thể xảy ra là một khối mã không thể hiểu được và xen kẽ có thể xử lý 'mọi thứ' và không ai có thể hiểu được. Có nhiều ý tưởng cho điều đó - máy trạng thái, DSL (ngôn ngữ miền cụ thể), tập lệnh, v.v. - bạn quyết định việc triển khai nên như thế nào. Nhưng bạn nên luôn suy nghĩ về các quy trình kinh doanh và tổ chức logic của bạn cho phù hợp để nó phản ánh các quy trình này. Và hãy chuẩn bị cho sự tồn tại của nhiều biến thể của cấu trúc dữ liệu và logic nghiệp vụ - đây là nhiệm vụ thiết kế khó nhất. hữu ích để viết mã logic kinh doanh của bạn để nó có thể được tạo phiên bản và chia thành các quy trình kinh doanh riêng lẻ - điều tồi tệ nhất có thể xảy ra là một khối mã không thể hiểu được và xen kẽ có thể xử lý 'mọi thứ' và không ai có thể hiểu được. Có nhiều ý tưởng cho điều đó - máy trạng thái, DSL (ngôn ngữ miền cụ thể), tập lệnh, v.v. - bạn quyết định việc triển khai nên như thế nào. Nhưng bạn nên luôn suy nghĩ về các quy trình kinh doanh và tổ chức logic của bạn cho phù hợp để nó phản ánh các quy trình này. Và hãy chuẩn bị cho sự tồn tại của nhiều biến thể của cấu trúc dữ liệu và logic nghiệp vụ - đây là nhiệm vụ thiết kế khó nhất. DSL (ngôn ngữ cụ thể của miền), tập lệnh, v.v. - bạn quyết định việc triển khai nên như thế nào. Nhưng bạn nên luôn suy nghĩ về các quy trình kinh doanh và tổ chức logic của bạn cho phù hợp để nó phản ánh các quy trình này. Và hãy chuẩn bị cho sự tồn tại của nhiều biến thể của cấu trúc dữ liệu và logic nghiệp vụ - đây là nhiệm vụ thiết kế khó nhất. DSL (ngôn ngữ cụ thể của miền), tập lệnh, v.v. - bạn quyết định việc triển khai nên như thế nào. Nhưng bạn nên luôn suy nghĩ về các quy trình kinh doanh và tổ chức logic của bạn cho phù hợp để nó phản ánh các quy trình này. Và hãy chuẩn bị cho sự tồn tại của nhiều biến thể của cấu trúc dữ liệu và logic nghiệp vụ - đây là nhiệm vụ thiết kế khó nhất.

Tôi đang ở trong tình huống phải sử dụng 4.0 vì .NET 4.5 chưa được công nhận để sử dụng trong môi trường sản xuất của chúng tôi. Nhìn chung, tôi đã hiểu rất rõ về việc làm thế nào để quy trình làm việc dài hạn phù hợp với nhu cầu kinh doanh của chúng tôi nhưng cuối cùng đã tìm ra một giải pháp hữu ích. Đó không phải là thứ mà chỉ những ai đến sau để hỗ trợ có thể dễ dàng tiếp nhận vì có quá nhiều thứ để suy nghĩ, nhưng tôi tin tưởng vào WF như một công cụ để quản lý trạng thái quy trình làm việc.

Tuy nhiên, một điều lớn mà tôi gặp phải với WF 4.0 là nhận xét của Maurice:

Điều cơ bản là không bao giờ thay đổi quy trình làm việc hiện có, luôn tạo quy trình mới

Điều đó thật tuyệt nếu bạn chỉ muốn có một phiên bản mới, nhưng điều gì sẽ xảy ra nếu bạn có 50.000 quy trình làm việc liên tục và tại một thời điểm nào đó nhận ra rằng có một lỗi trong quy trình làm việc? Bạn cần có thể cập nhật xamlx và vẫn được kết hợp với các phiên bản hiện có. Tôi đã thử giải nén các cột siêu dữ liệu khác nhau trong bảng phiên bản SQL Server để tìm thứ gì đó liên kết phiên bản với định nghĩa dòng công việc mà không gặp may.

Tôi đã viết một ứng dụng đồng bộ hóa để nhập dữ liệu từ hệ thống cũ vào hệ thống điều khiển WF 4.0 mới của chúng tôi. Về cơ bản, chúng tôi tải dữ liệu vào hệ thống, sau đó chạy quy trình tự động gọi vào các bước của quy trình làm việc và gọi các phương thức xác thực, về cơ bản là bắt chước tương tác của người dùng. Điều này chỉ thực sự hoạt động tốt với chúng tôi do kiến ​​trúc mà chúng tôi đã triển khai để truy cập vào máy chủ dịch vụ quy trình làm việc. Đó là một cách tuyệt vời, nơi mà sau khi chạy, bạn có thể kiểm tra và kiểm tra để đảm bảo tính nhất quán của quá trình di chuyển dữ liệu, nhưng việc phải sử dụng phương pháp này cho hàng trăm nghìn trường hợp sau khi hệ thống hoạt động không thực sự là một cách tiếp cận tạo sự tự tin và tạo gánh nặng cho quá trình tích hợp, sửa các lỗi đơn giản.

Khuyến nghị của tôi là bạn nên tránh hoàn toàn WF 4.0 và chỉ chuyển thẳng đến 4.5 nếu môi trường của bạn hỗ trợ nó. Cập nhật động và Phiên bản song song nó cung cấp cho việc sửa lỗi và lập phiên bản WF hoàn toàn mới. Tôi vẫn chưa điều tra chính xác làm thế nào vì 4.5 vẫn chưa được khách hàng của chúng tôi công nhận để sử dụng, nhưng rất háo hức chờ đợi cơ hội này.

Điều tôi vô cùng hy vọng là khách hàng của chúng tôi không yêu cầu thay đổi chính sách (và do đó là điều chỉnh quy trình làm việc) và quy trình công việc hiện tại được duy trì mà không có bất kỳ lỗi nào. Điều thứ hai là một hy vọng viển vông và trống rỗng vì lỗi luôn xuất hiện.

Tôi thực sự không thể hiểu những gì đã trải qua những người đứng đầu nhóm phát triển WF để phát hành một hệ thống mà bạn không thể sửa lỗi dễ dàng. Họ nên phát triển một kỹ thuật để liên kết lại một thể hiện với xamlx mới.