識別其他問題
本節將描述不符合先前分類之範疇相關的常見問題和可能的原因。下列所示為一系列常見問題的清單。您可以使用這些連結,直接找到您所經歷問題的資訊。如果在清單中找不到您所經歷的問題,或者其建議的動作無法完全解決問題,請聯絡系統管理員。
Tibco BusinessWorks Designer 會於啟動流程封存時拋出「Cannot create Transport」與「Process Definition Load」錯誤
欲配置 BusinessWorks,請遵循下列步驟:
1. 備份下列檔案:
<<TibcoHome>>/designer/<<version>>/bin/designer.tra
2. 在文字編輯器中,開啟下列檔案:
<<TibcoHome>>/designer/<<version>>/bin/designer.tra
3. 搜尋下列字串:
tibco.env.CUSTOM_CP_EXT
4. 以下列內容取代該字串:
tibco.env.CUSTOM_CP_EXT %RV_HOME%/lib/tibrvj.jar:%RV_HOME%/lib:%RV_HOME%/lib/64:
|
路徑上可能有其他資料夾。取代字串時請保留這些項目。
|
5. 搜尋下列字串:
tibco.env.CUSTOM_LIB_PATH
6. 以下列內容取代該字串:
tibco.env.CUSTOM_LIB_PATH %RV_HOME%/lib:%RV_HOME%/lib/64:
|
路徑上可能有其他資料夾。取代字串時請保留這些項目。
|
7. 儲存並關閉 designer.tra
8. 開啟 TIBCO Designer 並啟動流程封存。
下列其中一條 SAP 訊息顯示在「Windchill Enterprise Systems 交易記錄檔」中:
“No unit of measure found in ISO code __ in field BASE_UOM_ISO”
或
“The field MARA-MEINS/BAPI_MARA-BASE_UOM(_ISO) is defined as a required field; it does not contain an entry”
下列原因可能會導致此問題:
• 交叉參照的查詢檔案不具備正確值
• Windchill 中的預設量測單位遺失或無效
• 使用 SAP 中的原生量測單位代碼,而不是所需的 ISO 代碼
Windchill ESI 傳回轉接器逾時的訊息
• 轉接器組態錯誤
• ESITarget 無效
• 轉接器實例未執行
• 無法使用 SAP 應用程式伺服器
• 在轉接器與 SAP 之間的連線不足
• 訊息的輸入流超出可處理它們的轉接器容量。
|
解決此問題可能需要 Windchill ESI 管理員的協助。
|
Windchill PDMLink 無法訂閱 EMS 佇列
下列原因可能會導致此問題:
• Windchill ESI 服務未正確安裝
• EMS 伺服器未正常運作
• Windchill 應用伺服器和 EMS 伺服器之間發生網路錯誤
• Windchill 轉接器 EMS 組態不正確
• Windchill ESI 的偏好設定指定了一個或多個錯誤的 EMS 佇列名稱、EMS 佇列使用者,或者 EMS 佇列密碼
|
解決此問題可能需要 Windchill ESI 管理員的協助。
|
PostResult 上出現錯誤
下列原因可能會導致此問題:
• 資料的問題是存在於正在發行的資料中
• 一或多個所需的 TIBCO 元件已離線
• Windchill ESI 服務不能讀取或寫入 JMS 佇列 (這與 #ESISAPTroubleOther/WCPDMLinkCannotSubscribeEMSQueue 有相同的原因)。
• Windchill PDMLink 發生資料庫錯誤
• 由於 Windchill ESI 中介軟體中的程式設計錯誤,PostResult RPC 要求並未正確地格式化
|
解決此問題可能需要 Windchill ESI 管理員的協助。
|
不存在已發行物件的發佈目標工作分派
下列原因可能會導致此問題:
• 您嘗試在指派任何發佈目標之前發行物件。
• 您嘗試在移除所有發佈目標的指派之後發行物件。
自上次發行過後未發生變更
下列原因可能會導致此問題:
• 將 Windchill ESI 的「檢查版序」偏好設定設為「否」,且只有正發行之物件的版序已變更。
• 自從上次發行過資料之後,該資料就一直沒有變更
• 您早已順利地將物件發行至與該物件相關聯的所有發佈目標
• 在將新發佈目標工作分派新增至已發行的物件之後,嘗試再次發行該物件。
無法連接到 TIBCO BusinessWorks EMS、Windchill,或兩者都連接失敗
下列原因可能會導致此問題:
• EMS 伺服器配置錯誤。如果指定 EMS 伺服器的名稱為 "localhost",則只有在其執行的電腦上才會辨識出該伺服器。其他機器都無法連接到該伺服器。設定為連接到 EMS 伺服器 "localhost" 的應用程式,會嘗試尋找在同一部電腦上執行的 EMS 伺服器。如果找不到伺服器,就會出現錯誤。如果指定電腦名稱作為伺服器名稱,則其他電腦就能連接到 EMS 伺服器。
要解決這個問題:
• 將 factories.conf 檔案中與 QueueConnectionFactory 關聯的 url 屬性設定為 tcp://<machinename>:7222
其中 <machine name> 就是執行 EMS 伺服器的電腦。
• 將全域變數 ESIJMS/JNDIContextURL (位於 BW Engine、TIBCO Designer 或 TIBCO Administrator 中,視您執行 ESI 的位置而定) 設定為 = tibjmsnaming://<EMS 伺服器執行的電腦名稱>:7222。
|
此 EMS 伺服器所在的位置並不重要。它可位於與 Windchill 相同的電腦上、與中介軟體引擎相同的電腦上,或者與這些都不相同的電腦上。如果正確設定上述值 (而且電腦是在同一個網路上),Windchill PDMLink 與中介軟體就能連接至正確的 EMS 伺服器。
|
欲決定連接到 EMS 伺服器的是哪一部電腦和哪一個使用者名稱,請在 EMS 管理工具中輸入下列命令:
>show connections
此命令將會提供您有哪些使用者已連接和從哪部電腦連接的一份清單。如需詳細資訊,請參閱 TIBCO Enterprise for EMS 的文件。
針對 ESI 交易,TIBCO 轉接器逾時
• 如果在 TIBCO 轉接器與 ERP 的連接中斷之後,TIBCO 轉接器開始逾時,請檢查連接狀況並重新啟動轉接器。可以藉由查看轉接器記錄檔來確認此情況。
• 在 TIBCO Administrator GUI,應用程式管理,<Application_Name>,組態,Process Archive.par,TIBCO BusinessWorks 流程組態,ProcessDefinitions/DataProcessing/JMS_ESIEvent_TransactionRelease_End_PD 中檢查 bwengine 的工作與流程上限設定。此設定應該是一個有限非零數字,且以在使用者環境下進行的載入測試為基礎
• 如果即使 TIBCO Adapters 與 ERP 的連接未中斷,它們也開始逾時,請檢查 TIBCO Administrator GUI,應用程式管理,<Application_Name>,組態,ESISAPAdapterConfiguration.aar,進階,adr3.maxconnections 值。此值應等於 bwengine 的工作上限設定
顯示 ESI 回應中繼資訊檔案相關錯誤訊息
從「新發佈目標」或「編輯發佈目標」視窗中按一下「完成」時,與 ESI 回應中繼資訊檔案相關的錯誤訊息會顯示出來
這可能由以下任何一個問題所導致,並會顯示針對發佈目標屬性「ESI 回應中繼資訊檔案路徑」指定的值:
• 檔案的路徑不存在。
• 檔案的內容與基礎結構描述不符 (結構描述預設由 ESIResponseMetaInformation.xsd 檔案提供)。
• 檔案的內容無效 - 例如,檔案中的 MapInformation 元素參考了不存在的 Map 元素。其他一些原因也可能導致檔案內容被視為無效。
• 與檔案中至少一個 Map 元素相關聯的 ID 屬性已用於與前者不同的 Map 元素。例如,如果使用者將 (建立或編輯的) 發佈目標指向某個 ESI 回應中繼資訊檔案,且已修改其零件的 Map 元素以包含其他全域屬性,但其 ID 屬性繼續擁有 ESIPart 值,而已將不同的發佈目標指向預設提供的 ESI 回應中繼資訊檔案,則會發生這種情況。
轉接器無法以 JMS 輸送啟動
安裝 TIBCO Runtime Agent 5.6 與 TIBCO Runtime Agent 5.6.1 之後,使用 Enterprise Message Service 作為其傳輸工具的 TIBCO Adapter 專案不從 TIBCO Designer 啟動。會出現以下錯誤訊息:
Code = AESDKC-0156,Category = JmsComm, Severity = errorRole, Description = could not open JMS shared library jms.
要解決這個問題:
• 在 Windows 上:先進行備份,然後從 <TIBCO_HOME>/adapters/sdk/version/<lib> 中移除 libeay32.dll 與 ssleay32.dll
• 在 UNIX 上:先進行備份,然後從 TIBCO_HOME/adapters/sdk/version/lib 目錄中移除 libssl 與 libcrypto openssl 物件庫
轉接器無法啟動,狀況在管理員中保持為「正在啟動中」
如果流程 ID "-1" 分配至轉接器流程,則說明在啟動轉接器時發生錯誤。此錯誤通常取決於物件庫。
以下為已知錯誤:
• 載入共用物件庫時發生錯誤:librfccm.so: 錯誤的 ELF 類別: ELFCLASS64
如果您使用 64 位元 SAPJCo 物件庫,可能會發生此錯誤。在某些平台上,例如 Windows X64 與 Linux ia64,SAP 轉接器是 32 位元應用程式。使用 32 位元物件庫將會解決此問題
• 載入共用物件庫時發生錯誤:librfccm.so: wrong ELF class: ELFCLASS32
如果您使用 32 位元 SAPJCo 物件庫,可能會發生此錯誤。在某些平台上,例如 HPUX IA64 與 Solaris SPARC,SAP 轉接器是 64 位元應用程式。使用 64 位元物件庫將會解決此問題
下列物件庫中已發現類似問題:
• libresolv.so.2 sunw_2.2.2
• libstdc++-libc6.2-2.so.3
• libstdc++.so.5
請核對以下事項:
• 已安裝正確的相容性封裝。如此將可解決相依性問題。
• 如果已設定 Java 環境變數,請確保各版本相容。TIBCO 應用程式還會安裝 JRE 1.5 與 1.6。您可以移除已配置的任何 Java 設定,並允許 TIBCO 應用程式設定適當的 Java 變數。
• 在 HPUX 與 Solaris 電腦上,由於 SAP 轉接器在這些平台上是 64 位元應用程式,因此如果已設定 Java 變數,請確保類別路徑包含 64 位元 Java 物件庫。
Coyote 連接器未啟動
請核對 ESIOthers/WSHost 與 ESIOthers/WSPort 變數。
在「企業交易記錄檔」中,發行仍保持在「待處理」狀態下
此問題可能由以下其中一個原因造成:
• 連接至 JMS 伺服器 tcp://<JMSServer>:7222 失敗
如果無法連接至 JMS 伺服器,或無法將主機名稱解析至正確的 IP 位址,便可能發生這種情況。錯誤版本的 tibjms.jar 檔案也可能導致發生此問題。欲解決此問題,請確定 Windchill 伺服器中的 tibjms.jar 檔案正在 TIBCO 伺服器上使用正確版本的 JMS。
1. 從 Windchill 伺服器開啟指令視窗。
2. 使用與 Windchill 應用伺服器記錄檔中顯示的字串完全相同的字串來 Ping <JMSServer>。
3. 如果 ping 請求失敗,則執行 ping <JMSServer_IP>。
4. 如果 ping 請求成功,則使用所顯示的 IP 位址,或將下列項目新增至 %Windir%\System32\drivers\etc\hosts 檔案:<JMSServer_IP> <JMSServer>
5. 如果 ping 請求仍然失敗,請與網路管理員聯絡。
• 連接 DataResponse 佇列失敗。
欲核對這是否為導致發生此問題的原因,請連接至 JMS 伺服器並檢查是否已建立 DataResponse 佇列,以及是否已授與 WCESI 使用者在 DataResponse 佇列上傳送的權限。如果在 DataResponse 佇列名稱前面顯示一個星號 (*),則表示此佇列是暫時的,且需要建立。當已手動部署 EAR 時,可能會發生此問題。欲解決此問題,請在「JMS 管理」視窗中執行下列指令:
1. Create queue <DataResponse>
2. Setprop queue <DataResponse> secure
3. Grant queue <DataResponse> <EAIUser> receive
4. Grant queue <DataResponse> <WCESIUser> send
5. Setprop factory QueueConnectionFactory url=tcp://<JMSServer>:7222
6. Commit
• 「流程封存」並未連接至相同的 DataResponse 佇列。
開啟「JMS 管理」視窗以確認 DataResponse 佇列已由「流程封存」訂閱。手動部署時,常會遺漏此步驟,而導致發生錯誤。若尚未訂閱 DataResponse 佇列,則請導覽至 TIBCO Administrator > Application Management > Application Name > Configuration > Deployment Name > Advanced > ESIJMS/DataResponseQueue 來核對 DataResponseQueue 中的值
• 只有一個 WCESI 使用者連接至 EMS 伺服器。請導覽至 EMS Administration Tool > Show connections 來進行核對。
• 具有 ClientID (BW-ESIMaster_JMSConnection-queue-<Application Name>-Process_Archive) 的 ESISYS 連接數應與配置的 ERP 實例數相等。若不相等,執行流程封存的其他實例便可能會消耗「ESI 回應」訊息。請導覽至 EMS Administration Tool > Show connections 來核對 ESISYS 連接數。
• 核對是否所有連接都來自目前這一測試組中的 TIBCO 或 Windchill 伺服器,且沒有連接來自前一組或外部電腦。若不相等,執行流程封存的其他實例便可能會消耗「ESI 回應」訊息。請導覽至 EMS Administration Tool > Show connections 來核對 ESISYS 連接數。請導覽至 EMS Administration Tool > Show connections 來進行核對。
• 「流程封存」並未連接至相同的 DataResponse 佇列。請導覽至 EMS Administration Tool > Show queues 來進行核對。
• com.ptc.windchill.esi.Result 佇列只有一個接收器。請導覽至 EMS Administration Tool > Show queues 來進行核對。
• 佇列中仍然存在訊息。請導覽至 EMS Administration Tool > Show queues 來進行核對。
• 建立發佈目標時為「用戶端」與「系統 ID」屬性指定的值,與執行 MICU 時為特定 SAP 實例指定的對應值不符。這會導致 Windchill ESI 服務將 ESI 回應訊息置於不存在的 EMS 佇列上,進而導致 ESI 交易保持在待處理狀態下。
JAX-M 剖析器或 XML 剖析器無法使用 ResultResponse XML 結構描述剖析訊息
顯示以下錯誤訊息:
2,,2,2,1,20021,Windchill sent an invalid ResultResponse message. JAX-M Parser or XML Parser failed to parse message using ResultResponse XML schema. See Windchill logs for details,,,,,Job-1 Error in [ProcessDefinitions/Services/WCResult_Service.process/RepeatUntilTrue_SendAllResults/RepeatOnError_Result_ResultResponse/Java_ParseESIResultResponse]While executing [invoke] encountered [com.ptc.windchill.esi.ext.ESISoapException]: [Unable to create envelope from given source: at com.ptc.windchill.esi.ext.SoapResponseFinder.getResult(SoapResponseFinder.java:216)]
JRE 6 隨附的 Java 物件庫中存在此問題。JRE 1.5 與 JRE 1.6.0.18 中尚未發現此問題。
「企業交易記錄檔」中顯示「輸入資料無效」訊息
此錯誤指示在「呼叫轉接器請求回應服務」活動中的結構描述驗證失敗。詳細的描述與堆疊追蹤皆會記錄到 processArchive 記錄檔中。這些記錄檔將指示結構描述不相符的確切原因。例如:
validation error: data "xs:string('Hinge, Right Hand, Male, Removable, 0.187 Dia Pin, SS')" length must be at most xs:int('40') CHARACTERs ({com.tibco.xml.validation}SIMPLE_E_LENGTH_TOO_LONG) at /aeRequestInputType[1]/{http://www.tibco.com/xmlns/ae2xsd/2002/05/ae/700/basic/functionModules}__caret_request_caret_BAPI__MATERIAL__SAVEREPLICA_caret_BAPI__MATERIAL__SAVEREPLICA[1]/MATERIALDESCRIPTION[1]/item[2]/MATL__DESC[1]com.tibco.xml.validation.exception.k: data "xs:string('Hinge, Right Hand, Male, Removable, 0.187 Dia Pin, SS')" length must be at most xs:int('40') CHARACTERs
在「企業交易記錄檔」中,交易仍保持在「待處理」狀態下
此問題可能由以下其中一個原因造成:
• ESI 服務無法將 ESIResponse 寫入至 EMS 伺服器的 DataResponse 佇列中。欲核對此情況,請導覽至「Info*Engine 管理」 >「屬性編輯器」>「核心 JMS 屬性」,然後確認「JMS 基礎 URI」的正確性。然後參閱應用伺服器記錄檔,確認已成功訂閱 DataResponse 佇列。
• 無法連接至 JMS 伺服器 tcp://<JMSServer>:7222。欲解決此問題,請確保已從 TIBCO 伺服器上正確版本的 JMS 中提取來自 Windchill 伺服器的 tibjms.jar 檔案。
• 無法連接至 JMS 伺服器,或無法將主機名稱解析至正確的 IP 位址。此問題可能是由於 tibjms.jar 檔案的版本錯誤所導致。欲核對此情況:
1. 從 Windchill 伺服器開啟指令視窗。
2. 使用與 Windchill 應用伺服器記錄檔中顯示的字串完全相同的字串來 Ping <JMSServer>。
3. 如果 ping 請求失敗,則執行 ping <JMSServer_IP>。
4. 如果 ping 請求成功,則使用所顯示的 IP 位址,或將下列項目新增至 %Windir%\System32\drivers\etc\hosts 檔案:<JMSServer_IP> <JMSServer>
5. 如果 ping 請求仍然失敗,請與網路管理員聯絡。
• 連接 DataResponse 佇列失敗。
欲核對這是否為導致發生此問題的原因,請連接至 JMS 伺服器並檢查是否已建立 DataResponse 佇列,以及是否已授與 WCESI 使用者在 DataResponse 佇列上傳送的權限。如果在 DataResponse 佇列名稱前面顯示一個星號 (*),則表示此佇列是暫時的,且需要建立。當已手動部署 EAR 時,可能會發生此問題。欲解決此問題,請在「JMS 管理」視窗中執行下列指令:
1. Create queue <DataResponse>
2. Setprop queue <DataResponse> secure
3. Grant queue <DataResponse> <EAIUser> receive
4. Grant queue <DataResponse> <WCESIUser> send
5. Setprop factory QueueConnectionFactory url=tcp://<JMSServer>:7222
6. Commit
• 「流程封存」並未連接至相同的 DataResponse 佇列。
開啟「JMS 管理」視窗以確認 DataResponse 佇列已由「流程封存」訂閱。手動部署時,常會遺漏此步驟,而導致發生錯誤。若已訂閱 DataResponse 佇列,則請導覽至 TIBCO Administrator > Application Management > Application Name > Configuration > Deployment Name > Advanced > ESIJMS/DataResponseQueue 來核對 DataResponseQueue
手動啟動 EMS 伺服器之後,所有 EMS 伺服器組態都消失不見
5.1.4 版中已變更啟動 EMS 伺服器的指令。在 EMS 4.x 版中,啟動指令為 "./tibemsd"。在 EMS 5.1.4 版中,則為 ./tibemsd64 -config ../tibco/cfgmgmt/ems/data/tibemsd.conf。指令使用相對路徑,且應從 "<TIBCO_HOME>\ems\5.1\bin" 中執行。
欲解決此問題,請停止由 "./tibemsd" 指令啟動的流程,然後使用正確指令啟動 EMS 伺服器:".
"./tibemsd64 -config ../tibco/cfgmgmt/ems/data/tibemsd.conf"
SAP 實例的 TIBCO Adapter 停止工作,且顯示「錯誤」狀況
此問題是由於轉接器堆疊溢位錯誤所致。TIBCO 支援已承認此問題為已知問題,並建議將 adr3.stacksize 參數增大到適當的值來解決此問題。已使用 524288 (512 KB) 這個值成功進行測試。
目前只有 HPUX v3 電腦存在此問題。
欲增大 adr3.stacksize,請導覽至 TIBCO Administrator GUI > Application Management > <ApplicationName> Configuration > ESISAPAdapterConfiguration.aar > Advanced。
透過推進請求推進一組企業物件會導致為這裡的每一個物件建立一個 RTM 工作流程
如果「發佈推進請求」偏好設定的值為「否」,則可能發生此情形。將偏好設定設為「是」可透過單一 RTM 工作流程發行推進請求中的物件。
在推進一或多個企業物件時產生的 ESI 回應檔案並不包含有關除其 ID 以外之推進請求的任何資訊
這是預期的行為。如果您想要以單獨 XML 元素中的 ESI 回應傳送針對推進請求的其他屬性,您需要視需要配置 ESI 回應中繼資訊檔。