Các trường hợp sử dụng của Công cụ quy trình làm việc

Tôi muốn biết về các vấn đề cụ thể mà bạn - trình đọc SO - đã giải quyết bằng cách sử dụng Công cụ quy trình làm việc và những thư viện / khuôn khổ nào bạn đã sử dụng nếu bạn không tự triển khai. Tôi cũng muốn biết khi nào thì Công cụ dòng công việc không phải là lựa chọn tốt nhất và nếu / cách bạn chọn thứ gì đó đơn giản hơn, như ứng dụng kiểu TaskList / WorkList / Task-Management sử dụng máy trạng thái.

Câu hỏi:

• Bạn đã sử dụng công cụ quy trình làm việc để giải quyết những vấn đề gì?
• Bạn đã sử dụng thư viện / khuôn khổ nào?
• Khi nào thì một hệ thống State Machine / Task Management đơn giản hơn là đủ?
• Phần thưởng: Bạn đã / làm thế nào để phân biệt giữa Quản lý Tác vụ và Công cụ Quy trình Công việc ?

Tôi đang tìm kiếm trải nghiệm trực tiếp.

Một số tài nguyên tôi đã kiểm tra:

• Ruote and State Machine! = Workflow Engine
• StonePath và Docs
• Tạo và Quản lý Kế hoạch Nhiệm vụ Danh sách Công việc với Oracle
• Thiết kế và triển khai công cụ quy trình làm việc - Luận văn
• Sử dụng Windows Workflow Foundation Để làm gì
• Tài liệu JBoss jBPM

Tôi cũng có thành kiến, vì tôi là tác giả chính của StonePath .

Tôi đã phát triển các ứng dụng quy trình làm việc cho Bộ Ngoại giao Hoa Kỳ, Trung tâm rà phá bom mìn nhân đạo Geneva, một số khách hàng 500 tài sản và gần đây nhất là Hệ thống Trường Công lập Washington DC. Mỗi khi tôi thấy một 'công cụ quy trình làm việc' cố gắng trở thành tài liệu tham khảo chính duy nhất cho các quy trình kinh doanh, tôi lại thấy một tổ chức đang tự chiến đấu để làm việc xung quanh công cụ này. Điều này có thể là do các giải pháp này luôn được thúc đẩy bởi nhà cung cấp / sản phẩm và sau đó kết thúc với một nhóm 'chuyên gia tư vấn' chiến thuật liên tục cung cấp ứng dụng ... nhưng vì điều này, tôi có xu hướng phản ứng tiêu cực khi nghe lợi ích của các công cụ dựa trên quy trình hứa hẹn sẽ 'tập trung các định nghĩa quy trình làm việc vào một nơi và làm cho chúng có thể lặp lại'.

Điều đó nói rằng, tôi rất thích Ruote - Tôi đã theo dõi dự án đó một thời gian và nếu tôi cần loại giải pháp đó, nó sẽ là công cụ tiếp theo mà tôi sẵn sàng thử. StonePath có một mục đích rất khác với ruote - nơi Ruote rất hữu ích cho Ruby nói chung, StonePath nhắm đến Rails, web framework được viết bằng Ruby. Trong đó Ruote nói về các quy trình kinh doanh tồn tại lâu dài và các định nghĩa liên quan của chúng, StonePath là về quản lý quy trình làm việc và tác vụ dựa trên Trạng thái. Thành thật mà nói, tôi nghĩ rằng sự phân biệt từ bên ngoài nhìn vào có thể là tinh tế - nhiều khi các loại quy trình kinh doanh giống nhau có thể được biểu diễn theo cả hai cách - mặc dù vậy, mô hình dựa trên trạng thái và nhiệm vụ có xu hướng ánh xạ với mô hình tinh thần của tôi.

