互聯網中工作流架構與實現的示例分析

這篇文章主要介紹互聯網中工作流架構與實現的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

工作流系統以及人力 — 業務流程交互的一些***代表性的模式分為兩個主要組件。***個組件是工作流系統以及在集成平臺上實現這些系統時它們之間的交互。第二個組件是工作流交互設計模式以及使用工作流系統之間的交互實現這些模式的方式。本論述將詳細介紹這些流程。

如果不考慮人力交互 （該要素與過程自動化和集成的很多方面語義相關），那么業務流程的完全自動化實際上是無法實現的。 人力交互存在于一些最常見的業務流程中， 如訂單審批和人力資源管理。這些人力交互包含從簡單的任務分配流程到非常復雜的業務流程通知和任務再分配等各種形式。

不同供應商的多種受歡迎的集成服務器中均提供了工作流框架。 我們將從概念上探討一些在工作流平臺以及這些平臺之間的交互中存在的主要組件。 我們還將介紹一些最常見的工作流設計模式以及使用上述組件實現這些模式的方式。

工作流系統必須支持人與系統之間的通信。 要實現這一支持， 每個工作流系統都必須提供基本的功能， 如任務分配、 標識管理、 通知、 跟蹤以及與業務流程管理 (BPM) 系統的互操作（參見圖 1）。

圖一

工作流架構的四個主要組件為： 任務管理服務、 跟蹤服務、 通知服務和標識服務。 在深入探討這些服務之前， 需要了解一下任務在工作流系統中的作用。

任務是業務流程和人之間的主要通信單元。 通常， 任務被分配給需要執行某個相關操作的用戶。 例如， 一位可能需要批準購買某些貨物的請求的主管。 通常， 用戶必須執行按照語義進行組合的一系列任務。 也就是說，主管可能將每天需要購買的所有貨物組合到一個名為 “今天的批準項” 的組中。 這些組稱為任務列表。

任務狀態

在工作流系統的生存期內， 任務列表中的任務不斷地從一種狀態切換到另一種狀態。 例如， 主管的任務首先進入 “未決” 狀態； 在主管接受該任務后，狀態更改為 “認領” 。 ***， 當主管批準該請求后， 任務進入最終狀態“完成” 。 狀態用于從概念上描述任務生存期。 一些最常見的狀態是 “未決” 、“認領” 、 “完成” 和 “失敗” 。 在 “未決” 狀態下， 任務已被創建； 在 “認領” 狀態下， 用戶認領任務并接收任務輸入數據； 在 “完成” 狀態下， 用戶已經完成任務并提供了任務的輸出數據； 在 “失敗” 狀態下， 用戶已經完成任務， 并且提供了錯誤消息。

任務通常與時間范圍相關聯： 到期、 升級、 委派和續訂。 在我們的示例中，如果主管沒有在指定的時間段內處理批準任務， 則該任務可能到期。 這一到期任務隨后可以升級到另一個操作或分配流程中。 主管還可以決定將任務委派給另一個人（例如，經理）以代替他或她執行任務。 經理也可以決定是否讓另一位經理參與進來，以便收集其他意見。如果第二位經理沒有在給定的時間范圍內處理此任務，則該任務將被續訂，以便在另一時間段內執行。

在其他方案中， 各項任務在語義上彼此相關。 對于問題 “下一個任務是什么？”的回答并不總是無足輕重。在某些情況下，必須在運行時確定答案。任務可以按順序組合在一個業務流程實例中，以便用戶了解在完成當前任務后要執行的下一個任務。

在我們的示例中，主管需要依次批準20個請求才能完成該業務流程。主管每次完成一項批準之后，引擎都應該能夠標識下一個任務。“任務鏈”代表一種元數據驅動方法，該方法用來描述業務流程范圍內的一組任務之間的關系。任務鏈可以按照語義組合任務，以幫助用戶實現某些功能，如順序執行和失敗管理。

依賴于特定業務流程的任務稱為內聯任務。完全獨立于特定業務流程的任務是獨立任務。內聯任務通常可以訪問與業務流程相關的數據，并且存儲在本地的、業務流程元素（如變量或消息）中。相比之下，獨立任務通過定義良好的接口與業務流程進行交互，完全不依賴于流程數據本身。

工作流服務

處理局部任務的架構組件是任務管理服務。在典型方案中，任務管理服務接收任務創建請求， 與標識服務進行交互以選擇有資格執行此任務的所有人員，將任務添加到與所選用戶相關聯的工作列表（待完成工作）中，并分配特定的時間線和策略。最終，一個用戶通過認領該任務來決定對其進行處理。然后，該用戶可以處理該任務或請求更多的數據。

