Author Archives: Guillaume

Integration Tests on ICN

After my few posts on Unit Testing, I would like to introduce how to do Integration Testing on ICN. Integrations Testing means interaction with other systems. in our case, it means FileNet. However for the IT, we don’t want to rely on the ICN server, because it would require user interaction, and this is the purpose of the UI test (see this post for more information).

The purpose of the Integration Tests is to call every services we wrote in our plug-in, directly and check changes made to the FileNet repository or other repositories are what we expect them to be.
Continue reading

Make EclEmma test coverage work with PowerMock

EclEmma and Mockito do not work well together out-of-the-box. EclEmma report no coverage at all on test run with PowerMock runner. However there is a way to make it work together, using the PowerMock javaagent. To do this, don’t use the @RunWith(PowerMockRunner.class) annotation as you’re used to. Instead, use the standard JUnit Runner or your runner extending a JUnit one, and add this rule to all your test classes:

@Rule
public PowerMockRule rule = new PowerMockRule();

You will also need to add the 2 following jars to your classpath, as explained here:

  • powermock-module-javaagent
  • powermock-module-junit4-rule-agent

You can find then on the Maven repository: here and here.

Third step is to initialize the agent, add the following lines to all your test classes, or to you runner if you have one to add it only once:

static {
     PowerMockAgent.initializeIfNeeded();
 }

And finally last step: modify your launch configuration running your test to add the following option to the VM arguments:

-javaagent:libs/powermock-module-javaagent-1.6.0.jar

And you should be able to use the Coverage As for EclEmma and see you test coverage result!

Unit Test – Using PowerMock with FileNet

To write true unit test, and make sure your FileNet developments do not rely on FileNet for unit test, one solution is using PowerMock, because it allows to mock the static methods from FileNet, that we are using a lot since there are quite usual in the FileNet Java API, for example all the fetInstance and getInstance of the Factory objects, when creating Batches and so on.

How to set up PowerMock for your project

If you are not using any project management software to manage your dependencies like Maven, you’ll have to download the PowerMockito dependencies on the PowerMock website.

PowerMockito can work with both Mockito and EasyMock, you can use which one you are familiar with. If you are not familiar with any of them, I would recommend Mockito.  I prefer the Mockito syntax, I think it makes test easier to understand and maintain. You only have to take the zip for what you want to do, in our case the  powermock-mockito-junit zip.

Then add all zip to your classpath and you are good to go.
Continue reading

Unit Testing and FileNet

Unit test has to keep its unit, even with FileNet

In Unit Test, there is Unit, and people tends to forget that when writing tests with FileNet. That means your test should not rely on anything else than itself, especially not FileNet. Because then what happens? Your tests fail because the platform is down, the test user credentials changed or a network error occurred, and after a while you’ stop noticing the error, thinking “that’s the platform again, but the method’s fine”, or worst, you end up disabling test on your build, because they are becoming a liability more than a help.

Well, this is not how unit test work, I guess you already know that but still. A unit test has to be perfectly reliable, that’s means if your method produce the right outcome, the test should always pass, no matter what, if the test fail, there is something wrong with the method, and you MUST take a look at what’s wrong, not ignore the failure. If you write true unit test, this should be true and you can enable test in the build, and trust failures as real defects.

I’ll write in another post how to set up PowerMock, and some examples so this one does not become to long.

How to make FileNet development not rely on FileNet

Continue reading

Factory.Document.fetchInstance can also take the ID as a String

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!

The importance of the JAAS Stanza name

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

How to connect via EJB to P8 5.2 and WebSphere V8.5

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

The UpdatingBatch performance effect

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

Continue reading

How to change the server’s ports in WebSphere

There is two ways to change the communication ports for a server in WebSphere, the console and the configuration files. The former is the easiest, that I usually use. However today I broke my server by using a port already used, and it refused to start. So I couldn’t use the console as usual and I had to find a different way. I am sharing this because I found a lot of information on WAS 6 and 7 and not really on WAS 8.

Via the administration console

Servers > Server Types > WebSphere application servers > server_name > Communications (on the right side) > Ports

WebSphere_ports_console

Via the configuration file

The file persisting the port number is actually

WAS_HOME/profiles/profile_name/config/cells/cell_name/nodes/node_name/serverindex.xml

You can then change the port number you want and restart the server.

How to debug your JavaScript in ICN

When you develop a plug-in, it is always nice to be able to debug, especially when you spent your day developing without testing, did hundreds of changes, and then got an error and there is no way to know where it comes from. We’ve seen in another post how to activate debug on the server side. Let’s see in this one how to debug the Javascript you have written.

There is two ways of doing that, a proper way fixing a Dojo defect, allowing us to see all files properly in the developer tool, or a temporary way which doesn’t require rebuilding and redeploying ICN. But I’ll tell you, after 3 weeks using the temporary way, I was almost crying and so relieved to find the right way to do that, so the temporary way is more for staging and GA platforms where you can’t apply the proper way.
Continue reading