Case Manager developers are expected to be multi disciplinary. e.g. they’re expected to be experienced ECM consultants, guru in solution design, expert in Filenet P8 configuration/development, and both Java EE as wel as Web expert.

The thing is, most of the developers only excel in one, and lack expert knowledge of another. In practice most will definately be able to create some java (or dojo), but more than once i’ve seen people get stuck on the debugging. So, in this article, i’ll share a few short lines on how to debug your widgets/plugins.

Debugging java-code that’s run on the server.

This part assumes the use of Websphere and Eclipse.

First of all, know that all your Case Manager Widget’s or Content Navigator plugin’s java-code runs on the server. The .ear files you’ve included within your widget.zip are installed as applications on the webserver; and the navigator plugins you’ve included are run from within the Navigator web-application -> that’s run on Websphere as well.

So following that your java code is run on Websphere there are two things we need to do to be able to debug.

1. Enable debug-mode in Websphere.

When enabling debug mode within Websphere, we bascially set enable debug mode in the Java Virtual machine. The easiest way to do this is by using the WAS console (https://<server>:9043/ibm/console)

Step 1. Login to the WAS console and locate your server (server1 in the below screenshot). Click on it.

Step 2. In the screen that follows, locate  “Debugging Service”  under “Additional Properties”, click it.

 

Step 3. Check the “Enable service at server startup” and enter a “JVM-debug port”. Can be be arbitrary as long as it’s not in use.

Step 4. Reboot Websphere. The debugging port won’t be upon until after reboot.

2. Connect to the JVM debug port using Eclipse.

Step 1. Open the Debug Configurations screen.

Step 2. Add a new “Remote Java Application”.

Step 3. Choose the Project you want to debug and enter the your websphere IP as HOST, and port 7777 as port. Then press debug. The screen will close, and the debugger will connect.

3. Set your breakpoints and debug.

Place your breakpoint, execute the corresponding functionality in your application and watch the debugger kick in.

Debugging your widget’s javascript.

Debugging javascript is quite easy in modern browsers. Although IBM cleary notes it’s designing its products for use with FireFox and Internet Explorer, i personally prefer Chrome.

When in chrome, simply press the F12 key.  In the screen that opens (The Developer Tools) then search for the Sources tab. This tab will list all .js files loaded, including your plugin script.

An easier way to locate your line of code, is by pressint CTRL+SHIFT+F, allowing you to search all code for a specific line as shown below.

Once you’ve found your file, just click the line-numbers to place a breakpoint and you’re set!

Debugging your Script-adapter’s javascript.

The above doesn’t really count for script adapters. As the script written in the adapters is executed through eval() or runscript. There are two workarounds.

1. Externalize your script in a .js and call it from the script adapter.
   No much explanation needed i guess 🙂
2. Make use of the debugger; statement.
   The debugger statement will force to hold execution whenever the Developer Tools are open (all browsers supported). The below screenshots demonstrates a simple ScriptAdapter that pauses on the debugger statement.

Additionally, if you can also drag your script-adapter from the hidden part in the page-designer onto the page. This way your script adapter will (if checked) actively show the payloads received by your script adapter.