Andere Probleme erkennen

Dieser Abschnitt beschreibt häufige Probleme und mögliche Ursachen für Bereiche, die nicht zu den vorhergehenden Kategorien gehören. In der nachfolgenden Aufzählung sind häufige Probleme aufgeführt. Mithilfe der Links gelangen Sie direkt zu den Informationen für das jeweils aufgetretene Problem. Wenden Sie sich an Ihren Systemadministrator, wenn das aufgetretene Problem in der Aufzählung nicht enthalten ist oder mit den empfohlenen Schritten nicht vollständig gelöst werden kann.

• Tibco BusinessWorks Designer gibt beim Starten des Prozessarchivs die Fehler "Cannot create Transport" und "Process Definition Load" zurück

• Eine der folgenden SAP Meldungen wird im Windchill Enterprise Integration Systems Transaktionsprotokoll angezeigt:

• Windchill ESI gibt eine Adapter-Timeout-Meldung zurück

• Windchill PDMLink kann eine EMS-Warteschlange nicht abonnieren

• Fehlermeldungen in PostResult

• Es wird die Fehlermeldung angezeigt, dass es keine Übergabezielzuweisung für ein publiziertes Objekt gibt

• Es wird die Fehlermeldung angezeigt, dass seit der letzten Publizierung keine Änderung vorgenommen worden ist

• TIBCO BusinessWorks oder/und Windchill können keine Verbindung zu EMS herstellen

• Bei TIBCO Adapter kommt es zu Zeitüberschreitungen bei der Verarbeitung von ESI-Transaktionen

• Es wird eine auf die ESI-Antwort-Metadatendatei bezogene Fehlermeldung angezeigt

• Adapter kann nicht mit JMS-Transport gestartet werden

• Adapter kann nicht gestartet werden; im Administrator wird weiterhin der Status "Starting Up (Starten)" angezeigt

• Coyote-Anschluss wurde nicht gestartet

• Publikation behält im Enterprise-Transaktionsprotokoll den Status "Ausstehend"

• JAX-M-Parser oder XML-Parser konnte eine Meldung nicht mit dem XML-Schema ResultResponse analysieren

• Die Meldung "Eingabedaten ungültige" wird im Enterprise-Transaktionsprotokoll angezeigt

• Transaktion behält im Enterprise-Transaktionsprotokoll den Status "Ausstehend"

• Alle EMS-Serverkonfigurationen verschwinden, nachdem der EMS-Server manuell gestartet wurde

• Der TIBCO Adapter für eine SAP-Instanz reagiert nicht mehr, und es wird ein Fehlerstatus angezeigt

• Das Erhöhen einer Gruppe von Geschäftsobjekten über einen Erhöhungsantrag bewirkt, dass für jedes dieser Objekte ein RTM-Workflow erstellt wird

• Die ESI-Antwortdatei, die nach dem Erhöhen eines oder mehrerer Geschäftsobjekte generiert wird, enthält keine Informationen zu dem Erhöhungsantrag abgesehen von seiner ID

Tibco BusinessWorks Designer gibt beim Starten des Prozessarchivs die Fehler "Cannot create Transport" und "Process Definition Load" zurück

• Querreferenz-Suchdateien enthalten nicht die richtigen Werte.

• Die Standardmaßeinheit in Windchill fehlt oder ist ungültig.

• Es werden die systemeigenen Maßeinheit-Codes von SAP statt der erforderlichen ISO-Codes verwendet.

• Adapterkonfiguration ist falsch.

• ESITarget ist ungültig.

• Adapterinstanzen werden nicht ausgeführt.

• SAP Anwendungsserver ist nicht verfügbar.

• Unzureichende verfügbare Verbindungen zwischen dem Adapter und SAP.

• Es gehen mehr Meldungen ein als der Adapter verarbeiten kann.

• Windchill ESI Dienste sind nicht korrekt installiert.

• EMS-Server funktioniert nicht.

• Netzwerkfehler zwischen Windchill Methodenserver und EMS-Server.

• Windchill Adapter EMS-Konfiguration ist nicht korrekt.

• Windchill ESI Einstellungen geben einen oder mehrere EMS-Warteschlangennamen, EMS-Warteschlangenbenutzer oder EMS-Warteschlangenkennwörter falsch an.

• Datenproblem in den publizierten Daten.

• Eine oder mehrere erforderliche TIBCO-Komponenten sind offline.

• Windchill ESI Dienste können nicht aus einer JMS-Warteschlange lesen oder in diese schreiben (gleiche Ursachen wie bei Windchill PDMLink kann eine EMS-Warteschlange nicht abonnieren).

• Datenbankfehler in Windchill PDMLink

• Die PostResult-RPC-Anfrage wurde aufgrund eines Programmierfehlers in der Windchill ESI Middleware nicht richtig formatiert.

• Sie haben versucht, ein Objekt vor der Zuweisung von Übergabezielen zu publizieren.

• Sie haben versucht, ein Objekt nach dem Entfernen aller Übergabezielzuweisungen zu publizieren.

• Die Windchill ESI Einstellung "Iteration prüfen" ist auf "Nein" eingestellt, und nur die Iteration des Objekts, das publiziert wird, hat sich geändert.

• Die Daten haben sich seit der letzten Publizierung nicht geändert.

• Sie haben das Objekt bereits erfolgreich an alle dem Objekt zugeordneten Übergabeziele publiziert.

• Es wurde versucht, ein bereits publiziertes Objekt zu publizieren, nachdem ihm neue Übergabezielzuweisungen hinzugefügt wurden.

• Der EMS-Server ist nicht korrekt konfiguriert. Wenn Sie "localhost" als Namen des EMS-Servers festlegen, wird dieser Server nur auf dem Rechner erkannt, auf dem er ausgeführt wird. Kein anderer Rechner kann eine Verbindung zu ihm herstellen. Eine für die Verbindung zum EMS-Server "localhost" eingerichtete Anwendung versucht, den auf dem gleichen Rechner ausgeführten EMS-Server zu finden. Wenn der Server nicht gefunden wird, erscheint eine Fehlermeldung. Wenn Sie einen Rechnernamen als Servernamen angeben, können andere Rechner eine Verbindung zu Ihrem EMS-Server herstellen.

• Legen Sie die QueueConnectionFactory zugeordnete URL-Eigenschaft in der Datei factories.conf auf tpc://<Rechnername>:7222 fest

• Legen Sie die globale Variable ESIJMS/JNDIContextURL (in BW Engine, TIBCO Designer oder in TIBCO Administrator, je nachdem, wo Sie ESI ausführen) fest auf = tibjmsnaming://<Rechnername, auf dem EMS-Server ausgeführt wird>:7222.

Es ist unerheblich, wo sich dieser EMS-Server befindet. Er kann sich auf dem gleichen Rechner wie Windchill, wie die Middleware-Engine oder auf einem anderen Rechner befinden. Wenn die oben beschriebenen Werte entsprechend festgelegt werden (und sich die Rechner im gleichen Netzwerk befinden), können Windchill PDMLink und die Middleware eine Verbindung zum richtigen EMS-Server herstellen.

Geben Sie in EMS Administration den folgenden Befehl ein, um festzustellen, welcher Rechner und Benutzername mit einem EMS-Server verbunden ist:

In einer Liste wird angezeigt, welche Benutzer von welchem Rechner verbunden sind. Weitere Informationen finden Sie in der Dokumentation für TIBCO Enterprise for EMS.

• Wenn bei den TIBCO Adaptern eine Zeitüberschreitung auftritt, nachdem ihre Verbindung mit dem ERP-System unterbrochen wurde, überprüfen Sie den Verbindungsstatus, und starten Sie die Adapter neu. Zeigen Sie das Adapterprotokoll an, um sich davon zu überzeugen.

• Überprüfen Sie die bwengine Einstellungen für "Max Job" und "Flow limit" in der grafischer Benutzeroberfläche von TIBCO Administrator unter "Anwendungsverwaltung, <Anwendungsname>, Konfiguration, Process Archive.par, TIBCO BusinessWorks Process Configurations, ProcessDefinitions/DataProcessing/JMS_ESIEvent_TransactionRelease_End_PD". Es sollte eine endliche Zahl ungleich 0 (Null) sein, die auf in der Benutzerumgebung ausgeführten Auslastungstests basiert.

• Wenn bei den TIBCO Adaptern auch dann eine Zeitüberschreitung auftritt, wenn ihre Verbindung zum ERP nicht unterbrochen wird, überprüfen Sie in der grafischen Benutzeroberfläche von TIBCO Administrator den Wert für adr3.maxconnections unter "Anwendungsverwaltung, <Anwendungsname>, Konfiguration, ESISAPAdapterConfiguration.aar, Erweitert". Dieser Wert sollte gleich den Einstellungen für "Max Job" von bwengine sein

Wenn Sie im Fenster "Neues Übergabeziel" oder "Übergabeziel bearbeiten" auf "Fertigstellen" klicken, wird eine Fehlermeldung angezeigt, die die ESI-Antwort-Metadatendatei betrifft

Die Ursache hierfür kann eines der folgenden Probleme mit dem für das Übergabezielattribut für ESI-Antwort-Metadatendateipfad angegebenen Wert sein:

• Die Datei ist nicht im angegebenen Dateipfad vorhanden.

• Der Inhalt der Datei entspricht nicht dem zugrunde liegenden Schema (standardmäßig wird das Schema von der Datei ESIResponseMetaInformation.xsd bereitgestellt).

• Der Inhalt der Datei ist ungültig, z.B. verweist ein MapInformation-Element in der Datei auf ein nicht vorhandenes Zuordnungselement. Es kann eine Vielzahl anderer Gründe dafür geben, warum der Inhalt der Datei möglicherweise als ungültig angesehen wird.

• Das mindestens einem Zuordnungselement in der Datei zugeordnete ID-Attribut wird bereits für ein anderes Zuordnungselement verwendet, das nicht mit diesem identisch ist. Dies kann z.B. auftreten, wenn der Benutzer das Übergabezielargument (das erstellt oder bearbeitet wird) auf eine bestimmte ESI-Antwort-Metadatendatei zeigen lässt, deren Zuordnungselement für Teile geändert wird, um ein zusätzliches globales Attribut unterzubringen, aber dessen ID-Attribut weiterhin den Wert ESiPart enthält, während ein anderes Übergabeziel bereits auf die ESI-Antwort-Metadatendatei zeigt, die standardmäßig bereitgestellt wird.

Nachdem TIBCO Laufzeit-Agent 5.6 und TIBCO Laufzeit-Agent 5.6.1 installiert wurden, können TIBCO Adapterprojekte mit Enterprise-Meldungsdienst als Transport nicht von TIBCO Designer gestartet werden. Die folgende Fehlermeldung wird angezeigt:

• Unter Windows: Sichern Sie die Dateien libeay32.dll und ssleay32.dll, und entfernen Sie sie aus <TIBCO_HOME>/adapters/sdk/version/<lib>

• Unter UNIX: Sichern Sie die openssl-Bibliotheken libssl und libcrypto, und entfernen Sie sie aus dem Verzeichnis TIBCO_HOME/adapters/sdk/version/lib

Wenn einem Adapterprozess die Prozess-ID "-1" zugeordnet wird, tritt ein Fehler beim Starten des Adapters auf. Dieser Fehler ist im Allgemeinen von der Bibliothek abhängig.

• Fehler beim Laden von freigegebenen Bibliotheken: librfccm.so: falsche ELF-Klasse: ELFCLASS64

