簡介面向ERP實施顧問與Tiptop二次開發(fā)人員的集成參考資料以新單據(jù)接入為例講解Tiptop與EasyflowOA簽核之間如何通過XML實現(xiàn)單據(jù)簽核的雙向聯(lián)動。文檔從環(huán)境準備、數(shù)據(jù)表7個簽核字段檢查、Schema更新、單據(jù)性質與拋轉信息維護到4GL/PER程序調整完整梳理了新單據(jù)接入Easyflow的12個關鍵步驟同時對AWS公共模塊中的配置、服務調用、日志與狀態(tài)查詢以及對應各作業(yè)的拋轉模塊分工做了說明并配有集成測試與常見錯誤列表便于實施時按圖索驥。讀者可參照其中樣例完成單頭單身欄位映射、生成并修改拋轉作業(yè)源文件并通過p_link/p_zz/p_ze完成菜單與提示信息配置最終編譯執(zhí)行驗證簽核全鏈路。資源為1個PDF文件大小1.94MB內容以步驟說明、界面操作和配置要點為主適合正在實施Tiptop OA集成或需要排查簽核異常的技術人員參考。已有1515人學習下載。1. 審核通過卻進不了 OA 收件箱Tiptop 與 Easyflow 集成的第一道坎做過 Tiptop 與 EasyflowOA單據(jù)簽核集成的開發(fā)者多半都栽過同一個跟頭Tiptop 里點了審核彈窗提示拋轉成功單據(jù)狀態(tài)也變成了“S 送簽中”可打開易拓收件箱里面空空如也或者簽核人明明在 Easyflow 里批完了Tiptop 這邊簽核狀態(tài)卻紋絲不動還停在送簽中。這種“一半通一半不通”的集成問題最難纏——它不是某個單一環(huán)節(jié)出錯而是 Tiptop 端拋轉、XML 組串、Easyflow 表單解析、回寫服務四段鏈路里任何一處斷掉都會出現(xiàn)同樣癥狀排查時經(jīng)常一個環(huán)節(jié)查半天最后發(fā)現(xiàn)根因在最不起眼的配置上。這篇筆記就按“先環(huán)境、再數(shù)據(jù)、后拋轉、最后 OA 端”的順序把集成測試階段最常見的報錯和踩坑點一次說清。文中的步驟和代碼均來自實際項目集成手冊照著改就能用。2. 環(huán)境與前提排查三個 IP 配置決定集成通不通2.1 .profile 里的 EFSITEIP / EFSITENAME / EFSOAP 配錯拋轉必然失敗Tiptop 與 Easyflow 的通信走的是 SOAPTiptop 端所有拋轉動作最終都要通過 Appserver 去訪問 Easyflow 的網(wǎng)關地址。而這個地址不是寫在某個配置文件里的而是在 Tiptop 啟動用戶的 .profile 環(huán)境變量里。這個坑最隱蔽的地方在于它不是寫在程序里很多開發(fā)者第一次排查時根本想不到去看環(huán)境變量。#EasyFlow Server IP EFSITEIP192.168.0.250; export EFSITEIP #EasyFlow Server Name EFSITENAMEEF2KWeb; export EFSITENAME #EasyFlow SOAP Location EFSOAPhttp://192.168.0.250/EF2KGateWay/EF2KGateWay.WSDL; export EFSOAP三個變量的分工很明確EFSITEIP是 Easyflow 服務器的 IPEFSITENAME是 Easyflow 的站點名EFSOAP是網(wǎng)關 WSDL 的完整地址。實際項目里最容易配錯的是第三個——有人只改到 IP忘了把端口和EF2KGateWay路徑帶上結果 Tiptop 側報 SOAP 連接失敗還有人三個變量寫的是同一個 IP但 Easyflow 服務器上實際跑了多個站點導致請求打到了錯誤的站點上。檢查方法也很直接在 Tiptop 服務器上執(zhí)行env | grep EF確認三個變量都已經(jīng)生效并且值與你手上拿到的 Easyflow 服務器信息一致。改完 .profile 后要重新登錄或source .profile再重啟 Appserver環(huán)境變量才會被新啟動的進程讀到。注意不要直接在命令行 export 完就測試Tiptop 的 Appserver 進程如果沒重啟用的還是舊環(huán)境變量這是“明明改對了卻還是報錯”的高發(fā)原因。2.2 Appserver 沒啟動最容易被忽略的“黑匣子”Tiptop 與 Easyflow 的交互依賴 AppserverTiptop for Browser 版裝好后必須先運行startweb把 Appserver 拉起來。這個前提看起來簡單但實際踩坑率極高——尤其是服務器重啟之后Tiptop 的 Console 界面能打開作業(yè)也能進但一執(zhí)行審核就卡住或直接超時因為審核代碼里調用的 SOAP 服務根本沒有可用的進程在監(jiān)聽。判斷是不是這個原因最有效的辦法是看 Appserver 的啟動日志或者直接ps -ef | grep相關進程。如果 Appserver 確實沒起來執(zhí)行startweb后等十幾秒再測試審核拋轉。集成測試階段我一般建議把 Appserver 啟動加到服務器開機腳本里避免每次重啟后都手動拉起。這個“黑匣子”式的問題最難定位就在于報錯信息往往只會給一個籠統(tǒng)的“連線失敗”或“Service Unavailable”不會告訴你其實是 Appserver 沒監(jiān)聽。2.3 服務端集成包沒裝客戶端配置全對也連不上還有一個先決條件經(jīng)常被漏掉Easyflow 服務器端必須安裝 Tiptop 與 Easyflow 的集成包并且安裝完成后 Easyflow 端才有EF2KGateWay這個服務。這個環(huán)節(jié)出了問題現(xiàn)象非常迷惑——Tiptop 端三個環(huán)境變量全對Appserver 也起來了審核時卻仍然連不上日志里報的是 SOAP 訪問異常。驗證方法可以直接在 Tiptop 服務器上用 curl 或瀏覽器訪問EFSOAP里配的那個 WSDL 地址如果能正常返回 XML 格式的 WSDL 內容說明網(wǎng)關服務通了如果返回 404 或連接拒絕基本可以斷定集成包沒裝好或對應站點沒起來。這個檢查建議放在所有集成測試的第一步五分鐘就能排除掉一大類“網(wǎng)絡不通”的誤判而不是像第一次接觸集成的人那樣先翻防火墻、再查路由折騰一圈最后發(fā)現(xiàn)是服務端壓根沒有這個服務。3. 數(shù)據(jù)表與單據(jù)性質7 個簽核欄位一個都不能少3.1 pmkmksg 與 pmk25兩個關鍵欄位缺失的典型報錯Tiptop 里一張單據(jù)要能走電子簽核其對應的數(shù)據(jù)表必須包含 7 個簽核相關欄位。前兩個是關鍵欄位是否簽核標記和簽核狀態(tài)這兩個缺失的話作業(yè)編譯時或審核執(zhí)行時會直接報錯或者界面上根本顯示不出簽核相關的欄目。欄位名稱關鍵性作用pmkmksg是否簽核關鍵該單據(jù)是否要走電子簽核pmk25簽核狀態(tài)關鍵當前簽核所處狀態(tài)pmksign簽核等級非關鍵多級簽核時使用pmkdays簽核完成天數(shù)非關鍵統(tǒng)計簽核耗時pmkprit簽核優(yōu)先順序非關鍵排序用pmksseq已簽核順序非關鍵系統(tǒng)自動維護pmksmax應簽核順序非關鍵系統(tǒng)自動維護上面以 pmk_file 請購單為例實際上每支作業(yè)的數(shù)據(jù)表欄位名都不同比如出貨單是 ta_sfbefstat、ta_sfbmksg 這類以 ta_ 開頭的客制欄位。檢查數(shù)據(jù)表時不要只找同名欄位需要根據(jù)每支作業(yè)的實際命名來確認。如果表里缺欄位需要按客制規(guī)范手工創(chuàng)建不要試圖繞過——后面拋轉作業(yè)生成的 SQL 和 XML 都以這 7 個欄位為基礎缺一個就會導致組出來的 XML 少字段Easyflow 端解析時就對不上。3.2 簽核狀態(tài)取值表狀態(tài)字符和含義對不上時的困惑簽核狀態(tài)欄位的取值是一套約定的字符編碼集成過程中經(jīng)常遇到狀態(tài)值理解錯位的情況。比如界面上顯示“開立”但表里存的是 0顯示“送簽中”表里存的是 S。如果不熟悉這套映射排查時很容易被界面提示誤導。取值含義說明0開立單據(jù)初始狀態(tài)1已核準簽核完成6結案流程結束9作廢單據(jù)作廢S送簽中已拋轉等待簽核R送簽退回簽核人退回W抽單已從 Easyflow 抽回簽核狀態(tài)機的基本流轉是 0開立→ S送簽中→ 1已核準退回走 R作廢走 9結案走 6。調試時如果發(fā)現(xiàn)單據(jù)狀態(tài)卡在某個值不動先確認當前處于哪個狀態(tài)再看對應的流轉條件是否滿足。比如審批人已經(jīng)在 Easyflow 里核準了Tiptop 這邊還是 S問題出在回寫環(huán)節(jié)如果壓根沒進 Easyflow狀態(tài)不會變成 S還是 0。這套取值規(guī)律是集成調試中判斷“問題出在哪一段”的核心依據(jù)。3.3 單據(jù)別沒有勾選“是否簽核”后續(xù)操作全部無效數(shù)據(jù)表欄位齊了也不代表所有單據(jù)都會走簽核。Tiptop 里同一支作業(yè)可以按單據(jù)別區(qū)分是否簽核這個開關在單據(jù)性質設置作業(yè)里——制造模塊是 smy_file銷售子系統(tǒng)是 oay_file不同子系統(tǒng)用的資料表不一樣設置前一定要先確認當前子系統(tǒng)對應的表。在單據(jù)性質設置界面比如通用單據(jù)性質設置作業(yè) asmi300里找到“是否簽核”選項勾選上并保存。需要注意一個細節(jié)如果這張單據(jù)已經(jīng)以未簽核的單別開立之后再去修改單別性質是不生效的必須新建或選擇“是否簽核”為選中狀態(tài)的單據(jù)別。這個坑的實際表現(xiàn)是審核后狀態(tài)正常變成 S但 Easyflow 里搜不到新表單或者在易拓集成向導里選工廠后單據(jù)類別列表里壓根看不到你想要的單別——因為向導只會列出“是否簽核”已勾選的單據(jù)類別。3.4 schema 更新與客制欄位r.s2 dsx 和 p_perlang 的連帶操作數(shù)據(jù)表結構變更后還需要更新 schema 資料r.s2 dsx并重新編譯相關作業(yè)。如果單據(jù)上有客制欄位需要顯示還要運行 p_perlang 維護欄位顯示。這一步漏掉的表現(xiàn)是作業(yè)界面能進但新加的簽核欄位顯示不出來或者顯示成亂碼/星號。在 Tiptop 環(huán)境里跑 p_perlang 時要注意語言別簡體、繁體、英文都要維護一遍否則切語言后欄位描述會丟。這一步不需要改程序邏輯但它是界面顯示的最后一道工序漏了會讓前面所有數(shù)據(jù)表工作看起來“沒生效”。另外新增作業(yè)的話還要在 p_link 里增加對 aws 的鏈接在 p_ze 里維護新增的提示信息這兩個表不維護作業(yè)上會出現(xiàn)找不到程序或提示信息為空的情況。4. 拋轉作業(yè) aws_xxx.4glXML 對不上就卡在“送簽中”4.1 aws_efcfg 自動生成后的三處必修代碼aws 模塊下的拋轉作業(yè)aws_xxx.4gl與 Tiptop 各作業(yè)一一對應比如 aws_aapt110.4gl 對應請購作業(yè)、aws_asfi301.4gl 對應工單作業(yè)。這些文件不需要從零手寫而是在 aws_efcfg 維護窗體里配置好單頭、單身欄位后點擊“產(chǎn)生范式程序”自動生成的。但自動生成只是給了你一個骨架實際項目中幾乎每支都要手工改。CASE WHEN sr.oga001 CALL cl_getmsg(aws-003,g_lang) RETURNING g_msg WHEN sr.oga002 CALL cl_getmsg(aws-004,g_lang) RETURNING g_msg WHEN sr.oga003 CALL cl_getmsg(aws-005,g_lang) RETURNING g_msg WHEN sr.oga004 CALL cl_getmsg(aws-006,g_lang) RETURNING g_msg WHEN sr.oga005 CALL cl_getmsg(aws-007,g_lang) RETURNING g_msg END CASE LET l_oga00 g_msg這段代碼的作用是把數(shù)據(jù)庫里的 oga00 取值翻譯成顯示用的中文信息再塞進 XML。為什么要這樣改因為 Tiptop 表里存的是編碼1、2、3…而 Easyflow 表單上要顯示的是中文比如單據(jù)種類名稱直接拋編碼過去簽核人看到的表單就是一堆數(shù)字。邏輯說明通過 cl_getmsg 按編碼取消息文本再賦值給中間變量 l_oga00后續(xù)拼 XML 時用的是 l_oga00 而不是 sr.oga00。參數(shù)說明sr 是存放拋轉中間信息的 RECORDl_ 開頭的變量是需要手工增加的中間變量g_lang 是當前語言環(huán)境。自動生成的文件里需要重點檢查三類情況一是數(shù)據(jù)庫欄位需要加工后再傳入 XML 的比如上例的狀態(tài)碼轉文本二是選取欄位與 XML 欄位數(shù)量不一致的多了要去掉、少了要補三是從其他表 JOIN 替代原欄位的比如客戶編號 oga04 要顯示為客戶名稱 occ02這時要在參照字段里設置讓生成的 SQL 自動把 occ_file 表 JOIN 進來組 XML 時用 occ02 替代 oga04 的位置。我一般會在生成后先跑一遍編譯把語法錯誤清掉再對照 XML 輸出逐字段核對而不是直接進 OA 端聯(lián)調——那樣報錯信息太模糊定位成本高。4.2 XML 與 ColumnSet.xml 不一致名稱必須完全對應拋轉作業(yè)組出來的 XML 字符串最終要被 Easyflow 端的 ColumnSet.xml 解析。這個文件里配置了每個表單接收哪些 XML 節(jié)點節(jié)點名稱必須與 Tiptop 拋出的 XML 完全一致。一個常見的理解誤區(qū)是很多人以為順序也要一致其實順序無關名稱才是硬性要求。oga00開立/oga00 oaydesc請購單/oaydesc oga01PO000123/oga01 oga04某供應商名稱/oga04 addr地址一 地址二 地址三/addr ouuserADMIN/ouuser注意這個例子里的ouuser手冊里特別強調XML 里必須拋轉一個資料所有者 xxxuser 欄位這個欄位不顯示在電子表單上但 Easyflow 要拿它作為填單人解析流程。漏掉這個節(jié)點常見表現(xiàn)是單據(jù)能進 Easyflow但流程起不來審批人收件箱里始終看不到。我見過有人在 ColumnSet.xml 里手誤把 ouuser 拼成 oauser結果 Tiptop 拋轉成功、Easyflow 也收到了但流程就是不走查了半天才發(fā)現(xiàn)是節(jié)點名拼寫不一致。aws_efcfg 界面上的“傳送欄位資訊”按鈕雖然能自動生成 ColumnSet.xml但實際項目里不建議用——它完全按 Tiptop 數(shù)據(jù)庫里的設置重建文件而數(shù)據(jù)庫字段和實際要拋的 XML 很難保證完全一致重建后反而容易把人工維護好的內容沖掉。這個文件的維護方式應該是復制現(xiàn)有單據(jù)的 Program 段手工修改節(jié)點名稱和位置。4.3 標準作業(yè)審核流程改造送簽后原審核代碼不再執(zhí)行拋轉作業(yè)改好了只是第一步Tiptop 標準作業(yè)本身也要改。核心是在原有審核函數(shù)中插入一段判斷讓單據(jù)在需要簽核時先走拋轉而不是繼續(xù)執(zhí)行原來的審核事務。IF g_success Y THEN IF g_oga.ta_ogamksg Y AND g_oga.ogaconf N THEN CALL t600_ef() IF g_success N THEN ROLLBACK WORK END IF RETURN #如果要走簽核流程則下面的審核過程就不自動進行了 END IF END IF這段代碼的位置很講究必須放在原審核段“完成所有判斷但尚未開始事務性操作”的位置——也就是還沒有任何 UPDATE 之前。邏輯說明先判斷是否拋轉成功g_success再判斷該單據(jù)是否需要簽核g_oga.ta_ogamksg Y以及當前是否未確認g_oga.ogaconf N滿足條件就調用 xxx_ef() 函數(shù)執(zhí)行拋轉。參數(shù)說明ta_ogamksg 是自定義的“是否簽核”欄位ogaconf 是審核狀態(tài)欄位g_success 是拋轉函數(shù)的返回值。這段邏輯帶來的一個隱蔽變化是一旦單據(jù)走了電子簽核原審核段后面的事務性操作全部不會再執(zhí)行因為函數(shù)里直接 RETURN 了。所以如果原審核代碼里有必須執(zhí)行的操作比如更新庫存、生成后續(xù)單據(jù)需要把那部分代碼拷貝生成一個新的函數(shù)并新增一個 Action比如 confirm_ef僅當簽核狀態(tài)為 1已核準時允許執(zhí)行。這里建議是“拷貝”而不是“移動”保證不走簽核的單據(jù)仍然走原審核流程對系統(tǒng)原有行為影響最小。這個坑不提前處理的話上線后會出現(xiàn)“單據(jù)簽核完了但后續(xù)單據(jù)沒有自動生成”的連鎖問題。4.4 簽核狀態(tài)瀏覽 Action改錯單據(jù)號碼就白抄除了審核流程改造每支作業(yè)還建議增加一個瀏覽簽核狀態(tài)的 Action相關代碼可以從標準作業(yè)里拷貝。這類代碼有個特點結構完全一樣但每個作業(yè)要改的單據(jù)號碼欄位和簽核狀態(tài)欄位不同抄的時候改錯一個點擊后要么沒反應要么誤報。FUNCTION i301_approval_status() IF g_aza.aza23 matches [ Nn] THEN #未設定與 EasyFlow 簽核 CALL cl_err(aza23,mfg3551,0) RETURN END IF IF g_sfb.sfb01 IS NULL OR g_sfb.sfb01 THEN #尚未查詢資料 CALL cl_err(, -400, 0) RETURN END IF IF g_sfb.ta_sfbefstat NOT MATCHES [S1WR] THEN RETURN END IF CALL aws_efstat(g_sfb.sfb01) END FUNCTION這段代碼實際調用的是 aws_efstat 公共函數(shù)把當前單據(jù)號碼傳過去查詢 Easyflow 端的簽核狀態(tài)并顯示。需要修改的部分只有兩處單據(jù)號碼欄位這里是 sfb01換成目標作業(yè)的實際單據(jù)號碼和簽核狀態(tài)欄位這里是 ta_sfbefstat。另外注意[S1WR]這個匹配條件——只有狀態(tài)是 S送簽中、1已核準、W抽單、R退回時才允許查詢狀態(tài)為 0開立時直接返回。這是因為單據(jù)還沒送簽時查 Easyflow 沒有意義。抄這段代碼時最容易漏掉的是第一段 aza23 的判斷這是判斷單據(jù)別是否已設定 Easyflow 簽核的不判斷的話未設定簽核的單據(jù)也會發(fā)起查詢白白增加一次無效的 SOAP 調用。5. Easyflow 端配置表單出不來、審批流不走的常見問題排查5.1 表單目錄改名后Init 文件里的舊單號沒替換干凈Easyflow 端的新表單通常不是從零設計而是復制一個已有的 Tiptop 表單目錄再全局替換單號。存放位置在Program Files\EF2Kweb\ASP\CHT\Forms比如把 TT_SO1 整個目錄復制為 TT_WO1然后改目錄名、改目錄下所有文件名。這一步做完真正的坑在文件內容TT_WO1_Approve_Init.ASP、TT_WO1_Create_Init.ASP、TT_WO1_Display_Init.ASP 以及 Grid.ASP 這四個文件里的所有 “TT_SO1” 字符串都要替換成 “TT_WO1”。現(xiàn)象替換漏了之后表單能打開但數(shù)據(jù)不顯示或顯示的還是舊表單的欄位結構。原因Init 文件里寫死了舊單號的 XML 解析邏輯新表單的數(shù)據(jù)進來后按舊規(guī)則解析自然對不上。解決替換時不要只用編輯器的“全部替換”一次了事替換完后再全局搜一遍 “SO1” 確認沒有殘留。這類問題排查時往往要花不少時間因為報錯不一定明顯可能只是某個字段顯示為空。5.2 控件 ID 命名規(guī)則xxx_1 和 xxx_2 弄反導致數(shù)據(jù)填充為空Forms.ASP 是電子表單的外觀文件通常用網(wǎng)頁編輯工具調整布局。這里最容易踩的坑是控件 ID 命名每個欄位有兩組 ID標簽的命名規(guī)則是 xxx_1如 sfb01_1控件本身的命名規(guī)則是 xxx_2如 sfb01_2。Easyflow 系統(tǒng)會自動按照欄位名從 XML 中取數(shù)據(jù)解析 ID 后填充到對應位置。命名規(guī)則錯了表單上就看不到數(shù)據(jù)。ID 類型命名規(guī)則示例作用標簽欄位名_1sfb01_1顯示名稱控件欄位名_2sfb01_2承載數(shù)據(jù)值實際項目的血淚經(jīng)驗是調布局時順手改了控件的 ID或者復制粘貼后忘改后綴結果表單打開一片空白。檢查手段也很簡單——用瀏覽器開發(fā)者工具看控件 ID或者直接看 Forms.ASP 源碼里 id 屬性是否與 ColumnSet.xml 里的欄位名對應。這里還有一個容易混淆的點一般多行文本框和選擇框兩種控件足夠用了日期用選擇框其他都用文本框不要為了美觀引入特殊控件否則解析邏輯要跟著改得不償失。單身表格是 OCX 嵌入的不需要在 Forms.ASP 里特別設置但注意不要把 OCX 的 ID 也按 xxx_2 規(guī)則去改它有自己的命名約定。5.3 表單性質里“顯示否”和生效日沒設置表單死活不顯示表單文件配好、ColumnSet.xml 也填了但 Easyflow 左側清單里就是看不到新表單。這個問題的根因通常不在文件而在表單性質維護。進入“管理程序清單 → 流程基本數(shù)據(jù) → 表單性質維護操作”找到對應表單如果界面上各項目沒設置正確表單不會出現(xiàn)在清單里。兩個重點一是“顯示否”的設置如果這個項目被置為否表單直接隱藏二是生效日和失效日失效日如果被誤填了過去的日期表單也會消失。表單如果永久生效忽略失效日即可但生效日不能為空。這個界面跟 Tiptop 的單據(jù)性質設置是兩回事Tiptop 那邊決定了“要不要拋”這里決定了“拋過來后能不能顯示”兩者都要配漏一個就斷一條鏈路。5.4 沒建權限文件能看到清單卻打不開表單表單出現(xiàn)在清單里但點進去提示無權限這是另一個獨立問題。表單性質維護頁面滾動到最下面有一個“新建權限文件”的入口必須為新表單設置權限屬性否則就算表單已生效用戶也無法打開。這個問題的迷惑性在于表單清單能顯示容易讓人誤以為配置已經(jīng)完成結果點開才發(fā)現(xiàn)權限沒配。處理方式很簡單在權限文件里把需要訪問該表單的角色或用戶加上即可。實際項目里經(jīng)常是只給管理員配了權限簽核人比如審批流程里的 439 用戶沒加導致測試時管理員能打開、實際簽核人打不開來回扯皮半天才發(fā)現(xiàn)是權限文件漏了人。5.5 忘拋 xxxuser 欄位與表單關聯(lián)缺失流程起不來的兩個隱蔽原因最后一類高頻問題是單據(jù)成功進入 Easyflow也顯示在收件箱里了但發(fā)起流程時報錯或者流程根本不會按預期流轉。這里有兩個隱蔽原因值得單獨列出來。第一個原因是 XML 里沒拋 xxxuser 欄位。這個欄位不顯示在表單上但 Easyflow 要拿它作為填單人解析流程的依據(jù)。沒有它系統(tǒng)不知道這張單據(jù)是誰填的流程就起不來。檢查方法看 Tiptop 拋轉作業(yè)生成的 XML 字符串里是否包含以 user 結尾的欄位節(jié)點。第二個原因是表單關聯(lián)沒建。在“電子表單模塊 → 管理程序清單 → 自動向導 → 易拓集成向導”里點擊“新增表單關聯(lián)”選擇 tiptop 程序代號、工廠代號再選擇對應的 Easyflow 電子表單代號。完成關聯(lián)后Tiptop 拋轉過來的單據(jù)才能準確落到對應的電子表單上。如果這步?jīng)]做即使前面全部配置正確單據(jù)也到不了簽核人手里。做關聯(lián)時有個便利點tiptop 程序代號是系統(tǒng)自動列出的所有有拋轉機制的作業(yè)都會出現(xiàn)工廠代號選擇后下方會列出該作業(yè)中已勾選“是否簽核”的單據(jù)類別——如果這里列表是空的回頭檢查 3.3 小節(jié)里說的單據(jù)性質設置。6. 快速定位集成測試失敗時按這張順序表排查集成測試階段我習慣把問題分成“Tiptop 沒拋出去”“拋了但 Easyflow 沒收到”“收到了但顯示不對”“簽核后回寫失敗”四類每類對應不同的排查入口。下面這張表是我在實際項目中沉淀下來的排查順序按順序走一遍大多數(shù)問題能在十分鐘內定位到具體環(huán)節(jié)。癥狀第一排查點第二排查點第三排查點審核后狀態(tài)不變無拋轉提示Appserver 是否啟動單據(jù)別是否勾選簽核數(shù)據(jù)表 7 欄位是否齊全提示拋轉成功但 OA 收件箱空服務端集成包與 WSDL 可訪問性易拓集成向導表單關聯(lián)表單性質和權限文件表單收到但數(shù)據(jù)為空控件 ID 命名 xxx_1 / xxx_2ColumnSet.xml 節(jié)點名拋轉 XML 是否含該節(jié)點簽核后 Tiptop 狀態(tài)不變簽核狀態(tài)欄位名是否一致回寫服務是否登記XML 中 xxxuser 是否拋出驗證拋轉是否真的發(fā)生最快的辦法是在 Tiptop 端看 aws 拋轉作業(yè)的運行日志確認 XML 字符串已經(jīng)組出來然后在 Easyflow 端查收件箱、查流程實例。把兩端日志時間對上就能判斷是 Tiptop 沒發(fā)出去還是 Easyflow 沒收到。審核后立刻查簽核狀態(tài)欄位的值——變成 S 說明已經(jīng)發(fā)給 Easyflow 了還是 0 說明拋轉邏輯根本沒執(zhí)行。從那以后我每次接手新的 Tiptop 與 Easyflow 集成單都會強制走一遍這套排查先 curl 一下 WSDL 地址確認網(wǎng)關活著再確認 Appserver 進程在跑然后查數(shù)據(jù)表欄位、查單據(jù)性質勾選、查表單關聯(lián)最后才打開編輯器改代碼。這個順序幫我省掉了大量“查了半天發(fā)現(xiàn)是環(huán)境問題”的時間。希望這篇筆記也能幫你少走幾步彎路。本文還有配套的精品資源點擊獲取