Here is a quick summary of how to upgrade to FileNet 5.2.1. As usual, before starting, snapshot/backup your server. Here are the main steps for a single server platform installed with the CPIT installer and where the application server has not been upgraded. If it has been or you platform is different, check the knowledge center but procedure should be mostly the same and you can use this to help you.
Continue reading
Nowadays, everyone seems to think dropping a folder is somehow optional. They all have given up on the File API “Directories and System” (except Google which at least implemented it). I have to admit, I clearly don’t understand because in the ECM world, that just a must-have feature…
Anyway, since this is something our users are expecting, especially since there are used to it with the Workplace XT (via the applet), we had to find a workaround. Actually we found two which are quite complementary. One is using the Chrome Directories and System API, which really allows a true folder drop, but way better than Workplace XT since it’s applet free and therefore mobile supported. The other is supported by all browsers and requires the user to only zip the folder and drop the zip. It’ is only 1 second extra work for the user instead of the hours it would have to spend to create all the folder hierarchy manually and upload files folder by folder. This seems like a good alternative and again, it is supported by every brother.
Let’s present these two workarounds quickly. I won’t explain the whole implementation since it might get quite complex but instead, I will explain how to address the problem.
Continue reading
Using Workplace XT, we were able to keep the folder hierarchy of a Document within the Object Store when downloading it with the File Tracker applet. That means, if your document’s path was /Folder/SubFolder/Document.xml, and your FileTracker folder on the client was C:\FileNet\Work, then you would get your document downloaded as C:\FileNet\Work\ObjectStoreName\Folder\SubFolder\Document.xml.
That’s no longer true with ICN. Everything goes into your download folder, C:\FileNet\Work in the previous example, without creating any sub-directories. This is especially an issue if you download a lot of document and want to edit them, this folder becomes a mess, and if a lot of documents are called the same in your Object Store, then you will have conflicts.
Officially, this is because this functionality is now covered by the Sync and Share feature, which uses a client agent on Windows platform, and is embedded in mobile applications. However this does not cover Unix platforms, and does not allow using Entry Templates, which can be a requirement for your platform. That’s why we will see how to make it work in ICN anyway.
In this post, I will describe how to embed and use a Java applet in your IBM Content Navigator plugin. Applets may be useful to overstep some JavaScript limitations, usually related to security, for instance read/write the client’s file system.
I won’t explain how to write, package and sign your applet since you can find plenty of tutorials on this topic on the web. However I will explain how to embed your applet into your plugin, then how to use it.
Continue reading
I really had to write one single article about all issues occurring when using Workplace XT Entry Template in ICN, because at the time it wasn’t as clear as now in my mind. There are actually two main different issues (in some ways related) both concerning the Entry Templates in ICN, both because they are Workplace XT Entry Templates.
Therefore I am going to split them in two different issues, in two different threads:
This is the second post about the issue occurring when using Workplact XT entry template with ICN. We’ve seen that there is an inheritance problem in this post, we will now see that there is a problem of File Types filters. This issue needs to be addressed if you want to use the second work around of the former issue.
You’ve created Entry Templates in Workplace XT, and also created a few File Type Categories gathering several MIME Types. You’ve used these Entry Templates by associating them on a folder to use them when adding document. You restricted them by File Type Category. For example ET 1 is only for Images (File Type Images gathering image/png, image/jpeg, …), ET 2 is only for office documents, and ET3 is for every king of document. That looks a little bit like that in Workplace XT:
Problem is that in ICN, this does not work. You always get the generic entry template (in my case misc doc, or no Entry Template if they all have restrictions on the File Type Categories.
Continue reading
I just noticed that the following function is not working as the documentation says in the ICN JavaScript model. Actually it can not be used with a document path.
retrieveItem(itemIdOrPath, itemRetrievedCallback, templateID, version, vsId, objectStoreId, action)
Sources for the server part of ICN are not available. However it contains code for all public API services you are using in the ICN JavaScript model, like retrieve an item, a folder content, check in or check out an item and so on. And sometimes it is nice to know what is going on in these services, which can’t be debugged. A way to do that is to set the log level on DEBUG for the ICN server. Of course never do that on production…
This is actually really easy, you don’t even have to do it using Websphere, just go to the administration of ICN, Settings, Logging tab and set the Application-level logging to DEBUG. You can even define what classes/packages you want to log. Then restart WebSphere (maybe restarting the navigator application should be enough I haven’t tried) and you should have all debugs log in the SystemOut.log file of WebSphere (/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server1). That’s might be a lot so don’t forget to filter on some classes/packages.
Continue reading
Sometimes you need to use an external JavaScript libraries in your plugin, because you don’t want to reinvent the wheel. Problem is that often those libraries are not Dojo modules. So how to use them in your dojo class?
Well that’s simple, dojo provides an generic script injection mechanism. Everything declared in the external script will be available in your class. Code is the following:
require(["http://host.com/stuff.js"], function(){
// Everything declared in stuff.js is available here
});
You can link to an http location, or relative location into your project, for instance /application/stuff.js.
Now how to use that in your plugin? You can place your JavaScript file in another application or a CDN to refer it with an http protocole, example:
require(["http://host.com/application/stuff.js"], function(){
// Everything declared in stuff.js is available here
});
Or you can leave the file in your plugin so everything is embedded when you deploy:
require(["plugin/MyPluginID/getResource/jszip/zip.js"], function () {
// Here I can use the variable zip
});
I really wanted to write this because I had some hard time figuring out how this works. The documentation is just wrong and I had to debug quite deeply ICN to understand what the problem was. The function to add a folder is: