Debugging

When building solutions, unfortunately they don't always work first time.

Debugging with Inspector

One of the core components of IBPM PD is the Inspector. By using the Inspector you can demonstrate playbacks of the solution in real-time. It is Inspector that provides a lot of the iterative nature of IBPM value. Inspector allows the process developer to run instance of the process on the Process Center Server.

There are a number of ways to start a process for testing. On the BPD diagram, there is a run button at the top right:

This will start a run of the process and prompt you to switch perspectives to that of the Inspector tool:

Within the Inspector perspective of IBPM PD, there are many parts.

In the top left we have the list of process instances. These can be filtered by instance name or by process status. The instance name is a dynamic filter and can be extremely useful if there are many entries in the list. Entering a prefix or part of the name can dramatically reduce the number of items to be seen.

The columns in this area are:

|| |Column Name|Description| |Instance Name|The human readable name of the instance of the process| |Snapshot|The snap shot associated with the process| |Process|The name of the BPD| |Status|The status of the process. Options are:

            • | |Due Date|The date/time at which the process is due| |Instance Id|The IBPM unique instance ID for this instance of the process|

The area to the right of the process instances changes depending on which process instance is selected.

It describes the tasks/steps within the process. The columns in this area are:

|| |Column Name|Description| |Status|The current status of the task. States are:

  • | |Owner|The owner of the task.| |Subject|The name of the task within the process.| |Priority|The priority of the task. Choices are:

  • | |Due Date|When this task is due.| |Task Id|The unique ID of this task.|

Not all BPD activities list/show up in this area. The ones that don't include:

At the top right of the Inspector are a series of control buttons:

The meaning of the buttons change depending on what is selected.

|| ||Suspends the process. The status of the process changes to suspended.| ||Resumes the process. If the process has previously been suspended, this button resumes the process.| ||Terminates the process. The process is terminated. The status of the processes changes to Terminated.| ||Deletes the data associated with the process.| ||Refreshes inspector with the updated knowledge of the environment from the runtime.| ||Runs the selected task.| ||Debugs the selected task.|

If the Task includes a Coach, a browser window will appear in which the details of the coach will be shown and the user will be allowed to interact with the process. When the coach is completed, the process will continue to the next task.

If there is a task waiting for attention, it will show with a yellowed background:

We can set breakpoints in activities in the Inspector view. By right-clicking on an Activity, we bring up the context menu and in that menu, there is a Breakpoint entry. Switching on the Breakpoint results in a breakpoint icon (a bug icon) appearing in the lower left of the activity.

Here we see an inspector view and a breakpoint about to be added.

After having added the Breakpoint, the Activity shows the debug icon:

When a process is executed under the inspector and allowed to run freely, execution will stop at the next breakpoint encountered. We also have the ability to dynamically control whether or not a breakpoint is honored (causes the interruption of the process). Again from the context menu, we can select Breakpoint Condition after a Breakpoint has been enabled. Selecting this entry produces a dialog window into which a JavaScript expression can be entered. The expression must result in a true or false outcome. When the breakpoint is encountered during execution, the expression is evaluated. The breakpoint is ignored if the expression evaluates to false.

The Inspector can also show us where the tokens are within our process.

In the diagram view, the tokens are shown are red colored markers with a number beside them. In the Execution State area, we again see these markers along with the name of the step/activity against which the token is blocked or waiting.

In addition, we can see the values of any currently set variables.

By clicking on a variable name, its current string representation/value is shown in the lower portion of the variables window.

A JavaScript execution evaluator is also provided that allows the user to enter a JavaScript expression that is executed within the Process Server runtime. This can be used to print values of variables or execute small snippets of JavaScript during testing. After entering (or copy/pasting) the JavaScript to execute, the run button can be pressed and the JavaScript will execute.

When launching a task from the lists of tasks, we are prompted with a selection of users eligible to work upon that task. PD has the ability to remember the password for users to save us from having to enter it. If we miss-type the password or the password changes, we must tell PD to forget about its remembrance of the password. This can be achieved through the Preferences window:

Debugging the environment

The environment in which IBPM executes causes logs to be written. Knowing where these logs exist and what their contents are is vital if lower level debugging is required. The logs for the server are written to the standard WAS consoles. These will exist in <profile>/logs. Specifically, the following relative files are useful:


Browser tabs and Process Inspector

When using Process Inspector to examine coaches, it has been found that if the browser is FireFox, then a new tab is opened for each coach displayed. This is not necessarily a good thing as the result is a set of old browser tabs that simply remain around after use that add nothing but clutter to the overall view of the browser.

Fortunately, there is an elegant solution. The FireFox browser supports "plugins" and one-such plugin is called "Tab Mix Plus". The web site for this plugin is:

http://tmp.garyr.net/help/

while the FireFox plugin itself can be found at:

https://addons.mozilla.org/en-US/firefox/addon/1122/

Once installed, a new menu is available in the browser Tools pull-down. This menu is called "Tab Mix Plus Options..."

Refresh

From the tab window that appears, in the Links tab, an option called "Open links from other applications in:" can be set. Settings this to "Current tab" results in the browser tab being reused by Process Inspector for each coach shown which is more what we want to happen.

Logging

IBPM makes heavy use of JavaScript to describe logic that should be executed at runtime. Unfortunately, there is currently no source level debugger for this language available in IBPM. Because of this, it can be difficult to diagnose certain kinds of problems. One solution to this is to insert instrumentation code into the JavaScript. When reached, this code can log information externally to IBPM to allow the developer to see what is going on.

In the IBPM environment, a JavaScript variable called log is always in scope. This variable is an instance of a class which includes methods called:


Each of these functions take a string parameter. When reached, the string is appended into a log file called SystemOut in the directory <profile>/server1/logs.

For example, coding the following in JavaScript

log.error("Hello World");

results in the following being appended to the log file:

[6/18/11 20:14:36:398 CDT] 00000079 wle_javascrip E Hello World

A tail tool such as the popular BareTail or LogExpert can be used to follow log files.

One interesting technique for debugging processes is to place log statements in the pre or post assignments. This can be achieved by defining a junk variable (I called mine debug1) and then placing a pre or post assignment as follows:

What we are saying here is that we are assigning the junk variable the outcome of the log() function. The log function logs information and we ignore any result it may have returned.

Log files can grow pretty quickly. If a problem is re-creatable, it is suggested that the old logs files be deleted or copied away before re-running a test. The log files that can be cleaned include:

Tracing Web Service SOAP traffic

Web Services requests are SOAP over HTTP. On occasion, one may want to examine the SOAP data traveling over the network. A useful tool to achieve this is TCPMon from Apache:

http://ws.apache.org/commons/tcpmon/index.html

A possible alternative to TCPMon is the tool called Fiddler. (see: http://www.fiddler2.com).

Working with IBM Defect Support

If a suspected defect is found within the product, IBM wants to hear about this so it can fix it. The way this is done is to raise a PMR (a defect report). When raising a defect, it is best to provide as much detailed information as possible. Some suggested practices for capturing the information needed to resolve the issue include:

Shutdown the servers and delete all the log files in the <profile>/logs/server1 and <profile>/logs/ffdc directories. Recreate the problem and then ZIP up all the data contained within these two folders.

Raising defects with IBM

If a problem is believed to be a defect with IBPM itself, a PMR (and IBM problem report) should be raised. IBM defect support has a "must gather" set of logs that they require when submitting a report. The details and instructions for these can be found here:

http://www.ibm.com/support/docview.wss?uid=swg21440086

Page 5

No Comments
Back to top