IBM/FileNet P8

Bei der Installation der JDBC treiber läuft der Configuration Manager der Content Engine auf Fehler.

Problem: Aus WebSphere Sicht sind die notwendigen JDBC Jars Files nicht sichtbar

Lösung:

  • Sicherstellen, dass die jdbc JAR Files für die Datenbank in der richtigen Version  für den Benutzer der WebSphere ausgeführt und zugreifbar sind
  • JDBC Variable in WebSphere für Node, und Server und Cell explizit setzen, einer alleine reicht nicht, danach muss WebSphere restartet werden, damit es greift
  • Alle notwendigen jar Files für den JDBC treiber müssen im gleichen Verzeichnis liegen , bei DB2 muss auch das Lizenz File dort liegen, evt. bei DBA nachfragen

Nach der Installation erhält man bei der erstmaligen Anmeldung am WorkplaceXT folgenden Fehler:

com.filenet.api.exception.EngineRuntimeException:An unexpected error
occured accessing JNDI. [Code=null];
OMFC/TheNetwork/NoOp//API_UNEXPECTED_JNDI_ERROR

Umgebung:

  • WebSphere 8.5.0.2, Profil für CE , Profil für XT
  • XT 1.1.5.2
  • CE 5.2.2
  • DB2 10.1

Lösung:

  • Für jedes Profil in WebSphere unter Server - Servertypen - WebSphere-Anwendungsserver - Java Prozessverwaltung - Prozessdefinition - Java Virtual Maschine - Angepasste Eigenschaften - com.ibm.websphere.orb.uniqueServerName=true hinzufügen, beide WebSphere Profile restarten
  • Security von WebSphere 8 hat sich geändert, gemäß folgendem Artikel von IBM anpassen: http://www-01.ibm.com/support/docview.wss?uid=swg27023814
  • Prüfen, dass die Portnummer der CE muss dem EJB Port entsprechen, kann man wie folgt prüfen:  WebSphere im CE Profil. unter Anwendungsserver - Ports - Bootstrap_Address : (default bei Base 2809, bei Network Deployment 9810)

betroffene Produkte

  • Service.jar

betroffene Komponente

  • Archiv/Folder

Fehler

  • Null Pointer Exception

Beschreibung

  • Beim Anlegen eines folder tritt eine Null Pointer Exception auf.

Ursache

  • Inkompatible Objekte im Buffer

Lösung

  • Beim Austausch der Service.jar ist darauf zu achten, dass alle Jobs aus der Datenbank und den Buffern (Ordner im Dateisystem) entfernt sind.

betroffene Produkte

  • FileNet Image Service 4.1.x

betroffene Komponente

  • stdoccpy

Fehler

  • stdoccpy reportet ein Dokument fälschlicherweise als kopiert

Beschreibung

  • Mit stdoccpy verlagert Dokumente  werden laut Log und Dokumentliste als erfolgreich kopiert aufgelistet. Dokumente liegen aber im Sektor 0 und befinden sich damit nicht auf der neu erstellten Platte

Ursache

  • Bug im FileNet Image Services (  IS ) Release

Lösung

  • vorheriger Prefetch der Dokumente in den Cache für die zu kopierende Platte umgeht das Problem.

 

ähnliche Fehler