Dieser Fehler tritt möglicherweise auf, wenn Sie 64 Bit-SAPJCo-Bibliotheken verwendet haben. Auf bestimmten Plattformen, wie Windows X64 und Linux ia64, ist der SAP-Adapter eine 32-Bit-Anwendung. Dieses Problem lässt sich durch die Verwendung von 32-Bit-Bibliotheken lösen

• Fehler beim Laden von freigegebenen Bibliotheken: librfccm.so: falsche ELF-Klasse: ELFCLASS32

Dieser Fehler tritt möglicherweise auf, wenn Sie 32 Bit-SAPJCo-Bibliotheken verwendet haben. Auf bestimmten Plattformen, wie HPUX IA64 und Solaris SPARC, ist der SAP-Adapter eine 64-Bit-Anwendung. Dieses Problem lässt sich durch die Verwendung von 64-Bit-Bibliotheken lösen

• libresolv.so.2 sunw_2.2.2

• libstdc++-libc6.2-2.so.3

• Die richtigen Kompatibilitätspakete wurden installiert. Damit werden alle Abhängigkeiten aufgelöst.

• Wenn Java-Umgebungsvariablen festgelegt wurden, stellen Sie sicher, dass die Versionen kompatibel sind. TIBCO Anwendungen installieren auch JRE 1.5 und 1.6. Sie können alle Java-Einstellungen entfernen, die Sie bereits konfiguriert haben, und zulassen, dass die TIBCO Anwendung die entsprechenden Java-Variablen festlegt.

• Wenn die Java-Variablen auf HPUX- und Solaris-Computern bereits festgelegt wurden, stellen Sie sicher, dass der Klassenpfad 64-Bit-Java-Bibliotheken enthält, da der SAP-Adapter auf diesen Plattformen eine-64-Bit-Anwendung ist.

• Es konnte keine Verbindung mit dem JMS-Server ttcp://<JMSServer>:7222 hergestellt werden

Dies kann u.U. geschehen, wenn der JMSServer entweder nicht erreichbar ist oder der Hostname nicht in die richtige IP-Adresse aufgelöst wird. Auch eine falsche Version der Datei tibjms.jar kann dieses Problem verursachen. Um dieses Problem zu beheben, stellen Sie sicher, dass die Datei tibjms.jar vom Windchill Server die richtige JMS-Version auf dem TIBCO Server verwendet.

2. Pingen Sie <JMSServer> unter Verwendung der genauen Zeichenfolge, die in den Windchill Methodenserver-Protokollen angezeigt wird.

4. Wenn die Pinganfrage erfolgreich ist, verwenden Sie die angezeigte IP-Adresse oder fügen Sie der Datei %Windir%\System32\drivers\etc\hosts den folgenden Eintrag hinzu: <JMSServer_IP> <JMSServer>

• Beim Herstellen der Verbindung mit der DataResponse-Warteschlange trat ein Fehler auf.

Um zu überprüfen, ob dies die Ursache dieses Problems war, stellen Sie eine Verbindung mit dem JMS-Server her und überprüfen, ob die DataResponse-Warteschlange erstellt wurde und ob der WCESI-Benutzer über Berechtigungen zum Senden von Daten an die DataResponse-Warteschlange verfügt. Wenn ein Sternchen (*) vor dem DataResponse-Warteschlangennamen angezeigt wird, ist die Warteschlange temporär und muss erstellt werden. Dieses Problem kann auftreten, wenn EAR manuell bereitgestellt wurde. Um dieses Problem zu lösen, führen Sie folgende Befehle im JMS-Administrationsfenster aus:

• Das Prozessarchiv ist nicht mit der gleichen DataResponse-Warteschlange verbunden.

Öffnen Sie das JMS-Administrationsfenster, um zu bestätigen, dass die DataResponse-Warteschlange vom Prozessarchiv abonniert wurde. Bei der manuellen Bereitstellung wird dieser Schritt oft weggelassen, und dies führt zu diesem Fehler. Wenn die DataResponse-Warteschlange nicht abonniert wurde, um den Wert in DataResponseQueue zu überprüfen, indem zu "TIBCO Administrator > Anwendungsverwaltung > Anwendungsname > Konfiguration > Bereitstellungsname > Erweitert> ESIJMS/DataResponseQueue" gewechselt wurde

