Debugging Taskflows in WebCenter Spaces

For those who do not know, Oracle WebCenter Spaces is a ready-to-use application that delivers dynamic business communities and pulls together the capabilities of all the WebCenter Services. Oracle WebCenter Services provides a comprehensive set of standards-based components that enrich existing portals and Web sites with the industry's most complete and open set of Enterprise 2.0 capabilities. These Social Computing Services include wikis, blogs, online awareness and communications, content collaboration and social networks. Oracle WebCenter Services works with all Oracle portal offerings, enabling organizations to enhance their existing enterprise portals and Web sites, and empowering users with Enterprise 2.0 services that work with their existing information systems.

WebCenter Spaces can be customized using browser-based tools and also using JDeveloper. For example, you may want to deploy additional shared libraries that include custom code or some additional task flows. Or, you might want to edit/create WebCenter Spaces resources, such as skins, page templates, and navigations, in JDeveloper.  When developing the custom task flows in JDeveloper, there are many times that you will need to test/debug the code after the code has been deployed to a running instance of Spaces.  In this post I will describe how to accomplish this process.

Configuring the Spaces Managed Server Instance

The first step towards enabling debugging is to be able to start the WebLogic managed server, which is hosted Spaces, in debug mode.  One way of setting this up is to modify the startManagedWebLogic.sh (linux)  that will start Spaces.  This script is located in the <oracleHome>/user_projects/domains/<wc_domain>/bin directory. However, since this script is used to start all of the WebCenter hosted services (UCM, Collaboration, .etc), this would mean that these instances would be started in debug mode as well.  Yes, this would be OK, but unneccesary for what I want to do.  So what I do is to make a copy of this script (name the file something like startDebugManagedWebLogic.sh) and then modify this version of the script.

In the new startDebugManagedWebLogic.sh file locate the section that declares the JAVA_OPTIONS. 

Modify the startDebugManagedWeblogic.sh file and add the debug java options: -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=n to the JAVA_OPTIONS.  For example, in my file I added this option in front of the existing option already there:

JAVA_OPTIONS="-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=4000,server=y,suspend=n -Dweblogic.security.SSL.trustedCAKeyStore="/home/oracle/Middleware/wlserver_10.3/server/lib/cacerts" ${JAVA_OPTIONS}"

export JAVA_OPTIONS

Once this is done you will be able to use this script to start Spaces in debug mode. To check to see if the option has been enabled you will see the reference to the debug mode: Listening for transport dt_socket at address: 4000 in the Spaces terminal window.

Configuring JDeveloper

The next step is to enable the remote debugging feature for your project in JDeveloper.  To do this, go to your project's properties. Select the Run/Debug/Profile section, and click the Edit button for the "default" setting.  This will bring up a dialog where you can check the Remote Debugging option.

After this step you can then proceed to set breakpoints in your source, and then "Attach" to the running debug WLS instance. To attach, simply right click on the project (in the JDeveloper application navigator) and from the context menu, select "Start Remote Debugging".

Here's a screen shot of a JDeveloper debug session, debugging the WebCenter Page Service native API code, which I had blogged about in a previous post.

As you can see, being able to debug you Spaces based code in a running Spaces instance can be invaluable for tracking down those nasty bugs, and is very easy to set up.