Sử dụng các mẫu quy trình làm việc để quản lý trạng thái của bất kỳ thực thể nào

Bạn đã bao giờ gặp tình huống cần quản lý trạng thái của một thực thể thay đổi theo thời gian chưa? Có rất nhiều ví dụ ra khỏi đó. Hãy bắt đầu với một việc dễ dàng:hợp nhất hồ sơ khách hàng.

Giả sử chúng ta đang hợp nhất danh sách khách hàng từ hai nguồn khác nhau. Chúng tôi có thể có bất kỳ trạng thái nào sau đây phát sinh: Đã xác định trùng lặp - hệ thống đã tìm thấy hai thực thể có khả năng trùng lặp; Bản sao đã xác nhận - người dùng xác nhận rằng hai thực thể thực sự là bản sao; hoặc Đã xác nhận duy nhất - người dùng quyết định hai thực thể là duy nhất. Trong bất kỳ tình huống nào trong số này, người dùng chỉ có quyết định có - không.

Nhưng những tình huống phức tạp hơn thì sao? Có cách nào để xác định quy trình làm việc thực tế giữa các trạng thái không? Đọc tiếp…

Mọi thứ có thể dễ dàng sai lầm như thế nào

Nhiều tổ chức cần quản lý các đơn xin việc. Trong một mô hình đơn giản, bạn có thể có một bảng được gọi là JOB_APPLICATION và bạn có thể theo dõi trạng thái của ứng dụng bằng bảng dữ liệu tham chiếu có chứa các giá trị như sau:

Các giá trị này có thể được chọn theo thứ tự bất kỳ lúc nào. Nó dựa vào người dùng cuối để đảm bảo rằng lựa chọn hợp lý và chính xác được thực hiện ở mỗi giai đoạn. Không có gì ngăn cấm một chuỗi trạng thái phi logic.

Ví dụ:giả sử rằng một đơn đăng ký đã bị từ chối. Trạng thái hiện tại rõ ràng sẽ là APPLICATION_REJECTED . Không thể làm gì ở cấp ứng dụng để ngăn người dùng thiếu kinh nghiệm chọn INVITED_TO_INTERVIEW sau đó hoặc một số trạng thái phi logic khác.

Điều cần thiết là thứ để hướng dẫn người dùng chọn trạng thái logic tiếp theo, thứ xác định quy trình làm việc hợp lý .

Và điều gì sẽ xảy ra nếu bạn có các yêu cầu khác nhau cho các loại đơn xin việc khác nhau? Ví dụ, một số công việc có thể yêu cầu ứng viên phải làm bài kiểm tra năng khiếu. Chắc chắn, bạn có thể thêm nhiều giá trị hơn vào danh sách để bao gồm những giá trị này, nhưng không có gì trong thiết kế hiện tại ngăn người dùng cuối đưa ra lựa chọn không chính xác cho loại ứng dụng được đề cập. Thực tế là có quy trình làm việc khác nhau cho các ngữ cảnh khác nhau .

Một điểm khác cần suy nghĩ:các tùy chọn được liệt kê có thực sự là tất cả các trạng thái ? Hay trên thực tế là một số kết quả ? Ví dụ, lời đề nghị về một công việc có thể được người nộp đơn chấp nhận hoặc từ chối. Do đó, JOB_OFFER_MADE thực sự có hai kết quả:JOB_OFFER_ACCEPTED và JOB_OFFER_DECLINED .

Một kết quả khác có thể là lời mời làm việc bị rút lại. Bạn có thể muốn ghi lại lý do tại sao nó bị thu hồi bằng cách sử dụng một bộ định tính. Nếu bạn chỉ thêm những lý do này vào danh sách trên, không có gì hướng dẫn người dùng cuối đưa ra các lựa chọn hợp lý.

Vì vậy, thực sự, các trạng thái, kết quả và tiêu chuẩn càng trở nên phức tạp, bạn càng cần xác định quy trình làm việc của một quy trình .

Tổ chức các quá trình, trạng thái và kết quả

Điều quan trọng là phải hiểu điều gì đang xảy ra với dữ liệu của bạn trước khi bạn cố gắng lập mô hình dữ liệu đó. Thoạt đầu, bạn có thể có xu hướng nghĩ rằng có một hệ thống phân cấp nghiêm ngặt của các loại ở đây: process → trạng thái → kết quả .

Khi xem xét kỹ hơn ví dụ trên, chúng ta thấy rằng INVITED_TO_INTERVIEW và JOB_OFFER_MADE các trạng thái có cùng kết quả có thể có, cụ thể là ACCEPTED và DECLINED . Điều này cho chúng ta biết rằng có một mối quan hệ nhiều-nhiều giữa các trạng thái và kết quả. Điều này thường đúng với các trạng thái, kết quả và vòng loại khác.

Vì vậy, ở cấp độ khái niệm, đây là những gì đang thực sự diễn ra với siêu dữ liệu của chúng tôi:

Nếu bạn chuyển đổi mô hình này sang thế giới vật lý bằng cách sử dụng phương pháp tiếp cận tiêu chuẩn, bạn sẽ có các bảng được gọi là PROCESS , STATE , OUTCOME và QUALIFIER; bạn cũng cần phải có bảng trung gian giữa chúng - PROCESS_STATE , STATE_OUTCOME và OUTCOME_QUALIFIER - để giải quyết các mối quan hệ nhiều-nhiều . Điều này làm phức tạp thiết kế.

Mặc dù phải duy trì hệ thống phân cấp hợp lý của các cấp (quá trình → trạng thái → kết quả → vòng loại), có một cách đơn giản hơn để tổ chức siêu dữ liệu của chúng tôi một cách vật lý.

