PROC程序處理模組，同樣是以流程圖的方式讓開發者來設計，專門用來執行企業商業邏輯與自動化處理程序。如下為其架構圖:

Processflow API: 用來與外界溝通的橋樑。

Processflow Designer: 給User或開發者所使用的流程設計器，與Workflow的設計器同一介面，差異在Activity(活動組件)不同。

Processflow Activity: 所有Process的活動組件，共有四種，基礎組件有:條件、分支、循環(迴圈)、跳出循環、子程序等；輸入組件有:開始(傳入參數)、SQL查詢(讀取資料庫)、MAIL讀入(接收)、文件讀入、Web服務讀入、網頁讀入(爬蟲)等；處理組件有:設值、程序(C#或JS)、SQL命令(回寫資料庫)、批量過帳(結合EEP TRS組件)、流程觸發(發出流程)、Web服務(呼叫外部API)等；輸出組件有:結束(傳回參數)、文件輸出、發送消息(MAIL/SMS/APP/LINE)等等。

Processflow Engine: 整個處理流程的核心引擎。

Processflow Debugger: 專屬Process的Debug工具，完全仿真Designer介面，可以進行Run(執行)/Step(單步)/Break(斷點)/View(查看變數內容)等debug功能。

 

整個引擎可以支援在Node.JS平台上執行(EEPCloud平台)與.NET CORE(.NET5或.NET6)平台上執行。

 

PROC除了可讓USER或開發者以親和的拖拉介面來進行程序流程的設計之外，還有哪些特色呢?簡述如下:

1.         立即上手，免去程式語言的學習。

2.         可讓企業使用者以PROC來規畫業務邏輯與流程，事後再交給IT部門來審核與測試或進行二次開發。

3.         傳統的程式碼通常不利於閱讀，尤其是不同的程式員所寫程式碼更是不易理解與維護。透過PROC方式，以大家共同熟悉的流程圖來設計程序，更容易被維護與調整。

4.         更佳的品質與標準化，程式設計因著個人程度差異與風格，隱藏著品質與標準化風險，以PROCLow-Code方式除了沒有程式設計的品質困擾外，更讓後端商業邏輯可以標準化。

5.         更易除錯，後端程式除錯是一件非常麻煩的事，尤其應用系統已經正式上線於正式主機上更難以除錯，PROC有著前端配合的獨立視覺化Debug系統，不管是測試環境還是正式環境都能遊刃有餘。

6.         更快的開發速度，由於把所有活動都模組化，以拖拉的方式即可設計任何後端的商業邏輯，可縮短後端的開發時程。

 

那到底PROC如何應用呢?主要可以解決以下系統開發上的幾個重要需求:

1.         可100%取代後端的Server Method，在EEPCloud中，不少商業邏輯是必須撰寫後端Server Method才能達到使用者需求，PROC可用視覺化的流程來取代。

2.         可取代資料庫的後端預存程式(Stored Procedure)，通常比較複雜的資料庫程式都會用資料庫的預存程式撰寫，除了每個資料庫有自己的SP語法不易學習與撰寫外，除錯更是不易，PROC可以取代SP的開發。

3.         簡易的RPA(Robotic Process Automation)應用，RPA也是這兩年企業非常重視的話題。可透過WebSerive讀取IOT或外部資料，或是透過FTP與Email讀取信件內容與檔案，經過AI活動組件分析後(需要外部整合)，與內部的資料庫系統進行資料交換或處理，更可自動發送EMAIL/SMS/LINE或APP的推播等訊息，來完成企業流程自動化的目地。

4.         透過"流程觸發"的活動，可整合Workflow系統，利用排程或是事件觸發PROC來自動起單(機器自動起單，人工審核)。