Hãy để tôi mô tả những điểm nổi bật của quy trình làm việc dựa trên trạng thái. Tóm lại, hãy tưởng tượng một quy trình làm việc xoay quanh việc xử lý một thứ gì đó như khoản vay thế chấp hoặc gia hạn hộ chiếu. Khi tài liệu di chuyển 'quanh văn phòng', nó sẽ di chuyển từ trạng thái này sang trạng thái khác. Hãy tưởng tượng nếu bạn chịu trách nhiệm về tài liệu và sếp của bạn hỏi bạn cập nhật trạng thái vài giờ một lần và muốn có một câu trả lời ngắn gọn ... bạn sẽ nói những điều như "Nó đang được nhập dữ liệu" ... "Chúng tôi đang kiểm tra thông tin đăng ký của ứng viên bây giờ "..." chúng tôi đang chờ đánh giá chất lượng "..." Chúng tôi đã hoàn thành "... và v.v. Đây là các trạng thái trong quy trình làm việc dựa trên trạng thái. Chúng ta chuyển từ trạng thái này sang trạng thái khác thông qua các chuyển đổi - như "chấp thuận", "áp dụng", lại quả "," từ chối ", v.v. Đây có xu hướng là động từ hành động.

Phần tiếp theo của quy trình làm việc dựa trên trạng thái / nhiệm vụ là tạo các nhiệm vụ. Nhiệm vụ là một đơn vị công việc, thường có ngày đến hạn và hướng dẫn xử lý, kết nối một hạng mục công việc (ví dụ: đơn xin vay hoặc gia hạn hộ chiếu), với người dùng "trong hộp". Nhiệm vụ có thể xảy ra song song với nhau hoặc tuần tự và chúng ta có thể tạo nhiệm vụ tự động khi chúng ta nhập trạng thái, tạo nhiệm vụ theo cách thủ công khi mọi người nhận ra công việc cần phải hoàn thành và yêu cầu nhiệm vụ phải hoàn thành trước khi chúng ta có thể chuyển sang trạng thái mới. Tất cả loại hành vi này là tùy chọn và là một phần của định nghĩa quy trình làm việc.

Hố thỏ có thể sâu hơn thế này rất nhiều, và tôi đã viết một bài báo về nó cho Số 4 của PragPub, Tạp chí Lập trình viên Thực dụng. Kiểm tra liên kết reo lại ở trên để biết bản PDF cập nhật của bài báo đó.

Khi làm việc với StonePath trong vài tháng qua, tôi nhận thấy rằng mô hình dựa trên trạng thái thực sự phù hợp với các kiến ​​trúc web yên tĩnh - đặc biệt, các nhiệm vụ và chuyển đổi trạng thái ánh xạ độc đáo dưới dạng các tài nguyên lồng nhau. Mong đợi để xem các bài viết trong tương lai từ tôi về chủ đề này.

Tôi thiên vị, tôi là một trong những tác giả của ruote .

biến thể 1) máy trạng thái được gắn vào tài nguyên (tài liệu, đơn đặt hàng, hóa đơn, sách, đồ đạc).

biến thể 2) máy trạng thái được gắn với tài nguyên ảo có tên là một nhiệm vụ

biến thể 3) công cụ quy trình làm việc diễn giải các định nghĩa quy trình công việc

Bây giờ câu hỏi của bạn được gắn thẻ "BPM", chúng tôi có thể được mở rộng thành "Quản lý quy trình kinh doanh". Làm thế nào để loại quản lý đó xảy ra trong mỗi biến thể?

Trong biến thể 1, quy trình nghiệp vụ (hoặc quy trình làm việc) nằm rải rác trong ứng dụng. Máy trạng thái được gắn với tài nguyên thực thi một số khía cạnh của quy trình làm việc, nhưng chỉ những khía cạnh liên quan đến tài nguyên. Có thể có các tài nguyên khác với máy trạng thái của riêng chúng theo cùng một quy trình nghiệp vụ.

Trong biến thể 2, dòng công việc có thể được tập trung xung quanh tài nguyên tác vụ và được đại diện bởi máy trạng thái xung quanh tài nguyên đó.

Trong biến thể 3, quy trình làm việc được thực hiện bằng cách diễn giải một tài nguyên được gọi là định nghĩa quy trình công việc (hoặc định nghĩa quy trình nghiệp vụ).

Điều gì xảy ra khi quy trình kinh doanh thay đổi? Có đáng để có một công cụ quy trình làm việc nơi các quy trình kinh doanh là tài nguyên có thể quản lý được không?

Hầu hết các thư viện máy trạng thái đều có 1 bộ trạng thái + chuyển tiếp. Công cụ quy trình làm việc hầu hết là trình thông dịch định nghĩa quy trình làm việc và chúng cho phép nhiều quy trình công việc khác nhau chạy cùng nhau.

Chi phí thay đổi quy trình làm việc sẽ là bao nhiêu?

Các biến thể không loại trừ lẫn nhau. Tôi đã thấy nhiều ví dụ trong đó công cụ dòng công việc thay đổi trạng thái của nhiều tài nguyên, một số trong số chúng được bảo vệ bởi máy trạng thái.

Tôi cũng sử dụng biến thể 3 + 2 rất nhiều, cho các tác vụ của con người: công cụ quy trình làm việc, tại một số thời điểm khi chạy một phiên bản quy trình, giao một nhiệm vụ (workitem) cho người tham gia (tác vụ tài nguyên được tạo và đặt ở trạng thái 'sẵn sàng') .

Bạn có thể đi một chặng đường dài với biến thể 2 một mình (biến thể trình quản lý tác vụ).

Chúng tôi cũng có thể đề cập đến biến thể 0), trong đó không có máy trạng thái, không có công cụ quy trình làm việc và (các) quy trình kinh doanh nằm rải rác và / hoặc được mã hóa cứng trong ứng dụng.

Bạn có thể đặt nhiều câu hỏi, nhưng nếu bạn không dành thời gian để đọc câu trả lời và không dành thời gian để thử và thử nghiệm, bạn sẽ không tiến xa được và sẽ không bao giờ có được sự tinh tế nào khi sử dụng công cụ này hoặc công cụ kia.

Trong một dự án trước đây mà tôi đang thực hiện, tôi đã thêm một số quy tắc loại Quy trình làm việc vào một bộ Biểu mẫu chính phủ trong ngành Chăm sóc sức khỏe.

Người dùng cuối cần phải điền vào các biểu mẫu và tùy thuộc vào một số câu trả lời, các biểu mẫu khác đã được lên lịch để điền vào một ngày sau đó. Cũng có những sự kiện bên ngoài sẽ hủy bỏ các Biểu mẫu đã lên lịch hoặc lên lịch cho các Biểu mẫu mới.

Dòng mẫu:

Bệnh nhân được nhận -> Lên lịch đánh giá ban đầu FOrm -> Lên lịch biểu mẫu đánh giá hàng quý -> Bệnh nhân đã chết -> Hủy đánh giá -> Lên lịch biểu mẫu đánh giá xuất viện

Nhiều quy tắc khác dựa trên những thứ như tuổi của bệnh nhân, nơi họ được nhận vào v.v.

Đây là một ứng dụng ASP.NET, các quy tắc về cơ bản là một bảng trong cơ sở dữ liệu. Tôi đã thêm tập lệnh, vì vậy một tập lệnh sẽ chạy khi hoàn thành Biểu mẫu để xác định việc cần làm tiếp theo. Đây là một thiết kế kinh khủng và sẽ hoàn hảo cho một công cụ Quy trình làm việc phù hợp.

Tôi là một trong những tác giả của Cadence Workflow Engine mà chúng tôi đã phát triển tại Uber. Sự khác biệt giữa Cadence và phần lớn các công cụ quy trình làm việc hiện tại là nó tập trung vào nhà phát triển và cực kỳ linh hoạt và có thể mở rộng (lên đến hàng chục nghìn bản cập nhật mỗi giây và lên đến hàng tỷ quy trình mở). Dòng công việc được viết dưới dạng chương trình hướng đối tượng và công cụ đảm bảo rằng trạng thái của các đối tượng dòng công việc bao gồm ngăn xếp luồng và các biến cục bộ được bảo toàn đầy đủ trong trường hợp máy chủ bị lỗi.

Bạn đã sử dụng công cụ quy trình làm việc để giải quyết những vấn đề gì? Cadence được sử dụng thực tế cho bất kỳ ứng dụng phụ trợ nào vượt quá một phản hồi yêu cầu duy nhất. Ví dụ về cách sử dụng là:

• Việc làm CRON được phân phối
• Quản lý đường ống ML / Dữ liệu
• Phản ứng với các sự kiện kinh doanh. Ví dụ các sự kiện chuyến đi tại Uber. Dòng công việc có thể tích lũy trạng thái dựa trên các sự kiện nhận được và thực thi các hoạt động khi cần thiết.
• Triển khai dịch vụ tới Mesos / Kubernetes
• Triển khai đường ống CI
• Đảm bảo rằng nhiều cuộc gọi dịch vụ sẽ hoàn tất khi nhận được yêu cầu. Bao gồm triển khai mẫu SAGA
• Quản lý các tác vụ của nhân viên (tương tự như Amazon MTurk )
• Xử lý phương tiện
• Định tuyến vé hỗ trợ khách hàng
• Xử lý đơn hàng
• Dịch vụ thử nghiệm tương tự như ChaosMonkey