• Nur ein WCESI-Benutzer ist mit dem EMS-Server verbunden. Überprüfen Sie dies, indem Sie zu "EMS Administration Tool > Verbindungen anzeigen" navigieren.

• Die Anzahl der ESISYS-Verbindungen mit ClientID (BW-ESIMaster_JMSConnection-queue-<Anwendungsname>-Process_Archive) sollte der Anzahl der konfigurierten ERP-Instanzen entsprechen. Wenn dies nicht so ist, besteht die Möglichkeit, dass die zusätzlichen Instanzen von laufenden Prozessarchiven die ESI-Antwortmeldung verbrauchen. Überprüfen Sie die Anzahl der ESISYS-Verbindungen, indem Sie zu "EMS Administration Tool > Verbindungen anzeigen" navigieren.

• Überzeugen Sie sich, dass alle Verbindungen vom TIBCO oder Windchill Server in der aktuellen Testsuite ausgehen und dass keine Verbindungen von der vorherigen Suite oder einem fremden Computer stammen. Wenn dies nicht so ist, besteht die Möglichkeit, dass die zusätzlichen Instanzen von laufenden Prozessarchiven die ESI-Antwortmeldung verbrauchen. Überprüfen Sie die Anzahl der ESISYS-Verbindungen, indem Sie zu "EMS Administration Tool > Verbindungen anzeigen" navigieren. Überprüfen Sie dies, indem Sie zu "EMS Administration Tool > Verbindungen anzeigen" navigieren.

• Windchill und Prozess-Archive sind mit der gleichen JMS-Warteschlange verbunden. Überprüfen Sie dies, indem Sie zu "EMS Administration Tool > Show queues (Warteschlangen anzeigen)" navigieren.

• Die Warteschlange com.ptc.windchill.esi.Result hat nur einen Empfänger. Überprüfen Sie dies, indem Sie zu "EMS Administration Tool > Show queues (Warteschlangen anzeigen)" navigieren.

• Es verbleiben Meldungen in einer Warteschlange. Überprüfen Sie dies, indem Sie zu "EMS Administration Tool > Show queues (Warteschlangen anzeigen)" navigieren.

• Die während der Erstellung des Übergabeziels für die Attribute Client und System-ID angegebene Wert entspricht nicht den entsprechenden Werten, die beim Ausführen der MICU für die gegebene SAP Instanz angegeben werden. Dies führt zu Windchill ESI-Diensten, die die ESI-Antwortmeldung in eine nicht vorhandene EMS-Warteschlange einfügen, was wiederum bewirkt, dass die ESI-Transaktion den Status "Ausstehend" behält.

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)]

Dieses Problem tritt bei den Java-Bibliotheken auf, die im Lieferumfang von JRE 6 enthalten sind. Bei JRE 1.5 und JRE 1.6.0.18 wurde es nicht festgestellt.

Dieser Fehler weist auf einen Schemavalidierungsfehler in der Aktivität "Invoke an adapter request response service (Aufruf eines Adapter-Anfrage-Antwortdienstes)" hin. Eine ausführliche Beschreibung und ein Stacktrace werden in die processArchive-Protokolle eingefügt. Die Protokolle geben den genauen Grund des Schemakonflikts an. Beispiel:

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

• Die ESI-Dienste konnten die ESI-Antwort nicht in die DataResponse-Warteschlange des EMS-Servers schreiben. Um dieses zu überprüfen, navigieren Sie zu "Info*Engine-Verwaltung" > "Eigenschaften-Editor" > "JMS-Haupteigenschaften" und überzeugen sich davon, dass dieser JMS-Basis-URI richtig ist. Dann sehen Sie in den Methodenserverprotokollen nach, um sich zu vergewissern, dass die DataResponse-Warteschlange erfolgreich abonniert wird.

