If like me, you are a really clumsy person, you may delete the entire Object Store on a stupid mistake. Don’t laugh, it happened to me. I was working with the FEM and I clicked without reading twice :). From the FileNet knowledge center, this is supposed to be an irreversible action. The truth is it’s not, thanks god because i could have been in real trouble! So if you don’t have snapshot of the platform before, or your backup is hard to restore, or you will loose to much data since the last backup, here is another solution.

This is a really nice trick to recover a deleted object store really easily. It can save you a lot of troubles too. It is really well explained in the link, but here is the procedure summarized.

Actually the deletion of an object store is an update like every other updates, therefore it can be undone by updating the FNGCD table of the GCD database, which store the last 100 updates. You just have to set he last_epoch_id of the line with the id 0, to the the value of the update before the deletion.

I have to thank so much my colleague for finding and then sharing this trick with me!

Today, when I was doing unit testing, I discovered a weird behavior in P8. I just discovered that the fetchInstance method of the Factory.Document, this one:

public static Document fetchInstance(ObjectStore os, String path, PropertyFilter filter)

can also take the Id as a string and not only a path. I wasn’t as nice as P8 in my unit test since I was expecting an ID type when mocking the static method, and of course my test failed :). I still think this isn’t a good practice so I changed my code to convert the String to an Id, but I thought it was worth noticing so here is a post about it. The best way in my opinion is to write

Factory.Document.fetchInstance(os, new Id(id), pf);

instead of

Factory.Document.fetchInstance(os, id, pf);

which actually works. I had to debug to convince myself because I found really strange that it worked :).

That’s it folks. Another good to know, but not good to do!

One upon a time, I was wondering what the stanza name is for when connecting to P8,  using most of the time a null value. Today I remembered this lost time and I thought I would write about it.

Why does it work with null

It works with a null stanza name when you don’t have the thin client jar in your classpath. Indeed this jar contains some properties files which makes the connection impossible without stanza name. If you are using WSI connection (CEWS), you don’t need this jar. But if you are sometimes using the EJB connection and have this jar in your classpath, then the WSI connectionwon’t work with a null stanza name, and you will have to do things properly, i.e. use the appropriate stanza for the WSI: FileNetP8WSI.

What stanza name to use

Well to do things properly, always use FileNetP8WSI when connecting via WSI, and always use FileNetP8 when connecting via EJB, even if you don’t have the thin client jar in your classpath. At least if you add it later because you want to use an EJB connection, your code won’t break on every WSI connection.
Continue reading →

Since it can sometimes be tricky, I thought I would write about how to establish an EJB connection to a P8 platform. I try a lot of things to actually see it was quite easy.

First, forget about a non SSL connection with WebSphere 8. I tried a lot of things, including modifying the RMI/IIOP configuration in the WebSphere console to allow non SSL connection but nothing worked. But using SSL for EJB does’t mean you have to have your CE exposed via https, this is something different and doesn’t require any settings so why not use this.
Continue reading →

It is always nice to have benchmarks to see if what we use does really impact performance. That’s why I thought I would do this Updating Batch performance assessment. To see how much using a UpdatingBatch can improve performance. The idea was also to see if we are creating/updating/deleting a lot of objects, what is the best chunk size, meaning the number of objects you will include in one batch, then create a new one. Of course you can add all your updates to the same batch, but then you could get a Transaction Error from your DB because the transaction would become to big to handle.

As usual I did three tests, on Local, over LAN and over Internet. Although the actual time of execution is not really relevant since we don’t have the same machines, or the same internet connection, what really matters here is the evolution of the execution time depending of the chunk size, where two environments have for bottle neck the network, and the first one the machine resources.

Creation of 1000 sub-folders