Mẫu quy trình làm việc

Sơ đồ dưới đây xác định các thành phần chính của mô hình cơ sở dữ liệu quy trình làm việc:

Các bảng màu vàng ở bên trái chứa siêu dữ liệu quy trình làm việc và các bảng màu xanh lam ở bên phải chứa dữ liệu kinh doanh.

Điều đầu tiên cần chỉ ra là bất kỳ thực thể nào cũng có thể được quản lý mà không yêu cầu thay đổi lớn đối với mô hình này. YOUR_ENTITIY_TO_MANAGE bảng là một trong những quản lý quy trình làm việc. Theo ví dụ của chúng tôi, đây sẽ là JOB_APPLICATION bàn.

Tiếp theo, chúng ta chỉ cần thêm wf_state_type_process_id vào bất kỳ bảng nào chúng ta muốn quản lý. Cột này trỏ đến dòng công việc thực tế quy trình được sử dụng để quản lý thực thể. Đây không hoàn toàn là cột khóa ngoại, nhưng nó cho phép chúng tôi truy vấn nhanh WORKFLOW_STATE_TYPE cho đúng quy trình. Bảng sẽ chứa lịch sử trạng thái là MANAGED_ENTITY_STATE . Một lần nữa, bạn sẽ chọn tên bảng cụ thể của riêng mình ở đây và sửa đổi nó theo yêu cầu của riêng bạn.

Siêu dữ liệu

Các cấp độ khác nhau của quy trình làm việc được xác định trong WORKFLOW_LEVEL_TYPE . Bảng này chứa những thứ sau:

WORKFLOW_STATE_TYPE và WORKFLOW_STATE_HIERARCHY tạo thành cấu trúc Hóa đơn nguyên vật liệu (BOM) cổ điển . Cấu trúc này, rất mô tả một hóa đơn nguyên vật liệu sản xuất thực tế, khá phổ biến trong mô hình dữ liệu. Nó có thể xác định cấu trúc phân cấp hoặc được áp dụng cho nhiều trường hợp đệ quy. Chúng tôi sẽ tận dụng nó ở đây để xác định hệ thống phân cấp hợp lý của chúng tôi về các quy trình, trạng thái, kết quả và các tiêu chí định tính tùy chọn.

Trước khi có thể xác định hệ thống phân cấp, chúng ta cần xác định các thành phần riêng lẻ. Đây là những khối xây dựng cơ bản của chúng tôi. Tôi chỉ tham khảo những điều này bằng TYPE_KEY (là duy nhất) vì mục đích ngắn gọn. Đối với ví dụ của chúng tôi, chúng tôi có:

Bây giờ chúng ta có thể bắt đầu xác định hệ thống phân cấp của mình. Đây là nơi chúng tôi lấy các khối xây dựng của mình và xác định cấu trúc của chúng tôi. Đối với mỗi trạng thái, chúng tôi xác định các kết quả có thể xảy ra. Trên thực tế, một quy tắc của hệ thống quy trình làm việc này là mỗi trạng thái phải kết thúc với kết quả:

Các quy trình của chúng tôi chỉ đơn giản là một tập hợp các trạng thái mà mỗi trạng thái tồn tại trong một khoảng thời gian. Trong bảng dưới đây, chúng được trình bày theo thứ tự logic, nhưng điều này không xác định thứ tự xử lý thực tế.

Có một điểm quan trọng cần thực hiện liên quan đến hệ thống phân cấp BOM. Cũng giống như một bảng nguyên vật liệu xác định các cụm và cụm phụ cho đến các thành phần nhỏ nhất, chúng ta có một cách sắp xếp tương tự trong hệ thống phân cấp của mình. Điều này có nghĩa là chúng ta có thể sử dụng lại các 'tập hợp' và 'tập hợp con'.

Ví dụ:Cả STANDARD_JOB_APPLICATION và TECHNICAL_JOB_APPLICATION quy trình có INTERVIEW trạng thái . Đến lượt INTERVIEW trạng thái có PASSED , FAILED , CANDIDATE_CANCELLED và NO_SHOW kết quả được xác định cho nó.

Khi bạn sử dụng một trạng thái trong một quy trình, bạn sẽ tự động nhận được kết quả con của nó với nó vì nó đã là một hợp ngữ. Điều này có nghĩa là các kết quả giống nhau tồn tại cho cả hai loại đơn xin việc tại INTERVIEW sân khấu. Nếu bạn muốn có các kết quả phỏng vấn khác nhau cho các loại đơn xin việc khác nhau, bạn cần phải xác định, chẳng hạn, TECHNICAL_INTERVIEW và STANDARD_INTERVIEW nói rằng mỗi người có kết quả cụ thể của riêng mình.

Trong ví dụ này, điểm khác biệt duy nhất giữa hai loại đơn xin việc là đơn xin việc kỹ thuật bao gồm một bài kiểm tra năng khiếu.

Trước khi bắt đầu

Phần 1 của bài viết gồm hai phần này đã giới thiệu mẫu cơ sở dữ liệu dòng công việc. Nó đã chỉ ra cách bạn có thể kết hợp nó để quản lý vòng đời của bất kỳ thực thể nào trong cơ sở dữ liệu của bạn.

Phần 2 sẽ chỉ cho bạn cách xác định quy trình làm việc thực tế sử dụng các bảng cấu hình bổ sung. Đây là nơi người dùng sẽ được trình bày các bước tiếp theo được phép. Chúng tôi cũng sẽ chứng minh một kỹ thuật để giải quyết vấn đề tái sử dụng nghiêm ngặt 'tập hợp' và 'tập hợp con' trong BOM.