và nhiều người khác

Tập hợp các trường hợp sử dụng khác dựa trên việc chuyển các công cụ dòng công việc hiện có để chạy trên Cadence. Thực tế, bất kỳ ngôn ngữ đặc tả quy trình công việc động cơ hiện có nào cũng có thể được chuyển sang chạy trên Cadence. Có nhiều hệ thống Uber nội bộ đã được chuyển. Bằng cách này, một dịch vụ phụ trợ duy nhất có thể cung cấp năng lượng cho nhiều hệ thống quy trình làm việc cụ thể của miền.

Bạn đã sử dụng thư viện / khuôn khổ nào?

Cadence là một dịch vụ độc lập được viết bằng Go với Go và các thư viện phía máy khách Java . Sự phụ thuộc bên ngoài duy nhất là lưu trữ. Cơ sở dữ liệu Cassandra và SQL được hỗ trợ.

Cadence cũng hỗ trợ sao chép vùng chéo không đồng bộ (sử dụng thuật ngữ AWS).

Khi nào thì một hệ thống State Machine / Task Management đơn giản hơn là đủ?

Bên trong Uber, dịch vụ Cadence do nhóm của chúng tôi quản lý. Vì vậy, chi phí xây dựng bất kỳ máy / tác vụ trạng thái tùy chỉnh nào luôn cao hơn so với sử dụng Cadence. Bên ngoài công ty, dịch vụ và lưu trữ cho nó cần phải được thiết lập. Nếu bạn đã có một cơ sở dữ liệu SQL thì việc triển khai dịch vụ là không đáng kể thông qua hình ảnh docker. Docker cũng được sử dụng để chạy dịch vụ Cadence cục bộ để phát triển trên máy tính cá nhân hoặc máy tính xách tay.

Kiểm tra đá quý rails_workflow - Tôi nghĩ nó gần giống với những gì bạn đang tìm kiếm.

Tôi là một trong những tác giả của Imixs-Workflow . Imixs-Workflow là một công cụ quy trình làm việc mã nguồn mở dựa trên BPMN 2.0 và được tích hợp hoàn toàn vào ngăn xếp công nghệ Java EE.
Tôi tự mình phát triển công cụ quy trình làm việc từ hơn 10 năm nay. Tôi sẽ cố gắng trả lời câu hỏi của bạn trong ngắn hạn:

> Bạn đã sử dụng công cụ xử lý công việc để giải quyết những vấn đề gì?

Mục tiêu cá nhân của tôi khi tôi bắt đầu nghĩ về công cụ quy trình làm việc là tránh viết mã logic nghiệp vụ khó trong ứng dụng của mình. Nhiều thứ trong một ứng dụng kinh doanh có thể được sử dụng lại vì vậy việc giữ cho chúng có thể định cấu hình là rất hợp lý. Ví dụ:

• gửi thông báo
• xem các nhiệm vụ đang mở
• giao nhiệm vụ cho một người
• mô tả nhiệm vụ hiện tại

Từ danh sách chức năng này, bạn có thể thấy tôi đang nói về quy trình làm việc lấy con người làm trung tâm. Tóm lại: Một cỗ máy quy trình làm việc lấy con người làm trung tâm trả lời các câu hỏi: Ai chịu trách nhiệm cho một nhiệm vụ và ai cần được thông báo tiếp theo? Và đây là những câu hỏi điển hình trong yêu cầu kinh doanh.

> Bạn đã sử dụng thư viện / khuôn khổ nào?

5 năm trước, chúng tôi đã bắt đầu hoàn thiện lại công cụ Imixs-Workflow tập trung vào BPMN 2.0 . BPMN là tiêu chuẩn chung cho mô hình hóa quy trình. Và điều đáng ngạc nhiên đối với tôi là chúng tôi đột nhiên có thể mô tả các quy trình kinh doanh thậm chí rất phức tạp có thể được hình dung và thực thi. Tôi khuyên mọi người nên sử dụng BPMN để lập mô hình các quy trình kinh doanh.

