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" aus
• 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 gibt keine Übergabezielzuweisung für ein publiziertes Objekt
• Es gab keine Änderung seit der letzten Publizierung
• 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ültig" 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
Um BusinessWorks zu konfigurieren, gehen Sie wie folgt vor:
1. Sichern Sie die folgende Datei:
<<TibcoHome>>/designer/<<version>>/bin/designer.tra
2. Öffnen Sie die folgende Datei in einem Texteditor:
<<TibcoHome>>/designer/<<version>>/bin/designer.tra
3. Suchen Sie nach der folgenden Zeichenfolge:
tibco.env.CUSTOM_CP_EXT
4. Ersetzen Sie diese Zeichenfolge durch Folgendes:
tibco.env.CUSTOM_CP_EXT %RV_HOME%/lib/tibrvj.jar:%RV_HOME%/lib:%RV_HOME%/lib/64:
 |
Es kann zusätzliche Ordner im Pfad geben. Behalten Sie diese Einträge bei, wenn Sie die Zeichenfolge ersetzen.
|
5. Suchen Sie nach der folgenden Zeichenfolge:
tibco.env.CUSTOM_LIB_PATH
6. Ersetzen Sie diese Zeichenfolge durch Folgendes:
tibco.env.CUSTOM_LIB_PATH %RV_HOME%/lib:%RV_HOME%/lib/64:
|
|
Es kann zusätzliche Ordner im Pfad geben. Behalten Sie diese Einträge bei, wenn Sie die Zeichenfolge ersetzen.
|
7. Speichern und schließen Sie designer.tra.
8. Öffnen Sie TIBCO Designer, und starten Sie das Prozessarchiv.
Eine der folgenden SAP Meldungen wird im Windchill Enterprise Integration Systems Transaktionsprotokoll angezeigt:
"No unit of measure found in ISO code __ in field BASE_UOM_ISO"
oder
"The field MARA-MEINS/BAPI_MARA-BASE_UOM(_ISO) is defined as a required field; it does not contain an entry"
Mögliche Fehlerursachen sind:
• 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.
Windchill ESI gibt eine Adapter-Timeout-Meldung zurück
• 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.
|
|
Zur Lösung dieses Problems benötigen Sie eventuell die Hilfe Ihres Windchill ESI Administrators.
|
Windchill PDMLink kann eine EMS-Warteschlange nicht abonnieren
Mögliche Fehlerursachen sind:
• 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.
|
|
Zur Lösung dieses Problems benötigen Sie eventuell die Hilfe Ihres Windchill ESI Administrators.
|
Fehlermeldungen in PostResult
Mögliche Fehlerursachen sind:
• 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 #ESISAPTroubleOther/WCPDMLinkCannotSubscribeEMSQueue).
• Datenbankfehler in Windchill PDMLink
• Die PostResult-RPC-Anfrage wurde aufgrund eines Programmierfehlers in der Windchill ESI Middleware nicht richtig formatiert.
|
|
Zur Lösung dieses Problems benötigen Sie eventuell die Hilfe Ihres Windchill ESI Administrators.
|
Es gibt keine Übergabezielzuweisung für ein publiziertes Objekt
Mögliche Fehlerursachen sind:
• Sie haben versucht, ein Objekt vor der Zuweisung von Übergabezielen zu publizieren.
• Sie haben versucht, ein Objekt nach dem Entfernen aller Übergabezielzuweisungen zu publizieren.
Es gab keine Änderung seit der letzten Publizierung
Mögliche Fehlerursachen sind:
• 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.
TIBCO BusinessWorks oder/und Windchill können keine Verbindung zu EMS herstellen
Mögliche Fehlerursachen sind:
• 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.
Zum Lösen dieses Problems gehen Sie folgendermaßen vor:
• Legen Sie die QueueConnectionFactory zugeordnete URL-Eigenschaft in der Datei factories.conf auf tpc://<Rechnername>:7222 fest
Hierbei steht Rechnername für den Rechner, auf dem der EMS-Server ausgeführt wird.
• 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:
>show connections
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.
Bei TIBCO Adapter kommt es zu Zeitüberschreitungen bei der Verarbeitung von ESI-Transaktionen
• 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
Es wird eine auf die ESI-Antwort-Metadatendatei bezogene Fehlermeldung angezeigt
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.
Adapter kann nicht mit JMS-Transport gestartet werden
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:
Code = AESDKC-0156,Category = JmsComm, Severity = errorRole, Description = could not open JMS shared library jms.
Zum Lösen dieses Problems gehen Sie folgendermaßen vor:
• 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
Adapter kann nicht gestartet werden; im Administrator wird weiterhin der Status "Starting Up (Starten)" angezeigt
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.
Folgendes sind bekannte Fehler:
• 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
Ähnliche Probleme wurden bei den folgenden Bibliotheken beobachtet:
• libresolv.so.2 sunw_2.2.2
• libstdc++-libc6.2-2.so.3
• libstdc++.so.5
Überprüfen Sie Folgendes:
• 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.
Coyote-Anschluss wurde nicht gestartet
Überprüfen Sie die Variablen ESIOthers/WSHost und ESIOthers/WSPort.
Publikation behält im Enterprise-Transaktionsprotokoll den Status "Ausstehend"
Dieses Problem kann eine der folgenden Ursachen haben:
• 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.
1. Öffnen Sie ein Befehlsfenster auf dem Windchill Server.
2. Pingen Sie <JMSServer> unter Verwendung der genauen Zeichenfolge, die in den Windchill Methodenserver-Protokollen angezeigt wird.
3. Wenn die Pinganfrage fehlschlägt, führen Sie ping <JMSServer_IP> aus.
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>
5. Wenn die Pinganfrage weiterhin fehlschlägt, wenden Sie sich an Ihrem Netzwerkadministrator.
• 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:
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
• 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.
JAX-M-Parser oder XML-Parser konnte eine Meldung nicht mit dem XML-Schema ResultResponse analysieren
Die folgende Fehlermeldung wird angezeigt:
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.
Die Meldung "Eingabedaten ungültige" wird im Enterprise-Transaktionsprotokoll angezeigt
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
Transaktion behält im Enterprise-Transaktionsprotokoll den Status "Ausstehend"
Dieses Problem kann eine der folgenden Ursachen haben:
• 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:
1. Öffnen Sie ein Befehlsfenster auf dem Windchill Server.
2. Pingen Sie <JMSServer> unter Verwendung der genauen Zeichenfolge, die in den Windchill Methodenserver-Protokollen angezeigt wird.
3. Wenn die Pinganfrage fehlschlägt, führen Sie ping <JMSServer_IP> aus.
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>
5. Wenn die Pinganfrage weiterhin fehlschlägt, wenden Sie sich an Ihrem Netzwerkadministrator.
• 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:
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
• 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
Alle EMS-Serverkonfigurationen verschwinden, nachdem der EMS-Server manuell gestartet 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:.
"./tibemsd64 -config ../tibco/cfgmgmt/ems/data/tibemsd.conf"
Der TIBCO Adapter für eine SAP-Instanz reagiert nicht mehr, und es wird ein Fehlerstatus angezeigt
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.
Dieses Problem tritt gegenwärtig nur auf Computern mit HPUX v3 auf.
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.