您好,登錄后才能下訂單哦!
針對OA移動審批的問題,仿照費控系統郵件回復審批工作流的實現思路,提出在轉交下一步的時候直接推送郵件到審批人的外部郵箱,審批人收到郵件以后回復內容就可以審批。此審批方式能很好的解決移動審批的工作,也可以相對提高兼容性。
方案的主體思路就是通過郵件服務來解決辦公設備在互聯網同業務域系統之間的數據交換問題。流程平臺發送申請審批郵件、監聽審批郵件、自動接收并進行解析處理,將郵件賬號、審批結果同任務編號等信息關聯,從而提交郵件審批任務的方式推進流程執行。
流程運行平臺在產生任務的時候,如果任務可以支持郵件審批,就發送任務相關的審批郵件到對應的審批人。審批人收到郵件后,填寫批復內容并回復郵件。運行平臺接收郵件并解析,找到對應的流程人工任務并提交。
郵件審批時序圖:
關鍵步驟描述:
創建審批任務及上下文:是指審批任務創建后,如果任務需要支持郵件審批(郵件審批與普通審批方式一般是并存的)則需要額外創建郵件審批相關的上下文記錄到數據庫中。記錄的上下文目的是能夠將回復郵件準確的同任務關聯以及安全校驗避免仿冒郵件進行審批。上下文需要包含如下字段:任務ID、審批人郵件、發送日期、審批有效時間等
發送審批郵件:通過SMTP方式發送郵件到審批人郵箱,發件人為流程平臺本身的系統郵箱,收件人為審批人郵箱。郵件正文中除了審批任務的表單信息之外,還應明確告訴審批人回復郵件的格式要求,以及注意事項。郵件示例如下:
審批人接收郵件:審批人通過手機、平板、筆記本電腦等終端的郵件客戶端接收郵件。業務系統完成功能后需要對常用的郵件客戶端進行測試驗證。
審批人回復審批結果郵件:審批人通過手機、平板、筆記本電腦等終端的郵件客戶端回復審批郵件。回復格式及注意事項需要在原郵件中想審批人說明。
流程平臺接收審批郵件:流程平臺通過郵件接收協議來獲取審批郵件,常見的郵件服務器支持的郵件獲取協議有POP3\IMAP,還有微軟的EXCHANGE郵件服務器,接收程序需要根據郵件服務器開發的協議編寫郵件接收程序
解析郵件內容,關聯任務上下文:收到郵件后,需要解析郵件上下文,獲取安全秘鑰并解密,同任務上下文進行關聯校驗。校驗通過后執行后續動作。
提交任務推進流程:根據郵件關聯的任務ID和郵件內容中的審批結果提交對應的流程任務實例,并設置審批結果到上下文。
工作內容 | 難度 | 工作量 | 備注 |
回復郵件的監聽和獲取 | ★★★★★ | 10d | 基于zimbra二次開發關聯或直接采用接收協議攔截 |
郵件正文的移動端兼容 | ★★★/★ | 5d/1d | 考慮使用以上郵件模板,不嵌入pc web表單。如嵌入pc web表單 5d,不嵌入1d |
郵件的內容解析和與流程系統的聯動 | ★★★ | 5d | |
測試 | 1d | ||
buffer | 4d | ||
合計 | 25d/21d |
1.工作流審批不僅僅是簡單的審批通過或者審批不通過這樣簡單,所以需要有各種表達;僅采用審批通過/不通過具有嚴重局限性,以上方案無法通過擴展解決這一局限性;
2.由于PC和手持設備瀏覽器兼容性問題,不可能在郵件中提供豐富的交互界面;以本系統為例,如嵌入表單,需要對表單的表達作大量修改,以適應手持設備;
3.對回復郵件的監控(一般采用不間斷輪詢,或者郵件服務器提供的某種監控功能)和解析,會影響系統的性能;
綜合上面的問題可以看到我們需要一套標準的約定實現郵件和OA工作流系統的交互,否則系統是不會識別的,就像我們平時的短信回復也只能是簡單的Y和N,而不能實現較為復雜的交互。
1.通達用戶社區
2.流程同郵件交互審批方案
3.用友U8+工作流如何設置郵件審批
4.工作流郵件審批設置
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。