• Verbindung zum JMS-Server tcp://<JMSServer>:7222 fehlgeschlagen. Um dieses Problem zu beheben, stellen Sie sicher, dass die Datei tibjms.jar vom Windchill Server die richtige JMS-Version auf dem TIBCO Server verwendet.

• Der JMSServer ist entweder nicht erreichbar, oder der Hostname wird nicht in die IP-Adresse aufgelöst. Dieses Problem kann durch eine falsche Version der Datei tibjms.jar verursacht werden. So überprüfen Sie dies:

2. Pingen Sie <JMSServer> unter Verwendung der genauen Zeichenfolge, die in den Windchill Methodenserver-Protokollen angezeigt wird.

4. Wenn die Pinganfrage erfolgreich ist, verwenden Sie die angezeigte IP-Adresse oder fügen Sie der Datei %Windir%\System32\drivers\etc\hosts den folgenden Eintrag hinzu: <JMSServer_IP> <JMSServer>

• Beim Herstellen der Verbindung mit der DataResponse-Warteschlange trat ein Fehler auf.

• Das Prozessarchiv ist nicht mit der gleichen DataResponse-Warteschlange verbunden.

Öffnen Sie das JMS-Administrationsfenster, um zu bestätigen, dass die DataResponse-Warteschlange vom Prozessarchiv abonniert wurde. Bei der manuellen Bereitstellung wird dieser Schritt oft weggelassen, und dies führt zu diesem Fehler. Wenn die DataResponse-Warteschlange abonniert wurde, um DataResponseQueue zu überprüfen, indem zu "TIBCO Administrator > Anwendungsverwaltung > Anwendungsname > Konfiguration > Bereitstellungsname > Erweitert > ESIJMS/DataResponseQueue" gewechselt wurde

Der Befehl zum Starten des EMS-Servers wurde in Version 5.1.4 geändert. In den EMS Versionen 4.x lautete der Startbefehl "./tibemsd". In EMS Version 5.1.4 lautet er ./tibemsd64 -config../tibco/cfgmgmt/ems/data/tibemsd.conf. Der Befehl verwendet einen relativen Pfad, und er sollte ausgeführt werden aus dem Verzeichnis "<TIBCO_HOME>\ems\5.1\bin".

Um dieses Problem zu beheben, halten Sie den Prozess an, der gestartet wurde vom Befehl "./tibemsd", und starten Sie den EMS-Server mit dem richtigen Befehl:.

Dieses Problem tritt wegen eines Adapterstapelüberlauffehlers auf. Der TIBCO Support hat dies als bekanntes Problem akzeptiert und empfohlen, den Wert des Parameters adr3.stacksize auf einen geeigneten Wert zu vergrößern, um dieses Problem zu beheben. Es wurde es mit dem Wert 524288 (512 KB) erfolgreich getestet.

Um adr3.stacksize zu vergrößern, navigieren Sie zur grafischen Benutzeroberfläche von "TIBCO Administrator > Anwendungsverwaltung > < ApplicationName > Konfiguration > ESISAPAdapterConfiguration.aar > Erweitert".

Das Erhöhen einer Gruppe von Geschäftsobjekten über einen Erhöhungsantrag bewirkt, dass für jedes dieser Objekte ein RTM-Workflow erstellt wird

Dies kann passieren, wenn die Einstellung Erhöhungsanträge publizieren den Wert Nein hat. Legen Sie die Einstellung auf Ja fest, damit die Objekte im Erhöhungsantrag über einen einzelnen RTM-Workflow publiziert werden.

Die ESI-Antwortdatei, die nach dem Erhöhen eines oder mehrerer Geschäftsobjekte generiert wird, enthält keine Informationen zu dem Erhöhungsantrag abgesehen von seiner ID

Dies ist ein erwartetes Verhalten. Wenn Sie andere Attribute im Erhöhungsantrag mit der ESI-Antwort in einem separaten XML-Element senden möchten, müssen Sie die Metadatendatei der ESI-Antwort entsprechend konfigurieren.