> Khi nào thì một hệ thống State Machine / Task Management đơn giản hơn là đủ?

Một máy trạng thái đơn giản là đủ nếu bạn chỉ muốn theo dõi trạng thái của một đối tượng kinh doanh. Đây là trường hợp khi bạn bắt đầu đưa thuộc tính 'status' vào mô hình đối tượng của mình. Nhưng trong trường hợp bạn cần các quy trình nghiệp vụ với trách nhiệm, ghi nhật ký và kiểm soát luồng, thì máy trạng thái không còn đủ nữa.

> Phần thưởng: Bạn đã / làm thế nào để phân biệt giữa Quản lý Tác vụ và Công cụ Quy trình Công việc?

Đây chính xác là điểm mà nhiều công cụ quy trình làm việc được đề cập ở đây khác nhau. Đối với quy trình làm việc lấy con người làm trung tâm, bạn thường cần quản lý tác vụ để phân phối nhiệm vụ giữa các tác nhân là con người. Đối với tự động hóa quy trình, điểm này không quá phù hợp. Nó là đủ nếu động cơ thực hiện các nhiệm vụ nhất định. Không thể so sánh công cụ quản lý tác vụ và công cụ dòng công việc vì quản lý tác vụ luôn là một chức năng của công cụ dòng công việc.

Tôi đã triển khai công cụ quy trình làm việc của riêng mình để hỗ trợ xử lý tài liệu theo từng giai đoạn - lập danh mục, gửi để xử lý hình ảnh (chúng tôi làm việc với redaction sw), nếu cần, gửi đến xác thực, sau đó phát hành và cuối cùng gửi lại cho khách hàng. Trong trường hợp của chúng tôi, chúng tôi có một lượng tài liệu cần xử lý nên đôi khi chúng tôi cần chạy từng dịch vụ riêng biệt để kiểm soát việc phân phối và sử dụng tài nguyên. Đơn giản trong khái niệm nhưng cần hiệu suất cao và xử lý phân tán, và chúng tôi không thể tìm thấy bất kỳ sản phẩm nào trên kệ phù hợp với hóa đơn cho chúng tôi.

Tôi đã có kinh nghiệm sử dụng công cụ Activiti BPMN 2.0 để xử lý các quy trình truyền dữ liệu hiệu suất cao và thông lượng cao trong cơ sở hạ tầng của các nút mạng. Nhiệm vụ cơ bản là cho phép cấu hình và giám sát các quá trình truyền như vậy và kiểm soát từng nút mạng (nghĩa là. Yêu cầu nút1 gửi tệp dữ liệu đến nút2 thông qua lớp truyền tải cụ thể).

Có thể có hàng nghìn quy trình đang chạy cùng một lúc và tổng thể hàng chục hoặc hàng trăm nghìn quy trình mỗi ngày.

Có rất nhiều định nghĩa quy trình khác nhau nhưng không nhất thiết người vận hành hệ thống có thể tạo quy trình công việc tùy chỉnh. Vì vậy, trường hợp sử dụng chính cho công cụ BPM là phải mạnh mẽ, có thể mở rộng và cho phép giám sát từng luồng quy trình.

Cuối cùng thì về cơ bản nó đã hoạt động nhưng những gì chúng tôi học được từ dự án đó là nền tảng BPMN, hay cụ thể hơn là công cụ Activiti, không phải là lựa chọn tốt nhất cho một hệ thống thông lượng cao như vậy.

Những thách thức chính là ưu tiên thực thi tác vụ, khóa DB, các thử nghiệm thực thi để đặt tên cho một số ít liên quan đến chính BPM. Vì vậy, chúng tôi phải phát triển việc xử lý tùy chỉnh những điều này, ví dụ:

• Xử lý các lần thử lại trong BPM đối với các trường hợp khi một nút không có nhân viên tự do cho nhiệm vụ đã cho hoặc khi nút đó hoàn toàn không chạy.
• Thực hiện các nhiệm vụ chuyển giao song song trong một quy trình duy nhất và đồng bộ hóa kết quả (thành công / thất bại).

Tôi không biết liệu các công cụ BPMN khác có phù hợp hơn với tình huống như vậy không vì BPMN chủ yếu dành cho các nhiệm vụ kinh doanh dài hạn liên quan đến tương tác của người dùng trong đó hiệu suất có thể không phải là vấn đề giống như trường hợp của chúng tôi.