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