When using the FileTracker.getTrackingInfo in your plugin, it will throw an NPObject error exception if one folder of the FileTracker directory is empty (main or sub-folders) and if the file is not tracked yet.
Status: fixed in 2.0.3.3
You might have noticed that when using the ecm/model/FileTracker class in IBM Content Navigator, the callback is never called.
For instance if you are using the following code:
FileTracker.downloadAndTrackFiles(documentInfoObj, function (response) {
console.log("Never invoked");
});
the callback is never called. This is because there is a defect in the FileTracker processMessage function, it does not look correctly for the callback because of a = missing in the condition:
var callbackResponse;
if (response.responses && response.responses.length > 0) {
var callbackResponse;
for ( var i = 0; i < response.responses.length; i++) {
if (response.responses[i].errorCode = this.SERVER_RESPONSE_CALLBACK) {
callbackResponse = response.responses[i];
break;
}
}
} else if (response.errorCode == this.SERVER_RESPONSE_CALLBACK) {
callbackResponse = response;
}
This is fixed in Fix Pack 3 though (2.0.3.3), so you can either upgrade or use a plugin to do an aspect around and replace the function by the correct one, which is:
processMessage: function(json, showSuccessMessage) {
var methodName = "processMessage";
this.logEntry(methodName);
var response = dojojson.fromJson(json);
if (response.hasError) {
var errorPrefix = "", inserts = [];
var showError = true;
if (response.errorCode == 7) {//ERROR_OPEN_FAILED
errorPrefix = "runtime_file_tracking_file_not_found_error";
} else if (response.errorCode == 3) {
errorPrefix = "runtime_file_tracking_ioexception_error";
} else if (response.errorCode == this.ERROR_NOT_TRACKED) {
showError = false;
} else if (response.errorCode == this.ERROR_OPEN_FAILED) {
showError = true;
errorPrefix = "runtime_file_tracking_open_error";
} else if (response.errorCode == this.ERROR_SAVE_FILE_FAILED) {
showError = true;
errorPrefix = "runtime_file_tracking_save_file_error";
} else if (response.errorCode == this.ERROR_SAVE_FILE_FAILED_AND_OPEN_FIALED) {
showError = true;
errorPrefix = "runtime_file_tracking_save_file_after_checkout_error";
} else if (response.errorCode == this.ERROR_ENVIRONMENT_VARIABLE_PATH_NOT_FOUND) {
showError = true;
errorPrefix = "runtime_file_tracking_ev_file_path_not_found_error";
} else if (response.errorCode == this.ERROR_OPEN_CONNECTION) {
showError = true;
errorPrefix = "runtime_file_tracking_ioexception_error";
} else if (response.errorCode == this.ERROR_FOLDER_NOT_FOUND) {
showError = true;
errorPrefix = "runtime_file_tracking_exact_file_path_not_found_error";
} else if (response.errorCode == this.ERROR_EXACT_PATH_NOT_FOUND) {
showError = true;
errorPrefix = "runtime_file_tracking_exact_file_path_not_found_error";
} else if (response.errorCode == this.ERROR_CANNOT_CREATE_TRACKING) {
showError = false;
errorPrefix = "runtime_file_tracking_exact_file_path_not_found_error";
} else if (response.errorCode == this.ERROR_DELETE_FILE_FAILED) {
showError = true;
errorPrefix = "runtime_file_tracking_cannot_delete_file_error";
} else {
showError = true;
errorPrefix = "runtime_file_tracking_generic_error";
}
if (showError) {
if (response.responses && response.responses[0].value) {
inserts.push(response.responses[0].value);
} else if (response.value) {
inserts.push(response.value);
}
Desktop.addMessage(Message.createErrorMessage(errorPrefix, inserts, false));
}
} else {
var successMessage = "";
if (response.responses) {
if (response.responses.length == 1 && ((response.responses[0].errorCode == this.ERROR_DELETE_FILE_FAILED || response.responses[0].errorCode == this.FOUND_TRACKED_RECORD_BY_FILE_PATH) || (response.responses[0].errorCode == this.FOUND_TRACKED_RECORD_BY_SCANNING) || (response.responses[0].errorCode == this.SUCCESSFULLY_TRACKED_FILE_USING_ADS))) {
successMessage = string.substitute(ecm.messages.file_tracking_successfully_downloaded_document, [
response.responses[0].originalDocumentName,
response.responses[0].value
]);
} else if (response.responses.length > 1 && ((response.responses[0].errorCode == this.FOUND_TRACKED_RECORD_BY_FILE_PATH) || (response.responses[0].errorCode == this.FOUND_TRACKED_RECORD_BY_SCANNING) || (response.responses[0].errorCode == this.SUCCESSFULLY_TRACKED_FILE_USING_UD) || (response.responses[0].errorCode == this.SUCCESSFULLY_TRACKED_FILE_USING_ADS))) {
var count = response.responses.length;
var documentsDownloaded = [];
for ( var i = 0; i < count; i++) {
documentsDownloaded.push(response.responses[i].originalDocumentName);
}
successMessage = string.substitute(ecm.messages.file_tracking_successfully_downloaded_document, [
documentsDownloaded.join(",")
]);
}
}
if (successMessage && successMessage.length > 0) {
Desktop.addMessage(new Message({
number: 0,
level: 0,
text: successMessage
}));
}
var callbackResponse;
if (response.responses && response.responses.length > 0) {
var callbackResponse;
for ( var i = 0; i < response.responses.length; i++) {
if (response.responses[i].errorCode == this.SERVER_RESPONSE_CALLBACK) {
callbackResponse = response.responses[i];
break;
}
}
} else if (response.errorCode == this.SERVER_RESPONSE_CALLBACK) {
callbackResponse = response;
}
if (callbackResponse && callbackResponse.value) {
var lookupId = callbackResponse.value.callbackId;
if (lookupId && this.callbackMap[lookupId]) {
var callbackFunc = this.callbackMap[lookupId];
if (callbackFunc) {
callbackFunc(callbackResponse.value.response);
}
}
}
}
this.logExit(methodName);
return response;
//MessageFactory.createErrorMessage = function(messagePrefix, inserts, backgroundRequest);
},
One feature I really miss in ICN right now is a 2 ways communication channel between service and client. At this moment, you call your service and then it returns something when the execute method is done. That creates an issue, because users have no patience… More than one minute on the same loading spinner and you can be sure most of them will refresh the page thinking ICN crashed. That won’t stop your service, but if this one is not done by the time the user comes back, he will run the service again…
So here is a way to push information from the server to the client.
I used CometD to implement that because ICN is already shipped with some CometD client libraries (actually not all of them, discussed below)). The reason for that is ICN uses CometD for the Sync and Share feature. That way we don’t need to add any library to the client. About the server, the PluginService class is not a servlet or a web service, it is actually called by a Struts action so forget about asynchronous servlet, websocket and so on since we are not master of our servlet. On the other hand, we can’t change the navigator application either (well we could and redeploy but we want to be update proof), so we can’t add support for any “push” framework and ICN doesn’t have that natively. That’s why I’ve decided to use another light web application to achieve that. Here is the schema to help you understand how it works.
Some business logic can require to send a file from the client workstation to the server. Usually to improve performance by doing a server work instead of a client one, sometimes because it’s more convenient for the user or for the developer. I had to transfer a zip to do a zip-add after I noticed that deflating on the client and adding file one by one was to slow for our needs, although it worked fine.
On the client, we won’t use the function Request.invokePluginService as we usually do when invoking services. Instead, we are going to use Request.postFormToPluginService(pluginName, pluginServiceName, form, pluginParams), which allow posting data to our service. However the syntax differs, here we won’t pass our params in the requestParams attribute of the pluginParams argument, this time they all go in the form, which is a W3C FormData object, along with our W3C File. Here is the example.
var fd = new FormData();
fd.append('file', zipArchive);
fd.append(Constants.PARAM_FOLDER_ID, this.parentFolder.id);
fd.append(Constants.PARAM_REPOSITORY, this.parentFolder.repository.id);
fd.append(Constants.PARAM_SERVER_TYPE, this.parentFolder.repository.type);
var pluginParams = {
requestCompleteCallback: lang.hitch(this, function (response) {
this.parentFolder.refresh();
})
};
Request.postFormToPluginService("GenericActionsPlugin", "AddZipService", fd, pluginParams);
This is all it takes on the client.
Now let’s see how to fetch this file and use it in our service.
ICN is still using Struts. That means we will use the FormFile interface to get our file (actually the stream). The FormFile is added as attribute of the request by the PluginAction class in charge to call your Plugin class so you can retrieve it with:
FileUploadActionForm uploadForm = (FileUploadActionForm) request.getAttribute(FileUploadActionForm.class.getName());
if (upload != null) {
FormFile ff = (FormFile) uploadForm.getMultipartRequestHandler().getFileElements().get("file");
}
In order for this to work, you will have to add to your classpath the ICN classes. You can find them by deflating the ear file or going to your application server in the installed app, usually there will be the exploded ear there too. That could be more convenient to zip all WEB-INF/classes in a jar and add that to your classpath.
However, the other parameters are still retrieved with request.getParameter().
Then you can use the stream. If you need a file, even if in the ICN implementation FormFile, the file is actually stored in a WAS temp directory, this is not possible to get it so you’ll have to copy the stream in a temp file and use this file instead.
Here is the server side example corresponding to the client.
String repositoryId = (String) request.getParameter(Constants.PARAM_REPOSITORY);
String parentFolderIcnId = (String) request.getParameter(Constants.PARAM_FOLDER_ID);
String parentFolderId = P8Helper.getP8ID(parentFolderIcnId);
ObjectStore os = callbacks.getP8ObjectStore(repositoryId);
FileUploadActionForm uploadForm = (FileUploadActionForm) request.getAttribute(FileUploadActionForm.class.getName());
if (uploadForm != null) {
FormFile ff = (FormFile) uploadForm.getMultipartRequestHandler().getFileElements().get("file");
if (ff != null) {
InputStream is = ff.getInputStream();
// Do something with the stream
}
}
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
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