기타 문제 식별

이 섹션에서는 앞의 카테고리에 해당되지 않는 영역과 관련된 일반적인 문제들과 가능한 원인에 대해 설명합니다. 일반적인 문제의 목록이 다음에 나와 있습니다. 링크를 사용하여 해결하려는 문제에 대한 정보로 직접 이동할 수 있습니다. 해결하려는 문제가 목록에 없거나, 제안된 조치를 수행해도 문제가 해결되지 않으면 시스템 관리자에게 문의하십시오.

• 프로세스 아카이브를 시작할 때 Tibco BusinessWorks Designer에서 "Cannot create Transport" 및 "Process Definition Load" 오류를 발생시킴

• 다음 SAP 메시지 중 하나가 Windchill 엔터프라이즈 시스템 트랜잭션 로그에 나타납니다.

• Windchill ESI에서 어댑터 시간 초과 메시지를 반환함

• Windchill PDMLink가 EMS 대기열에 가입할 수 없음

• PostResult에 오류가 표시됨

• 게시된 객체에 배포 대상이 지정되지 않음 오류 메시지가 표시됨

• 마지막 게시 후 변경 사항이 없음 오류 메시지가 표시됨

• TIBCO BusinessWorks EMS, Windchill 또는 둘 모두에 연결할 수 없음

• TIBCO 어댑터가 ESI 트랜잭션에 대해 시간 초과됨

• ESI 응답 메타 정보 파일 관련 오류 메시지가 표시됨

• 어댑터에서 JMS 전송을 시작할 수 없음

• 어댑터가 시작되지 못하고 관리자에서 "시작 중" 상황으로 머물러 있음

• Coyote 커넥터가 시작되지 않음

• 엔터프라이즈 트랜잭션 로그에서 게시가 "보류" 상태로 유지됨

• JAX-M Parser 또는 XML Parser가 ResultResponse XML 스키마를 사용하여 메시지 구문 분석을 하지 못함

• 엔터프라이즈 트랜잭션 로그에 "입력 데이터가 부적절합니다."라는 메시지가 나타남

• 엔터프라이즈 트랜잭션 로그에서 트랜잭션이 "보류" 상태에 머물러 있음

• EMS 서버를 수동으로 시작한 후 모든 EMS 서버 구성이 사라짐

• TIBCO Adapter for an SAP 인스턴스가 작동하지 않고 오류 상황이 표시됨

• 수준 올리기 요청을 통해 비즈니스 객체 세트의 수준을 올리면 이러한 각 객체에 대해 RTM 워크플로가 작성됨

• 비즈니스 객체 하나 이상의 수준을 올릴 때 생성되는 ESI 응답 파일에 해당 ID를 제외하고 수준 올리기 요청에 대한 어떠한 정보도 포함되지 않음

프로세스 아카이브를 시작할 때 Tibco BusinessWorks Designer에서 "Cannot create Transport" 및 "Process Definition Load" 오류를 발생시킴

경로에 추가 폴더가 있을 수 있습니다. 문자열을 대체할 때 이러한 엔트리를 유지하십시오.

• 상호 참조 조회 파일에 잘못된 값이 있는 경우

• Windchill에서 기본 단위가 잘못되었거나 누락된 경우

• 필요한 ISO 코드 대신에 SAP 기본 측정 단위 코드를 사용한 경우

• 어댑터 구성이 잘못된 경우

• ESITarget이 잘못된 경우

• 어댑터 인스턴스가 실행되지 않는 경우

• SAP 응용 프로그램 서버를 사용할 수 없는 경우

• 어댑터와 SAP 간에 사용할 수 있는 연결이 충분하지 않은 경우

• 메시지 수신량이 이를 처리하는 어댑터 용량을 초과하는 경우

• Windchill ESI 서비스가 제대로 설치되지 않은 경우

• EMS 서버가 기능을 발휘하지 못하는 경우

• Windchill 메소드 서버와 EMS 서버 간에 네트워크 오류가 발생한 경우

• Windchill 어댑터 EMS 구성이 잘못된 경우

• Windchill ESI 기본 설정에서 하나 이상의 EMS 대기열 이름, EMS 대기열 사용자 또는 EMS 대기열 암호를 잘못 지정한 경우

• 게시 중인 데이터에 데이터 문제가 존재하는 경우

• 하나 이상의 필수 TIBCO 컴포넌트가 오프라인 상태인 경우

• Windchill ESI Services가 JMS 대기열에 대해 읽기 또는 쓰기를 수행할 수 없는 경우(이 문제의 원인은 Windchill PDMLink가 EMS 대기열에 가입할 수 없음 오류와 동일)

• Windchill PDMLink에서 데이터베이스 오류가 발생한 경우

• Windchill ESI 미들웨어의 프로그래밍 오류로 인해 PostResult RPC 요청의 형식이 잘못된 경우

• 배포 대상을 지정하기 전에 객체 게시를 시도한 경우

• 모든 배포 대상 지정을 제거한 후 객체 게시를 시도한 경우

• Windchill ESI 기본 설정인 이터레이션 확인이 "아니요"로 설정되어 있고 게시하는 객체의 이터레이션만 변경된 경우

• 마지막 게시 이후 데이터에 변경된 내용이 없는 경우

• 해당 객체와 연관된 모든 배포 대상으로 객체를 이미 게시한 경우

• 새 배포 대상 지정을 추가한 후 이미 게시된 객체를 게시하려고 시도한 경우

• EMS 서버가 제대로 구성되지 않은 경우. EMS 서버의 이름을 "localhost"로 지정한 경우, 이 서버는 실행 중인 시스템에서만 인식되며 다른 시스템은 이 서버에 연결할 수 없습니다. EMS 서버 "localhost"에 연결하도록 설정된 응용 프로그램은 동일한 시스템에서 실행 중인 EMS 서버를 찾으려고 시도합니다. 서버를 찾을 수 없는 경우, 오류가 표시됩니다. 시스템 이름을 서버 이름으로 지정하면 다른 시스템이 EMS 서버에 연결할 수 있습니다.

• factories.conf 파일에서 QueueConnectionFactory와 연관된 URL 등록 정보를 tcp://<machinename>:7222로 설정합니다.

• ESI를 실행하는 위치에 따라 BW Engine, TIBCO Designer 또는 TIBCO Administrator에서 글로벌 변수 ESIJMS/JNDIContextURL을 = tibjmsnaming://<EMS 서버가 실행 중인 시스템 이름>:7222로 설정합니다.

이 EMS 서버가 상주하는 위치는 문제가 되지 않습니다. EMS 서버는 Windchill과 동일한 시스템, 미들웨어 엔진과 동일한 시스템 또는 다른 시스템상에 모두 위치할 수 있습니다. 위에서 설명한 값이 제대로 설정되어 있고 시스템이 동일한 네트워크에 있다면 Windchill PDMLink 및 미들웨어를 정확한 EMS 서버에 연결할 수 있습니다.

어떤 시스템과 사용자 이름이 EMS 서버와 연결되어 있는지 확인하려면 EMS 관리 도구에서 다음 명령을 입력합니다.

이 명령을 실행하면 어떤 시스템에서 어떤 사용자가 연결되어 있는지 목록을 볼 수 있습니다. 자세한 내용은 TIBCO Enterprise for EMS 설명서를 참조하십시오.

• ERP에 대한 TIBCO 어댑터의 연결이 끊어진 후 TIBCO 어댑터에서 시간 초과를 시작하는 경우 연결 상황을 확인하고 어댑터를 다시 시작합니다. 이것은 어댑터 로그에서 확인할 수 있습니다.

• TIBCO Administrator GUI, Application Management, <Application_Name>, Configuration, Process Archive.par, TIBCO BusinessWorks Process Configurations, ProcessDefinitions/DataProcessing/JMS_ESIEvent_TransactionRelease_End_PD에서 bwengine의 Max job 및 flow limit 설정을 확인합니다. 사용자 환경에서 실시한 로드 테스트를 기반으로 하는 0이 아닌 유한 숫자여야 합니다.

• ERP 연결이 끊기지 않았음에도 TIBCO 어댑터에서 시간 초과를 시작하는 경우 TIBCO Administrator GUI, Application Management, <Application_Name>, Configuration, ESISAPAdapterConfiguration.aar, Advanced, adr3.maxconnections 값을 확인합니다. 이 값이 bwengine의 max job 설정과 동일해야 합니다.

새 배포 대상 또는 배포 대상 편집 창에서 마침을 클릭하면 ESI 응답 메타 정보 파일과 관련된 오류 메시지가 표시됨

이 문제는 배포 대상 속성인 ESI 응답 메타 정보 파일 경로에 대해 지정된 값에 다음과 같은 문제가 있을 때 발생할 수 있습니다.

• 존재하지 않는 파일 경로입니다.

• 파일의 내용이 기본 스키마(기본 제공, 스키마는 ESIResponseMetaInformation.xsd 파일에서 제공)에 부합하지 않습니다.

• 파일의 내용이 잘못되었습니다. 예를 들어, 파일의 MapInformation 요소가 존재하지 않는 맵 요소를 참조합니다. 그 밖의 다양한 이유로 파일의 내용이 잘못된 것으로 간주될 수 있습니다.

• 파일의 맵 요소 한 개 이상과 연관된 ID 속성이 이전과 다른 맵 요소와 함께 이미 사용되고 있습니다. 예를 들어, 사용자가 (작성 중이거나 편집 중인) 배포 대상이 특정 ESI 응답 메타 정보 파일을 가리키게 하고 그 파일의 부품 맵 요소가 다른 글로벌 속성을 수용하도록 수정되었으나 그 ID 속성의 값은 계속 ESIPart이고 다른 배포 대상에서 기본적으로 제공된 ESI 응답 메타 정보 파일을 이미 가리킬 경우, 이러한 문제가 발생할 수 있습니다.

TIBCO Runtime Agent 5.6 및 TIBCO Runtime Agent 5.6.1을 설치한 후, Enterprise Message Service 전송을 사용하는 TIBCO 어댑터 프로젝트가 TIBCO Designer에서 시작되지 않습니다. 다음 오류 메시지가 나타납니다.

• 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: wrong ELF class: 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

• 올바른 호환성 패키지가 설치되었습니다. 그러면 종속성 문제가 해결됩니다.

• Java 환경 변수가 설정된 경우 호환되는 버전인지 확인합니다. TIBCO 응용 프로그램에서는 JRE 1.5 및 1.6도 설치합니다. 이미 구성한 Java 설정을 제거하고 TIBCO 응용 프로그램에서 해당 Java 변수를 설정하게 할 수 있습니다.

• HPUX 및 Solaris 시스템에서 Java 변수가 이미 설정된 경우 클래스 경로가 64비트 Java 라이브러리를 포함하는지 확인하십시오. SAP 어댑터는 이 플랫폼에서 64비트 응용 프로그램입니다.

• JMS 서버 tcp://<JMSServer>:7222에 연결하지 못했습니다.

JMS 서버에 접근할 수 없거나 호스트 이름에서 정확한 IP 주소를 확인하지 못했기 때문일 수 있습니다. 잘못된 버전의 tibjms.jar 파일 때문에 이 문제가 발생할 수도 있습니다. 이 문제를 해결하려면 Windchill 서버의 tibjms.jar 파일에서 TIBCO 서버의 정확한 JMS 버전을 사용하고 있는지 확인합니다.

2. Windchill 메소드 서버 로그에 나타난 문자열을 정확하게 사용하여 <JMSServer>를 Ping합니다.

4. Ping 요청이 성공할 경우 표시된 IP 주소를 사용하거나 <JMSServer_IP> <JMSServer> 엔트리를 %Windir%\System32\drivers\etc\hosts 파일에 추가합니다.

• DataResponse 대기열에 연결하지 못했습니다.

이것이 원인인지 확인하기 위해 JMS 서버에 연결하고 DataResponse 대기열이 작성되었는지 그리고 WCESI 사용자에게 DataResponse 대기열에 대한 보내기 권한이 부여되었는지 확인합니다. DataResponse 대기열 이름 앞에 별표(*)가 있을 경우 그 대기열은 임시적이므로 작성해야 합니다. 이 문제는 EAR을 수동으로 배포한 경우 발생할 수 있습니다. 이 문제를 해결하려면 JMS 관리 창에서 다음 명령을 실행합니다.

• Process Archive가 동일한 DataResponse 대기열에 연결되지 않았습니다.

JMS 관리 창을 열어 Process Archive가 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로 이동하여 확인합니다.

• Windchill 및 Process Archives가 동일한 JMS 대기열에 연결되어 있습니다. EMS Administration Tool > Show queues로 이동하여 확인합니다.

• com.ptc.windchill.esi.Result 대기열에 수신자가 하나밖에 없습니다. EMS Administration Tool > Show queues로 이동하여 확인합니다.

• 대기열에 남아 있는 메시지가 있습니다. EMS Administration Tool > Show queues로 이동하여 확인합니다.

• 배포 대상을 만드는 동안 클라이언트 및 시스템 ID 속성에 대해 지정된 값이 해당 SAP 인스턴스에 대해 MICU를 실행할 때 지정된 값과 일치하지 않습니다. 그러면 Windchill ESI 서비스가 존재하지 않는 EMS 대기열에 ESI 응답 메시지를 배치하게 되어 ESI 트랜잭션이 보류 상태로 남게 됩니다.

JAX-M Parser 또는 XML Parser가 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 서비스에서 EMS 서버의 DataResponse 대기열에 ESIResponse를 쓰지 못했습니다. 이를 확인하려면 Info*Engine 관리 > 등록 정보 편집기 > 핵심 JMS 등록 정보로 이동하고 JMS BASE URI가 정확한지 확인합니다. 그런 다음 메소드 서버 로그를 참조하여 DataResponse 대기열에 가입했는지 확인합니다.

• JMS 서버 tcp://<JMSServer>:7222에 연결하지 못했습니다. 이 문제를 해결하려면 Windchill 서버의 tibjms.jar 파일이 TIBCO 서버의 정확한 JMS 버전에서 가져온 것인지 확인합니다.

• JMSServer에 접근할 수 없거나 호스트 이름에서 정확한 IP 주소를 확인하지 못했기 때문일 수 있습니다. 잘못된 버전의 tibjms.jar 파일 때문일 수 있습니다. 이를 확인하려면

2. Windchill 메소드 서버 로그에 나타난 문자열을 정확하게 사용하여 <JMSServer>를 Ping합니다.

4. Ping 요청이 성공할 경우 표시된 IP 주소를 사용하거나 <JMSServer_IP> <JMSServer> 엔트리를 %Windir%\System32\drivers\etc\hosts 파일에 추가합니다.

• DataResponse 대기열에 연결하지 못했습니다.

• Process Archive가 동일한 DataResponse 대기열에 연결되지 않았습니다.

JMS 관리 창을 열어 Process Archive가 DataResponse 대기열에 가입했는지 확인합니다. 수동 배포 시 이 단계가 생략될 때가 종종 있으며, 이 경우 오류가 발생합니다. DataResponse 대기열에 가입된 경우 TIBCO Administrator > Application Management > Application Name > Configuration > Deployment Name > Advanced > ESIJMS/DataResponseQueue로 이동하여 DataResponseQueue를 확인합니다.

EMS 서버를 시작하는 명령이 버전 5.1.4에서 변경되었습니다. EMS 버전 4.x에서 시작 명령은 "./tibemsd"였습니다. EMS 버전 5.1.4에서는 ./tibemsd64 -config ../tibco/cfgmgmt/ems/data/tibemsd.conf입니다. 이 명령은 상대 경로를 사용하며 "<TIBCO_HOME>\ems\5.1\bin"에서 실행되어야 합니다.

이 문제는 어댑터 스택 오버플로 오류 때문에 발생합니다. TIBCO 지원 팀에서 이 문제를 확인했으며, adr3.stacksize 매개변수를 적절한 값으로 늘려 이 문제를 해결할 것을 권장합니다. 이 방법은 524288(512KB)에서 성공적으로 테스트되었습니다.

adr3.stacksize 값을 늘리려면 TIBCO Administrator GUI > Application Management > <ApplicationName> Configuration > ESISAPAdapterConfiguration.aar > Advanced로 이동합니다.

수준 올리기 요청을 통해 비즈니스 객체 세트의 수준을 올리면 이러한 각 객체에 대해 RTM 워크플로가 작성됨

수준 올리기 요청 게시 기본 설정의 값이 아니요이면 이렇게 될 수 있습니다. 수준 올리기 요청의 객체가 단일 RTM 워크플로를 통해 게시되게 하려면 이 기본 설정을 예로 설정하십시오.

비즈니스 객체 하나 이상의 수준을 올릴 때 생성되는 ESI 응답 파일에 해당 ID를 제외하고 수준 올리기 요청에 대한 어떠한 정보도 포함되지 않음

이는 정상적인 동작입니다. 별도의 XML 요소에서 ESI 응답을 사용하여 수준 올리기 요청에 대한 다른 속성을 보내려면 ESI 응답 메타 정보 파일을 적절히 구성해야 합니다.