If you want to debug business integration components in
a large application using the IBM® Integration
Designer integration
debugger, you should consider deploying the application to a remote IBM Process
Server machine
and debugging it remotely from IBM Integration
Designer.
This can significantly enhance performance and minimize potential
memory problems on your IBM Integration
Designer machine
Before you begin
In the remainder of this topic, it is assumed that your
local machine
is running
IBM Integration
Designer and
your
remote machine is running either standalone
IBM Business
Process Manager or
another instance of
IBM Integration
Designer.
If you are running
IBM Integration
Designer on
the remote machine, you must close it down before completing the following
steps so that you can access its
IBM Process
Server runtime
environment directly.
About this task
To prepare for remote debugging:
Procedure
- On your remote machine, open a command window and navigate
to one of the following directories (where installDir is the
installation path of standalone IBM Business
Process Manager or IBM Integration
Designer):
- On standalone IBM Business
Process Manager (where profileName is
the name of the profile that you want to use for the server): installDir/profiles/profileName/bin
- On IBM Integration
Designer: installDir/pf/wps/bin
- Assuming that server1 is the name of your remote IBM Business
Process Manager server,
run the command startServer server1 on Windows or ./startServer.sh
server1 on Linux.
- When the server has finished starting, open a browser window
and load the URL for the IBM Business
Process Manager administrative
console on the remote machine; for example, http://localhost:9060/ibm/console or http://remote_host_name:9060/ibm/console.
- In the User ID and Password fields
of the administrative console Login page, specify your user ID and
password and then click Log in.
- Ensure that the server starts up in debug mode by completing
the following steps:
- In the left frame of the administrative console, expand Servers and
then click the Application Servers link. The
Application Servers page opens in the right frame.
- In the Application Servers page, click the server1 link.
The server1 page opens.
- Scroll down to the Additional Properties section and
click the Debugging Service link. The Debugging
Service page opens.
- Ensure that the Enable service at server
startup check box is selected.
- In the JVM debug port field,
type a port number of your choice. For example, 7777.
(On Linux, the value must be greater than 1024.)
- In the JVM debug arguments field,
specify all of the following arguments (including the -Xj9 argument);
however, for the address argument, replace 7777 with whatever
port number you specified in the JVM debug port field: -Dcom.ibm.ws.classloader.j9enabled=true
-Xj9 -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=7777
- Click Apply to save the changes
so that they are picked up the next time the server is started.
- Click the Save link to save the
changes.
- Disable the transaction timeout values by completing the
following steps:
- In the left frame of the administrative console, click
the Application Servers link. The Application
Servers page opens in the right frame.
- In the right frame, click the server1 link.
The server1 page opens.
- Scroll down to the Container Settings section and expand Container
Services, then click the Transaction Service link.
The Transaction Service page opens.
- In the Total transaction lifetime timeout field,
type 0 to indicate that there should be no
timeout.
- In the Client inactivity timeout field,
type 0 to indicate that there should be no
timeout.
- Click Apply.
- Click the Save link to save the
changes.
- For multiprocessor systems, you should know that other
transaction limits may impact performance. Any transaction limit with
a nonzero value can cause a running component instance to time out
if the debugging time exceeds the allocated resources. If you experience
timeout problems in your distributed applications, disable the ORB
timeout values by completing the following steps:
- In the left frame of the administrative console, click
the Application Servers link. The Application
Servers page opens in the right frame.
- In the right frame, click the server1 link.
The server1 page opens.
- Scroll down to the Container Settings section and expand Container
Services, then click the ORB Service link.
The ORB Service page opens.
- In the Request timeout field,
type 0.
- In the Locate request timeout field,
type 0.
- Click Apply.
- Click the Save link and then
click the Save button to save the changes.
- At the top of the administrative console, click the Logout link
to log out of the administrative console.
- On your local IBM Integration
Designer machine,
complete the following steps:
- Set the integration debugger timeout values by following
the instructions in the debugger topic "Changing timeout values".
- Open the component that you want to debug in the component
editor, then right-click the first element in the component where
you can set a breakpoint and use the menu to add a breakpoint
to the element. This will prevent the component instance from immediately
running to completion when it is started.
- Create a server instance for your remote IBM Business
Process Manager by
following the instructions in the deployment topic "Creating a server in the test environment".
- In the Servers view, ensure that the status of your
new server is Started. (If it is not started,
then start or restart IBM Business
Process Manager directly
on the remote machine.)
- In the Servers view, right-click your new server and
select Restart > Debug to restart your remote IBM Business
Process Manager in
debug mode.
- When you have finished restarting the server in Debug
mode, use the integration test client to both deploy your module to
the new server and create a running instance of a component for remote
debugging, much like you would for local debugging. This is described
in the debugger topic "Creating a component instance". (Alternatively,
you can manually deploy your module to the new server and then use
a different means of creating a running instance of a component for
debugging, such as a JSP.)