工作流系統的一個關鍵方面是能夠解析允許執行任務的用戶集。此用戶解析流程可以基于與標識管理平臺之間的交互。在我們的示例中，工作流服務需要標識哪些用戶能夠批準請求，在此情況下是主管。 要完成此標識， 工作流平臺必須對照傳統上存儲在用戶目錄中的一組用戶和角色來解析“主管” 概念。

在人與流程之間可以建立多種類型的關系。最常見的關系之一就是人與流程進行交互的方式（人力角色）。可以將組織中的人組合到在語義上與某個業務活動相關的角色中，如流程管理員或任務所有者。另一種常見的關系是流程如何標識要與哪些人交互（人員鏈接和查詢）。在業務流程中，某些用戶組從業務觀點來看是相關的。人員鏈接用于表示參與流程執行的不同組人員。針對組織目錄進行的查詢用于確定與人員鏈接相關聯的個人，而且被綁定到人員鏈接。在我們的示例中，普通的人力角色 — 財務經理可以由人員鏈接主管限定， 后者被綁定到以下查詢：“選擇部門領導，其中部門名稱為財務”。

身份服務負責與用戶相關的功能，如身份驗證、授權或人員解析。用戶信息通常存儲在組織目錄（例如，Active Directory 目錄服務、LDAP 目錄或關系數據庫）中。身份服務的工作可以獨立于組織目錄。根據適配器模式，可以通過提供程序提取目錄訪問，該提供程序能夠執行查詢來獲取目錄中的信息。此方法可以從用戶的存儲區中提取工作流功能。

在我們的示例中，假設經理想要重建請求 — 批準工作流的執行，以檢查是否存在短缺。 跟蹤服務可以跟蹤與任務和任務鏈相關的狀態更改。此服務應該提供所需功能的基礎，以重建任務歷史記錄更改和執行任務分析。

在創建請求 — 批準任務時，我們還需要一種能夠通過電子郵件通知主管的服務。通知服務處理向與任務的狀態更改相關的用戶發送通知的機制。

這里討論的四個運行時服務提供了工作流系統所需的一些最常見功能的良好概覽。通過將這些服務組合起來，可處理一些最常見的工作流方案。現在，讓我們來探討一些常見的工作流模式。

任務分配模式

面向工作流的流程在業界已經存在了一些年。獲得的知識可以作為改進的基礎，以構建工作流系統。模式在不同的級別（如任務批準、任務創建和任務狀態管理）抽象工作流系統。 在此，我們不打算定義工作流模式的分類。相反，我們將從以前定義的架構的角度介紹工作流系統中的一些常見模式。

我們將從考察“單用戶工作流”示例開始。可以將任務分配給一個用戶，并且只有一個用戶可以處理該任務。例如，一名雇員通過雇員門戶提交了休假請求。該門戶啟動了一個業務流程，該流程包括一個使用簡單工作流建模的用戶任務。該任務被分配給此雇員的經理。 當經理批準或拒絕休假請求時，將經理的決定通過電子郵件通知該雇員。

對于此解決方案，通過四個交互將工作流組件組合起來。該任務是使用與任務管理服務交互的客戶端應用程序配置的；該任務的生存期或任務狀態得到了配置。作為業務流程的一部分，使用任務管理服務將任務分配到用戶組。用戶之一認領該任務，任務管理服務應用正確的策略以防止其他用戶處理同一個任務。業務流程使用任務管理服務獲取任務的狀態更新。

現在，讓我們來考慮一個順序工作流示例。順序工作流代表一個方案，在該方案中，任務必須由一組用戶按順序批準。例如，當購買訂單批準系統使用業務流程處理購買訂單時， 屬于“主管”組的一名雇員要對購買訂單進行初步評估。在初始用戶批準購買訂單之后，由該用戶的經理批準它。在經理批準后，該購買訂單被轉發至計帳和運輸部門。該解決方案包含四個交互。與任務管理服務進行交互，以配置任務和設置合適的策略。定義應該處理任務的用戶的順序。啟動與任務管理服務交互的任務。***個用戶將認領該任務以開始處理它， 處理完成后， 任務管理服務會將該任務傳送到該組中的下一個用戶。

