-
FileNet Image Service 4.1.x
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
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.