平行工作流模式代表如下方案：一個任務必須由不同的用戶同時批準。每一個審批者都可以獨立于其他人添加備注和附件。例如，招聘流程用于招聘新雇員。每個面試人員都需要投票以支持或反對應聘者。如果有75% 的投票表示支持，則會雇用該應聘者；否則，該應聘者將會落選。此流程使用平行工作流建模，其中每個面試人員都可以獨立于其他面試人員進行投票。實現該解決方案需要五個交互。與任務管理服務進行交互，以配置任務和設置合適的策略。定義應該處理任務的用戶的順序。啟動與任務管理服務交互的任務。任務管理服務將該任務傳送給所有用戶。 任務管理服務只有在所有用戶都完成任務的處理時才能完成該任務。

使用策略進行任務分配

現在，讓我們討論一下如何使用任務分配的策略，按照該策略，需要遵循特定的規則向用戶分配任務。例如，心臟搭橋手術過程被分配給所分手術數量最少的外科醫生。此解決方案的實現通過五個交互將工作流組件組合起來。與任務管理服務進行交互，以配置任務和設置合適的策略。作為任務定義的一部分配置分配策略 — 例如，從有空的用戶中選擇所分配的任務數量最少的一個。 作為業務流程的一部分， 使用任務管理服務將任務分配到用戶組。啟動與任務管理服務交互的任務。 任務管理服務將針對可以處理該任務的潛在用戶執行任務策略，然后依次完成下列操作：選擇符合策略條件的用戶； 將任務分配給該用戶。

在 “使用升級的單用戶工作流” 示例中， 可以將任務分配給多個用戶， 但是只有一個用戶可以處理該任務。如果該任務到期，則該用戶的經理必須處理該任務。例如，技術支持服務請求流程使用戶可以提交技術支持服務請求票證。 如果收到票證的人沒有在指定的時間段內處理該票證，則該票證自動升級給此人的經理。如果在預定義時間段內沒有任何人處理該票證，則該票證被自動升級三次，直到它到達公司的CEO那里。如果CEO也沒有進行處理， 則該票證到期。

對于此解決方案的實現，通過五個交互將工作流組件組合起來。任務是使用客戶端應用程序配置的，這些應用程序與任務管理服務交互；在此步驟中配置了屬性，如任務的生存期、 升級策略或任務狀態。作為業務流程的一部分， 使用任務管理服務將任務分配到用戶組。 一個用戶認領該任務，任務管理服務應用正確的策略以防止其他用戶執行同一個任務。 如果任務到期，則任務管理服務會應用升級策略，將任務升級到正確的用戶。如果該任務再次到期， 則任務管理服務會將其取消。

在“使用委派的單用戶工作流”示例中，聲稱要處理任務的用戶可以將該任務重新分配給其他用戶。例如，在離開之前，會計主任將他或她的所有未完成的任務交給助理會計。 對于此解決方案的實現，通過四個交互將工作流組件組合起來。任務是使用客戶端應用程序配置的，這些應用程序與任務管理服務交互；配置了屬性，如任務的生存期、升級策略或任務狀態。作為業務流程的一部分， 使用任務管理服務將任務分配到用戶組。 一個用戶認領該任務，任務管理服務應用正確的策略以防止其他用戶執行同一個任務。使用適當的客戶端應用程序，用戶可以檢查能夠處理該任務的可能人員的列表。用戶將該任務重新分配給上述人員之一， 并重新調整該任務的屬性。

對于“任務鏈模式”示例，一個任務需要根據另一個任務的完成狀態而啟動。例如，在急救協調流程中，當前面的工作項目完成時，立即開始下一個工作項目。要實現此解決方案， 可以通過四個交互將工作流組件組合起來。任務是使用客戶端應用程序配置的，這些應用程序與任務管理服務交互；屬性（如任務的生存期或狀態）得到了配置。配置了任務鏈元數據， 指示第二個任務將由***個任務的完成觸發。通過任務管理服務啟動任務鏈，從而使***個任務啟動。 當***個任務完成時，任務管理服務將使用任務鏈中的元數據啟動第二個任務。

業務流程集成

可以組合使用任務管理、身份管理、跟蹤、通知等服務和客戶端應用程序來設計工作流解決方案。我們已經探討了工作流架構中存在的一些最常見的組件以及它們在一系列交互中的實現。可以使用一組人力交互模式對一些最復雜的人力 — 系統交互進行建模，而這些人力交互模式又是使用工作流組件實現的。工作流架構的這些基本組件和模式代表了業務流程集成領域中的關鍵方面，而且，它們在實現后能夠創建強大的工作流解決方案。

以上是“互聯網中工作流架構與實現的示例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！