Troubleshooting

IBM Integration Designer provides numerous tools to help you troubleshoot problems in applications, such as the integration debugger and a new Server Logs view that enables you to work with cross-component tracing and server consoles and logs. Specialized tools are also provided that enable you to import IBM WebSphere Business Modeler problem determination archives and troubleshoot problems that occurred when business process models were deployed from IBM WebSphere Business Modeler to a managed deployment environment.


Fixing compilation errors in integration projects

Refactoring artifacts in Process Designer sometimes causes compilation errors to appear in IBM Integration Designer. These errors occur after you refresh Integration Designer from the repository.

This topic applies only to IBM Business Process Manager Advanced.

If a process application or toolkit contains content that was authored in both Process Designer and Integration Designer, you must take extra caution to avoid unintended or unnoticed breakages.

The set of artifacts visible to a business analyst who is working in Process Designer is different from the set seen by the integration developer who is working in Integration Designer. For example, a mediation flow that is authored in Integration Designer is not seen by the business analyst. Conversely, an undercover agent that is authored in Process Designer is not seen by the integration developer. However, some artifacts are visible to both roles, such as data types, business process definitions, and advanced integration services.

There are dependencies between process applications and toolkits that enable artifact visibility across project dependencies. For example, a project dependency in Integration Designer must be resolved in the scope of the process application or toolkit. If a module in a process application depends on a library, the library must be in the same process application as the module or in a dependent toolkit. Integration developers and business analysts can change these artifacts or dependencies, which causes problems with artifacts that are seen only in one component.

To ensure that an entire process application or toolkit is error-free, open and analyze it in both editors. Using a new workspace in Integration Designer, select all modules and libraries when you open the process application or toolkit. After the build is complete, you can see errors in the Problems view. The examples show two typical problems and suggest ways to resolve them.


Example 1

If you move a dependent business object in Process Designer, you might need to make changes in Integration Designer. Let's say you move an artifact in Process Designer from a process application into a toolkit or another process application. If the moved artifact or any of its dependencies belong to advanced contents ( an implemented advanced integration service or a business object referenced by SCA modules or libraries in the process application), the SCA modules or libraries might fail to build. In this case, you need to make the appropriate changes to ensure the dependent business object is still accessible. You also need to change related unique resource identifiers in the maps that depend on the moved business object.


Example 2

In Process Designer, if you rename a business object or change the type name or namespace name in the Advanced Properties page of the Business Objects editor, Integration Designer artifacts that reference that business object are not synchronized. After you synchronize the process application with the repository from Integration Designer, broken references display.

If you find broken references of this kind, you can correct the situation by manually updating the references in Integration Designer. If there are a few errors, this action is the best choice. If you have many errors, you can revert back to the original name used in Process Designer. You can also revert back to the original business object XML properties. You can modify the referencing artifacts as well. When you refresh the process application in Integration Designer from the repository, the broken references are corrected.


More information

One way to avoid this repair work is to follow the advice provided in the developerWorks article Best practices when using IBM Integration Designer and Process Designer together.


Error prevention as part of application design

Including error prevention practices as part of your application design means implementing specific design techniques and using the capabilities of the product to help prevent system and application errors.

A strong system of governance, complete with architectural and design guidelines and appropriate standards combined with reviews and checkpoints are essential to building the right kind of application.

Error prevention practices as part of application design include the following:

  • Implementing design considerations for exceptions and faults
  • Implementing an error handling strategy that uses existing IBM Integration Designer error handling capabilities and tools
  • Creating connectivity groups and using module application design techniques


Connectivity groups

A connectivity group represents a specific pattern of behavior found in an SCA module.

Create connectivity groups to represent the possible request sources for the system.

In a connectivity group you:

  • Put all the logic to get the inbound data into one module

    This is also true for outbound data when it is going to an external system or legacy system

  • Put all the logic to connect and transform the data into one module

    All the other modules can now use a standard set of interfaces and not have to worry about extra transformations.

The connectivity group will not contain stateful component types like long-running business processes and Business State Machines. These connectivity groups provide encapsulation and isolation of the specific endpoint's integration requirements. Commonly, mediation modules are used for this purpose as they represent convenient ways to implement "infrastructure" related tasks.

The concept of connectivity groups also provide a convenient way to quiesce the system in case there is a need for recovery. Because the connectivity group module is stateless, the module can be temporarily stopped thus cutting off the inbound flow of new events while the system finishes processing the events it has.

To stop the flow of inbound events, then the connectivity modules should not support inbound and outbound in the same module (even though the same EIS system may have both inbound and outbound). If inbound and outbound support are in the same module, then the outbound is turned off with the inbound. This may cause internal work to stop from completing. Consider separating inbound and outbound in this case.

When the system is recovered and able to process new work, these modules can be restarted.

The module that is outlined in the following screen capture is considered part of a connectivity group.

Connectivity groups can be used for input from an external source or an existing system such as SAP or CICS . Or for new work from a web browser-based clients.


Application design considerations for exceptions and faults

You need to consider your application design so that it can take advantage of the error handling and fault processing capabilities in IBM Integration Designer.

In order to create a comprehensive error handling strategy, solution architects need to understand howProcess Server represents declared and undeclared exceptions.

The SCA programming model provides two types of exceptions:

  • Service Business Exceptions

    Service Business Exceptions are checked exceptions declared in a business method's function signature (WSDL faults or Java™ throws). Service Business Exceptions identify error conditions that are anticipated by the application or service. These exceptions are sometimes referred to as "checked exceptions"

    An example is an InvalidSymbolException for a stock quote service. Such exceptions are wrapped by ServiceBusinessException and passed back to the client.

  • Service Runtime Exceptions

    Also known as "system exceptions" service runtime exceptions are not declared in the method signature. In general, they represent error conditions that are not anticipated by the application, such as a NullPointerException in a Java Component.

    These exceptions are wrapped by ServiceRuntimeException and passed back to the client, which can interrogate the ServiceRuntimeException to determine the cause.

    When working at the SCA level these exceptions are sometimes referred to as faults. However, when using Java code they are usually referred to as exceptions.

    When a ServiceRuntimeException is thrown from a component, the current transaction will be rolled back.


Service Business Exception handling

Service Business Exceptions represent known and declared exceptions anticipated by the application or service.

Service Business Exceptions are defined on the service interface.

Component developers should take care to declare the possible exceptions that may be thrown, so the consuming service can handle them. For example, a business fault to a banking application would include "Invalid Account Number", or "Insufficient Funds" as business exceptions. So the application that calls the service needs to include logic to handle a situation where they have passed in an invalid account number, or where they tried to transfer $100 but there was only $50 in the account. These are the types of business errors that a calling application is designed to handle. The IBM Integration Designer business exceptions are returned to the client to catch and handle appropriately.

When handling business service exceptions, service consumers should implement the client such that it will perform one of the following actions for a declared business exception:

  1. Catch the exception and create the appropriate Service Business Exception for the calling application.

    This could mean including the original exception in the new exception (wrapping it). This is most often done when the calling module does not have the same Business Exceptions as the service that it is calling. Here is an example of the flow catching an exception and creating a Service Business Exception for the calling application:

    1. Module A has SBE "MoneyTransferFailed"
    2. Module B has SBE "InsufficientFunds"
    3. Module A calls Module B and gets "InsufficientFunds" exception
    4. Module A must create a new exception "MoneyTransferFailed", which may have a place where a string defining the original error of insufficient funds can be included.

  2. Catch the exception and perform alternate logic.


Service Runtime Exception handling

Service Runtime Exceptions are undeclared exceptions. In general, they represent error conditions that are not anticipated by the application.

Service Runtime Exceptions are used to signal an unexpected condition in the runtime.

Component developers can handle Service Runtime Exceptions in the following ways:

  1. Catch them and perform some alternative logic.

    For example, if one partner is not able to service a request perhaps another one might.

  2. Catch the exception and "re-throw" it to your client.
  3. Remap the exception to a business exception.

    For example, a timeout for a partner may result in a business exception that indicates most of the request was processed but there was one piece of the request that was not completed and should be retried later or tried with different parameters.

If an exception is not caught, the exception is passed on to the component that called the current component. This call chain continues back to the original caller in the chain. For example, Module A calls Module B and Module B calls Module C and then Module C throws an exception, Module B might or might not catch the exception. If Module B does not catch the exception, then the exception travels back to Module A.

When a ServiceRuntimeException is thrown from a component, the current transaction will be rolled back. This type of exception processing is repeated for all components in the chain. For example, if a ServiceRuntimeException is thrown from Module C, that transaction will be marked for rollback. Then the exception is thrown to Module B, where if it is not caught and another transaction is present, that transaction also will be rolled back. Component developers can use quality of service (QoS) qualifiers to control whether invocations occur in the current transaction or a new transaction. So, if Module A calls Module B and Module B is part of a new transaction, then Module A can "catch" a ServiceRuntimeException from Module B and continue processing, without Module A's transaction rolling back.

Because runtime exceptions are not declared as part of the interface, component developers should attempt to resolve the exception and thus prevent a runtime exception from inadvertently being propagated to the client if the client is a user interface.

You should be aware the contents of the rolled back transaction can vary, depending on the nature of the transaction. For example, long-running BPEL processes can be segmented into many smaller transactions. Asynchronous request and response calls are broken out of a transaction automatically (otherwise the calling application might have to wait a long time for the response).

In instances where a transaction is broken into multiple asynchronous calls (as opposed to one large transaction), the initial work for the transaction would rollback at the occurrence of a ServiceRuntimeException. However, the response from the asynchronous call is sent from a different transaction, and because the response from the asynchronous call would have no place to go, an event is created in the Failed Event Manager (FEM).

The following list is of 4 current subclasses of ServiceRuntimeException:

  1. ServiceExpirationRuntimeException

    This exception is used to indicate that an asynchronous SCA message has expired. Expiration times can be set using the RequestExpiration qualifier on a service reference.

  2. ServiceTimeoutRuntimeException

    This exception is used to indicate the response to an asynchronous request was not received within the configured period of time. Expiration times can be set using the ResponseExpiration qualifier on a service reference.

  3. ServiceUnavailableException

    This exception is used to indicate there was an exception thrown while invoking an external service via an import.

  4. ServiceUnwiredReferenceRuntimeException

    This exception is used to indicate the service reference on the component is not wired correctly.


Resolve communication problems with remote servers

If you are having problems communicating with a remote server, such as problems in publishing to the remote server or obtaining the status of the server, it is possible the server settings or system settings on the remote machine are not correctly set up.

There are numerous scenarios where you can encounter problems in communicating with remote servers. In many of these scenarios, your first indication of trouble will be when one of several Publishing failed messages is issued. Also, if you are attempting to run a component test on an application that resides on a remote machine and the integration test client fails to communicate with the remote server on the machine, you may see the following message (where application_name is the name of the application):

Start the integration test client has encountered a problem. Cannot start application application_name.

In many situations, communication problems with remote servers are caused by incorrect server settings or system settings on the remote machine. To ensure these settings are correct, complete the steps in the following procedure.

  1. In the file system of the remote machine, open the file serverindex.xml that is located in the installation path of your server profile. The default installation path for a server profile is:

    C:\IBM\BPM\v7.5\profiles\profile_name\config\cells\cell_name\nodes\node_name\serverindex.xml

    For example:

    C:\IBM\BPM\v7.5\profiles\AppSrv01\config\cells\localhostNode01Cell\nodes\nlNode01\serverindex.xml

  2. In the serverindex.xml file, ensure the hostName parameter is not set to localhost (which can cause problems in publishing and reporting status for the server). If it is set to localhost, change the value of the hostName parameter to the actual host name. For example:
    <?xml version="1.0" encoding="UTF-8"?>
    <serverindex:ServerIndex xmi:version="2.0"
     xmlns:xmi="http://www.omg.org/XMI"
     xmlns:serverindex="http://www.ibm.com/websphere/appserver/schemas/5.0/serverindex.xmi"
     xmi:id="ServerIndex_1"
     hostName="MyHostName">
    <serverEntries ...

    You can change the value of the hostName parameter to the actual host name at the command line level or console. To change the value of hostName, see Change the node host names.

    Save changes and restart the remote server.

  3. If you continue to experience problems in communicating with the remote server:

    1. In the file system of the local machine where IBM Integration Designer is installed, open the file hosts that is located in the following path:

      C:\WINDOWS\system32\drivers\etc

    2. In the hosts file, ensure there is an entry to map the IP address of the remote server to its host name. Any entry that maps an IP address to a host name must be specified on a separate line in the file. The IP address must be placed in the first column followed by at least one space and then the corresponding host name. For example:

      9.186.64.134 MyRemoteServerHostName

      Save changes.

    3. Republish to the remote server. (If you are working with the integration test client, you can click the Run icon to republish.)


Performance tuning for IBM Integration Designer

If an application fails to run or cycles for a long time without completing, those situations might be caused by insufficient system memory.

IBM Integration Designer can be used in a number of configurations. The information in this topic focuses on the use of Integration Designer with the test environment and with Process Server. Although the context is the tools environment, the tuning solutions also involve adjustments to the test environment and Process Server using its administrative console. The issues described here could also occur if you are using Integration Designer with IBM Process Center and, optionally, with IBM Business Monitor.

There are two typical symptoms of performance problems:

  • An out of memory exception occurs, and the server process stops.
  • Performance degrades significantly because either physical memory is overcommitted and swapping occurs, or an excessive amount of time is being spent in garbage collection.

Out of memory problems are most likely to arise on a 32 bit JVM and a 32 bit operating systems, where the amount of accessible memory is limited. For 64 bit operating systems, use a 64 bit JVM. A 64 bit JVM supports much larger heap sizes than a 32 bit JVM; the practical limit is determined by the amount of physical memory available on the system. The throughput and memory efficiency of 64 bit JVMs is very similar to that of 32 bit JVMs in BPM, so there is usually no compelling reason to use a 32 bit JVM on a 64 bit operating system.


Identifying problems with heap size

When IBM Integration Designer is responding slowly to mouse clicks or keyboard strokes, you can use the Heap Status widget or generate the verbosegc.log file to see JVM heap usage.

A check for Java heap size issues would be to turn on the Heap Status widget in Integration Designer by selecting Window > Preferences > General > Show heap status. This widget allows you to see how much of the heap is being used and to trigger a garbage collection.

The verbosegc.log is also useful for analyzing memory usage. To generate the verbosegc.log file for Integration Designer:

  1. Use a text editor, from the Integration Designer installation directory, open the eclipse.ini file.

  2. Add the following line:

      -verbosegc -Xverbosegclog:location for the generated gclog file

    If you do not specify an exact location, the file will be created in the installation directory.

  3. To analyze the verbosegc.log file, download IBM Pattern Modeling and Analysis Tool for Java Garbage Collector (PMAT) from the following URL:http://www.alphaworks.ibm.com/tech/pmat.
  4. To run PMAT, type the following command in a command prompt:

      java -Xmx500m -jar ga39.jar

    .

The JVM parameters such as -Xmx are found in the eclipse.ini file in the IID_HOME directory.


Analyzing system memory use

When heap size is increased, the memory available for the rest of the process is decreased. The remaining system memory is used by native code, the JVM loading classes, the JVM itself, and so on. To analyze system memory utilization, use the appropriate system memory tool ( vmstat for Linux or Unix systems, and Performance Monitor or Task Manager for Windows).


Addressing problems from swapping

If you discover that performance is severely degraded because swapping is occurring, try these solutions:

  • Ensure there is enough physical memory to support BPM and all other running processes. Use the system memory tools to do this. Note that some 32 bit operating systems can only use a certain amount of physical memory ( 3 GB for Windows).
  • Stop all processes that are not required ( browsers, tools, office applications).

  • Use a remote DB2 system, and stop the DB2 processes on the local system.

  • For authoring, use a remote test environment or Process Center.


Addressing problems related to garbage collection

This kind of problem can be indicated by either of two symptoms:

  • An out of memory exception occurred with frequent garbage collection activity immediately before the out of memory exception, which results in very little free space in the Java heap.
  • Performance is severely degraded without swapping occurring, but the system is spending an excessive amount of time doing garbage collection.

You can address these symptoms by increasing the Java heap size (-Xmx) or tuning the JVM heap. The Java heap must be large enough to contain all required Java objects. However, on 32 bit systems ensure that it is not so large the amount of native memory becomes a bottleneck. You need to experiment to determine these limits.

For information about tuning the JVM heap, see Tuning the IBM virtual machine for Java in the WAS information center. Here is a summary of key tuning points. The parameters referenced below apply to IBM JVMs. HotSpot JVMs, used on Solaris systems, generally have similar options but the syntax is different. Consult the JVM documentation for details.

  1. Generate the verbosegc.log file.

  2. Tune the Java heap size parameters.
  3. Experiment with different garbage collection policies. These policies are set by using the -Xgcpolicy JVM option. There are two choices: optthruput and gencon. The gcpolicy choice can influence the amount of memory used, depending on the particular scenario. If using the gencon gc policy, tune the nursery size parameters (-Xmnsize, -Xmnsinitial size, and -Xmnxmaximum size. These parameters are found in the eclipse.ini file in the IID_HOME directory.


Change heap size settings

Sometimes publishing in IBM Integration Designer takes a long time, and sometimes the server suddenly stops. If that happens, check the server log for an out of memory error. By default, the Integration Designer test environment is configured for unit testing and it might run out of memory with large workloads. To resolve this issue, increase the heap size.

  1. In the left panel of the administrative console, select Servers > Server Types > WebSphere application servers.

  2. Select the server that requires more memory.

  3. Under Java and Process Management, select Process Definition.

  4. In the Additional Properties section, select Java Virtual Machine.
  5. There are two fields that are related to heap size, initial heap size and maximum heap size. By default, if the initial heap size is not specified, it is 256 KB. For a 32-bit system, the JVM heap size is limited to 1.5 GB on Microsoft Windows and 2.5 GB on AIX.

There are no definite rules for the optimal heap size, because the required size depends on the number and size of the modules deployed on the server and on whether the server is used as development server or production server. However, here is a technique that has worked for some administrators. Increase the maximum value to a level that is large enough for the server not to run out of memory and collect verbosegc data. The verbosegc data shows the typical or maximum amount of live data in the heap. Set the maximum heap size so the server remains approximately 50% empty during a steady state. For example, if the verbosegc data reveals there is typically about 500MB of data, set the maximum heap size to 1024MB.

You might not be able to use the maximum setting, because that setting might cause you to run out of memory on your system before the JVM limit is reached. That is the case if the symptom is an out of memory exception, and there is not a garbage collection taking place immediately before the out of memory exception. In this case, the issue is the native memory for a resource (such as threads, sockets, file handles, JIT compiled code) has been exhausted. In this case, decrease the maximum Java heap size (-Xmx) to allow more room for native memory in the JVM address space. This issue typically occurs only on 32 bit operating systems.


Processing Java files in Integration Designer

This advice addresses situations where you need to import a very large number of Java files into Integration Designer. In that case, large number of Java files might cause build performance issues. There are four major tasks that Integration Designer performs when you import Java files into the workspace for the first time:

  1. Import the Java files into the workspace.
  2. Compiling the Java files.
  3. JDT indexing to gather basic information from the Java files for validation and search purposes.
  4. Integration Designer indexing and validation to identify Java sources that use the business object API for better validation and refactoring.

These four steps can take a large amount of time in your build process if you have hundreds or thousands of Java files in your processes.

Here is one step you can take to improve performance in this situation. Bundle Java classes into Java Archive (JAR) files and reference the JAR files instead of individual Java files. By compiling all the Java source files into a JAR file, you save Java compilation time (which is actually quite significant) and you save time on the Java indexing and validation as well. To support source-level debugging, bundle the Java source files together with the Java classes in the same JAR.

This technique should only be used if the Java code is not likely to be changed, or will be changed infrequently. To create the JAR file, import the classes and then use the JAR export wizard.

See "Using binary JAR files with Integration Developer and Process Server" in the related links for more information about this subject.


Use the Server Logs view for problem determination

In IBM Integration Designer, the Server Logs view is used to display the contents of server consoles and log files. It automatically displays console output for each server that is started, but you can also manually load and display the contents of the console and log files for any server. If you enable cross-component tracing, the Server Logs view will also display invocation records that can contain the invocation data that passed between components. The Server Logs view provides several advantages over the traditional Console view, such as the ability to filter records and display invocation records in hierarchical format.


Overview of cross-component tracing

By default, the Server Logs view displays standard server console and log records. However, if you enable cross-component tracing, the Server Logs view will also display invocation records that can contain the invocation data that was passed between the components in your application. The invocation records are displayed in hierarchical format in the Server Logs view, which enables you to more easily understand the relationships that exist between the records. When you enable cross-component tracing, the Server Logs view becomes an even more powerful tool for problem determination.

When you enable cross-component tracing on a server, invocation records are generated during Service Component Architecture (SCA) processing of modules and components. The invocation records include information about any errors or events that had occurred during processing, such as runtime exceptions. If you choose to enable cross-component tracing with the data snapshot feature, the generated invocation records will also contain the invocation input and output data that was passed between the components during processing.

You can enable or disable cross-component tracing for a server from either the Server Logs view or the server administrative console. If you enable cross-component tracing from the Server Logs view, the tracing is only enabled for the duration of the server session. When you next stop or restart the server, the cross-component trace state will automatically be disabled by default. By comparison, if you enable cross-component tracing for a server from the server administrative console, the cross-component tracing will remain enabled for all sessions of the server until you choose to disable it again.

When you enable or disable cross-component tracing, you can choose from one of the following options:

Disabled

This option disables cross-component tracing. No invocation records are generated in the server console and logs.

Enabled

This option enables cross-component tracing. Invocation records are generated into both the server console and the System.Out and trace.log files, but the record properties do not include any invocation input and output data. The System.Out and trace.log files are located in the server log directory. For example: D:\Program Files\IBM\WID62\pf\wps\logs\server1

Enabled with Data Snapshot

This option enables cross-component tracing with the data snapshot feature. Invocation records are generated into both the server console and the System.Out and trace.log files, but the record properties do include invocation input and output data. This data is captured in input and output files under the logs\xct directory. For example: C:\Program Files\IBM\WID62\pf\wps\logs\xct


Server Logs view

The Server Logs view is used to display server console and log file records. Although the Server Logs view automatically displays console records for each server that is started, you can also manually load and display the server console and log file records for any server. When cross-component tracing is enabled, the Server Logs view will also display invocation records that can contain the invocation data that passed between components. The Server Logs view is the recommended tool for working with server console and log records. It provides several advantages over the traditional Console view, such as the ability to filter records, display invocation records in hierarchical format, and load invocation records directly into the integration test client.

In the Business Integration perspective, you can open the Server Logs view by simply clicking the Server Logs tab. (If the Server Logs tab is not visible, you can open the Server Logs view by selecting Window > Show View > Server Logs.) The Server Logs view is shown in the following figure:

As shown in the figure, there are three main areas of the Server Logs view:

  • 1 Welcome tab
  • 2 Server console and log tabs
  • 3 Toolbar

At the bottom of the Server Logs view, there is also a status area that returns messages relating to the server console and log records.

These three areas are described in the following sections.


Welcome tab

The Welcome tab is the home page of the Server Logs view. It provides an overview of the Server Logs view and introduces you to some of the key tasks that you can perform in the view, such as:

  • Loading the contents of server consoles or server logs into the Server Logs view
  • Filtering server console or server log records in the Server Logs view

  • Enable or disable cross-component tracing for servers
  • Loading invocation records into the integration test client


Server console and log tabs

The server console and log tabs display the records of server consoles and server logs that you have loaded into the Server Logs view.

The following four columns in the server console and log tabs provide detailed information about the records:

Type

Displays the types of the records, such as log messages, FFDC records, exception records, and invocation records.

Time

Displays the date and time the records were generated.

Thread ID

Displays the thread IDs of the records.

Contents

Displays the first line of the contents for the records.

You can also right-click any record and select Properties to open a Properties window that displays the time, thread ID and contents for the record. You can choose to view the contents in the default translated format (for easier reading and assimilation) or you can view the contents in the raw native format in which they were originally generated. Also, if you open the Properties window for an FFDC record or an invocation record, such as a Start, Fail, or End invocation record, the Properties window will contain an additional Data field that displays the invocation data that was passed between components.


Toolbar

The toolbar in the Server Logs view consists of several icons that are used to initiate numerous tasks. The toolbar icons and their associated tasks are described in the following table:

Icon Task
Loads the contents of server consoles or log files into the Server Logs view.
Filters the records that are displayed in the tabs of server consoles or log files. (Additional information about filtering is found in the "Record filtering" section below.)
Loads invocation records into the integration test client.
Expands nested invocation records that are currently collapsed.
Collapses nested invocation records that are currently expanded.
Pages up through records one page at a time.
Pages down through records one page at a time.
Skips directly to a specified page number.
Refreshes the records either manually or automatically.
Removes all of the records in a server console tab.
Toggles between enabling and disabling the automatic scrolling of records whenever a server console or log tab is refreshed and new records are appended to the bottom of the tab.
Displays a menu that enables you to accomplish the following tasks:

  • Enable or disable cross-component tracing.
  • Search for a string in the server console or log records.
  • Sort server console or log records by column in ascending or descending order.

  • Open the Welcome tab.


Record filtering

As described in the "Toolbar" section, you can click the Select Records to Display icon () to open and select menu items that filter the records in server console or log tabs.

By default, any invocation records are displayed in hierarchical format and have check boxes that enable you to select them for direct loading into the integration test client. Although you can choose to display records in a flattened format rather than a hierarchical format, the invocation records will not have check boxes and you will not be able to select them for direct loading into the integration test client.

The following table lists and describes the menu items for filtering records:

Menu Item Submenu Item (If Any) Description
All Record Types (Hierarchical) > with only Server State and Error Contents Filters the contents of the consoles and logs to display server state and error contents as well as SystemOut records. If cross-component trace was enabled, invocation records may have been generated and any records appearing within invocations are displayed in hierarchical format. All other records are displayed in flattened format.
  with only Server State, Error, and Warning Contents Filters the contents of the consoles and logs to display server state, error, and warning contents as well as SystemOut records. If cross-component trace was enabled, invocation records may have been generated and any records appearing within invocations are displayed in hierarchical format. All other records are displayed in flattened format.
  with All Contents Filters the contents of the consoles and logs to display all contents as well as SystemOut records. If cross-component trace was enabled, invocation records may have been generated and any records appearing within invocations are displayed in hierarchical format. All other records are displayed in flattened format.
All Record Types (Flattened) > with only Server State and Error Contents Filters the contents of the consoles and logs to display server state and error contents as well as SystemOut records. If cross-component trace was enabled, invocation records may have been generated. However, all records are displayed in flattened format.
  with only Server State, Error, and Warning Contents Filters the contents of the consoles and logs to display server state, error, and warning contents as well as SystemOut records. If cross-component trace was enabled, invocation records may have been generated. However, all records are displayed in flattened format.
  with All Contents Filters the contents of the consoles and logs to display all contents as well as SystemOut records. If cross-component trace was enabled, invocation records may have been generated. However, all records are displayed in flattened format.
Invocation Types > with only Server State and Error Contents If cross-component trace was enabled, invocation records may have been generated. This menu item filters the contents of the consoles and logs to display only those records that appear within invocations and displays the records in hierarchical format. Displays server state and error contents as well SystemOut records.
  with only Server State, Error, and Warning Contents If cross-component trace was enabled, invocation records may have been generated. This menu item filters the contents of the consoles and logs to display only those records that appear within invocations (including SystemOut records) and displays the records in hierarchical format. Displays server state, error, and warning contents as well SystemOut records.
  with All Contents If cross-component trace was enabled, invocation records may have been generated. This menu item filters the contents of the consoles and logs to display only those records that appear within invocations (including SystemOut records) and displays the records in hierarchical format. Displays all contents as well as SystemOut records.
Invocation Start Types   Filters the contents of the consoles and logs to display only Start records for an invocation, such as Start invoke, Start component, and Start import records.
Invocation End Types   Filters the contents of the consoles and logs to display only End records for an invocation, such as End invoke, End component, and End import records.
Invocation Failure Types   Filters the contents of the consoles and logs to display only Fail records for an invocation, such as Fail invoke, Fail component, and Fail import records.
Exception Types   Filters the contents of the consoles and logs to display only exception records.
FFDC Types   Filters the contents of the consoles and logs to display only first failure data capture (FFDC) records.


Getting started with the Server Logs view

In IBM Integration Designer, the Server Logs view is the designated tool for working with server console and log records. Typically, the process of using the Server Logs view for problem determination begins when you encounter problems when testing your application using the integration test client or another tool. In this end-to-end introduction to the Server Logs view, it is assumed that you are working with the test client when you encounter problems in your application.

In this introduction to problem determination using the Server Logs view, you complete the following high-level steps:

  1. Test your application in the test client and discover problems.

  2. Enable cross-component tracing on the server.
  3. Rerun the test in the test client.

  4. Use the Server Logs view to investigate the problems.
  5. Fix the problems.
  6. Rerun the test in the test client to ensure the problems are fixed.

  7. Disable cross-component tracing.

To get started with the Server Logs view:

  1. Test your application in the test client and discover problems:

    1. Open your application in the integration test client.

    2. In the Detailed Properties area, ensure the correct operation is selected, as shown in the figure below:

    3. In the value editor, specify some input data for the invocation.

    4. Click the Continue icon . Depending on the current deployment state of your application, the Deployment Location wizard may open, as shown in the figure below:

    5. If the Deployment Location wizard opens, ensure that a deployment location is selected in the Deployment location list and then click Finish.

    6. If security is enabled, a User Login window will open. In the window, specify the user ID and password that you selected when you installed IBM Integration Designer and then click OK.

    7. In the Events area of the test client, examine each of the events to determine the status of the invocation. In this application, an error was encountered during the invocation and the second Response event is flagged with a red exclamation mark.

      If the Response event that is flagged with the error symbol is selected in the Events area, the value editor may display the cause of the error.

      However, the test client cannot determine the cause of all possible errors. For example, if a module is invoked that is not part of the test configuration, the Server Logs view is the only place where you can view the interactions between the components in the module that have resulted in errors. For this reason, the Server Logs view is ultimately a more powerful problem determination tool than the test client.

    8. Leave the test client open. (If you need to close the test client, ensure that you save the test trace.)

  2. Enable cross-component tracing on the server:

    1. In the workbench, click the Server Logs tab and then click the tab that contains the console output of the server where you deployed your application.

      If the server console tab is not displayed in the Servers Logs view, click the down arrow icon beside the Load Server Console or Log icon , then select Load from Server Console > server_name from the menu, where server_name is the name of the server for the console to load. (You can use the same menu to load server log files from a server log directory or from anywhere in the file system.)

    2. In the Server Logs view, click the View Menu icon . A menu opens.

    3. From the Cross-Component Trace State menu, select the Enabled with Data Snapshot menu item. This will cause invocation records to be generated in the server console and logs and the record properties will include invocation data.

    4. Optionally, click the Clear Server Console icon . All records are removed from the server console tab.

  3. Rerun the test in the test client:

    1. If you closed the test client, open it again by loading the test trace.

    2. In the Events area, right-click the top-level Invoke event and select Rerun. The test client displays the same information that was displayed in the initial test. However, as a result of enabling cross-component tracing, invocation records have now been generated into the server console tab of the Server Logs view. And some of the invocation records may be flagged with red Fail symbols to indicate errors.

  4. Use the Server Logs view to investigate any problems:

    1. In the Events area of the test client, select the nested Invoke event that was generated by rerunning the test.

    2. Right-click the selected Invoke event and select Show in Server Logs View. The Server Logs view displays the invocation records that are associated with the invocation events in the test client.

    3. In the Type column of the Server Logs view, ensure the top-level Start invoke record is highlighted.

    4. In the Server Logs view tool bar, click the Expand icon . All of the nested invocation records are expanded.

      In the figure, you could work with the records by opening the Properties window for the Fail Invoke record to gain additional insight into the Fail component invocation record that is displayed above it.

      You can also view the Contents column where the contents of each record are displayed, as shown in the figure below:

    5. Right-click a Start record (such as a Start Invoke, start Component, or Start Import record) and then select Properties. The Properties window opens.

      In the Properties window box, you can view the contents in either the default translated format or in the raw native format in which the record was originally generated. Also, when cross-component tracing with data capture is enabled and you open the Properties window for a Start record, a Data area is displayed that contains invocation data for the record.

    6. In the Server Logs view, click the Select Records to Display icon . A menu opens. By default, the All Record Types (Hierarchical) > with only Server State and Error Contents menu item is selected.

    7. From the menu, select the Invocation Failure Types menu item. The server console tab is filtered to display only invocation failure records.

      You can use the other menu items to filter the server console records (or log records) according to other criteria.

  5. Use the information that you obtain from the server records to determine what needs to be done to fix the problems. This is an easier task than in the past because invocation records are now interspersed with exception records in the Server Logs view, which makes it easy to identify the components that failed and caused the exceptions to occur.
  6. Rerun the test in the test client to ensure the problems are fixed.

  7. Disable cross-component tracing on the server:

    1. Click the Server Logs tab and then click the tab that contains the console output of the server where you deployed your application.

    2. In the Server Logs view, click the View Menu icon . A menu opens.

    3. From the Cross-Component Trace State menu, select the Disabled menu item.


Work with server console and log records in the Server Logs view

The Server Logs view provides numerous tools that enable you to effectively work with server console and log records.


Set preferences for the Server Logs view

By default, the Server Logs view is used to display server console records rather than the Console view. Whenever a server is started from the Servers view or from the integration test client, the contents of the server console are automatically opened in a new tab in the Server Logs view and the tab is automatically selected and displayed. However, you can set preferences to control these behaviors.

To set preferences for the Server Logs view:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. Expand Business Integration and select Server Logs. The Server Logs preferences page opens.
  3. To control whether server console records are automatically opened in a new tab in the Server Logs view whenever a server is started, complete one of the following steps:

    • If you want server console records to be automatically opened in a new tab in the Server Logs view whenever a server is started, ensure the Use the Server Logs view to display server console output check box is selected. (Note that selecting this check box will not automatically cause the new tab in the Server Logs view to be automatically selected and displayed whenever a server is started. This capability is controlled by the When a server is started, open a server console page in the Server Logs view check box described below.)

    • If you do not want server console records to be automatically opened in a new tab in the Server Logs view whenever a server is started, clear the Use the Server Logs view to display server console output check box. (If necessary, you can manually open the server console records in a tab in the Server Logs view by following the instructions in the topic "Loading server console or log records.")

  4. To control whether the new tab in the Server Logs view is automatically selected and displayed when a server is started, complete one of the following steps:

    • To create automatically select and display the new tab in the Server Logs view whenever a server is started, ensure the When a server is started, open a server console page in the Server Logs view check box is selected.

    • If you do not want to automatically select and display the new tab in the Server Logs view whenever a server is started, clear the When a server is started, open a server console page in the Server Logs view check box. (If necessary, you can manually select and display the new tab in the Server Logs view by simply clicking both the Server Logs tab and the tab that contains the server console records.)

  5. Click OK.


Opening the Server Logs view

By default, the Server Logs view is always open in the workbench. However, if the Server Logs view is no longer displayed, you can easily open it again.

To open the Server Logs view:

  1. Switch to the Business Integration perspective (if it is not already open).

  2. From the Window menu, select Show View > Server Logs. The Server Logs view opens.


Enable or disable cross-component tracing

In the Server Logs view (or in the administrative console of a server), you can enable or disable cross-component tracing on a server to control whether invocation records and associated invocation input and output data are generated and displayed as part of the server console and log records.

Before you read the following instructions on enabling or disabling cross-component tracing, you should read the conceptual information on cross-component tracing in the topic "Overview of cross-component tracing."

The current cross-component trace state is always displayed in the lower right corner of the Server Logs view. You can enable or disable cross-component tracing for a server from either the Server Logs view or the server administrative console. If you enable cross-component tracing from the Server Logs view, the tracing is only enabled for the duration of the server session. When you next stop or restart the server, the cross-component trace state will automatically be disabled again by default. By comparison, if use the Configuration option to enable cross-component tracing for a server from the server administrative console, the cross-component tracing will remain enabled for all sessions of the server until you choose to disable it again.

To enable or disable cross-component tracing:

  1. To enable or disable cross-component tracing from the Server Logs view:

    1. Click the Server Logs tab to open the Server Logs view.

    2. In the Server Logs view, ensure that at least one server console or server log tab is open and selected for the running server where you want to enable or disable cross-component tracing. (By default, the contents of a server console are automatically loaded into a new tab in the Server Logs view whenever a server is started. However, you can also manually load the contents of a server console or server log files into a tab by following the instructions in the topic "Loading server console or log files.")

    3. Click the View Menu icon . A menu opens.

    4. From the Cross-Component Trace State menu, select one of the following menu items: Disabled, Enabled, or Enabled with Data Snapshot (recommended). The lower right corner of the Server Logs view displays the new cross-component trace state on the server.

  2. To enable or disable cross-component tracing from the administrative console of a server:

    1. Click the Servers tab to open the Servers view.

    2. In the Servers view, right-click the running server where you want to enable or disable cross-component tracing and then select Administration > Run Administrative Console. The login page of the administrative console opens.

    3. In the User ID and Password field, type the user ID and password that you specified when you installed IBM Integration Designer.

    4. Click Login. The Welcome page of the administrative console opens.

    5. In the left frame of the Welcome page, expand Troubleshooting and click the Cross-Component Trace link.

      The Cross-Component Trace page opens.

    6. In the Configuration column of the Cross-Component Trace configuration table, select disable, enable, or enable with data snapshot. This setting is only used when the server is started or restarted. The setting applies to all sessions of the server.

    7. In the Runtime column of the Cross-Component Trace configuration table, select disable, enable, or enable with data snapshot (recommended). This setting is only used when the server is running. The setting only applies to a single session of the server.

    8. Click OK and then click the Save link.
    9. Close the administrative console.


Loading server console and log files into the Server Logs view

In the Server Logs view, you can load the contents of one or more server consoles. You can also load one or more server log files from a server log directory or from other directories anywhere in the file system.

To load server console or log files into the Server Logs view:

  1. Click the Server Logs tab to open the Server Logs view.

  2. In the Server Logs view, click the Load Server Console or Log icon . The Load Server Console or Log window opens.

  3. To load server log files into the Server Logs view from one or more directories in your file system:

    1. Select Load from file.
    2. Beside the Files field, click Browse. The Load from File window opens.

    3. In the Filter field, accept the default filter of .log. This will ensure that only files with a .log file extension will be displayed in the Select files list. (Although you can change the filter to specify another type of file extension, server log files typically have a .log file extension.)

    4. In the Select files list, select one or more server log files to load into the Server Logs view. The Files field displays the paths and names of the selected server log files and the Total file size field displays the total combined size of the selected files.

    5. Click OK to close the Load from File window.

    6. Click OK to close the Load Server Console or Log window. The selected server log files are loaded into a tab in the Server Logs view.

    In the Server Logs view, you can directly load server log files from one or more directories in the file system without first opening the Load Server Console or Log window. Beside the Load Server Console or Log icon, open the associated menu by clicking the down arrow icon . To load logs that were recently loaded in the Server Logs view, the path and names of the logs may be listed on a menu item that you can select to directly reload them. If the logs are not listed on a menu item, you can select the Load from File menu item. The Load from File window will open to enable you to select and load one or more logs.

  4. To load the contents of a server console into the Server Logs view:

    1. Select Load from server console.

    2. In the Server field, select the appropriate server for the server console to load. (If there are no servers currently running, the Server field will be empty.)

    3. Click OK to close the Load Server Console or Log window. The contents of the selected server console are loaded into a new tab in the Server Logs view.

    In the Server Logs view, you can load the contents of the server console for a running server without first opening the Load Server Console or Log window. Beside the Load Server Console or Log icon, click the down arrow icon . From the menu, select Load from Server Console > server_name (where server_name is the name of the server for the console to load). The contents of the console for the selected server are loaded into a tab in the Server Logs view.

  5. To load one or more server log files from a server log directory:

    1. Select Load from server log directory.

    2. In the Server field, select the appropriate server for the server logs to load.
    3. Beside the Files field, click Browse. The Load from Server Log Directory window opens.

    4. In the list of server logs, select the check box beside each server log to load.

    5. Click OK to close the Load from Server Log Directory window.

    6. Click OK to close the Load Server Console or Log window. The server log files that you selected are loaded into a tab in the Server Logs view.

    In the Server Logs view, you can directly load server log files from a server log directory without first opening the Load Server Console or Log window. Beside the Load Server Console or Log icon, open the associated menu by clicking the down arrow icon . To load logs that were recently loaded in the Server Logs view, the path and names of the logs may be listed on a menu item that you can select to directly reload them. If the logs are not listed on a menu item, you can select the Load from Server Log Directory > server_name menu item (where server_name is the name of the server for the server logs to load). The Load from Server Log Directory window will open to enable you to select and load one or more logs.


When you load server console or log records into the Server Logs view, the records are organized into pages. Although you can use the scroll bar to scroll through the records in a single page, you need to use one of the paging tools or the Page Up and Page Down keys to access the records in a different page. Information about using the paging tools is found in the topic "Paging through server console and log records in the Server Logs view."


Paging through server console and log records in the Server Logs view

When you load server console or log records into the Server Logs view, the records are organized into pages. Although you can scroll through the records in a single page, you need to use one of the paging tools to access the records in another page.

To page through server console or log records:

  1. Click the Server Logs tab to open the Server Logs view.

  2. In the Server Logs view, click the tab of the server console or server log that contains the records to page through. In the tab, the current page number is displayed at the end of the filter selection title immediately over the records.

  3. To page up or down through the records one page at a time, complete one of the following steps:

    • To page up through the records, click the Page Up icon . (Alternatively, you can press the Page Up key, which will initially page up through all of the records in the current page and then it will move to the previous page when the top record in the current page is reached.)
    • To page down through the records, click the Page Down icon . (Alternatively, you can press the Page Down key, which will initially page down through all of the records in the current page and then it will move to the next page when the bottom record in the current page is reached.)

  4. To skip directly to a specific page of records, complete the following steps:

    1. Click the Go to Page icon . The Go to Page window opens.

    2. In the Enter page number field, type the page number to skip to.

    3. Click OK. The specified page of records is displayed.


Filtering events

In the Events page of the integration test client, you can choose to filter out the events that you are not interested in viewing. Any events that you filter out in your current instance of the test client will not be filtered out in any other instances of the test client that you choose to open.

To filter events:

  1. In the integration test client, click the Events tab to open the Events page.
  2. At the top of the Events page, click the Filters icon . The Event Filter window opens.

  3. In the Select the filters to apply list, select the check boxes of those events to filter out.

  4. Click OK. The events that you selected will not be displayed in the Events page.


Sorting server console and log records in the Server Logs view

In the Server Logs view, you can sort and display the server console and log records according to their type, timestamp, thread ID, or contents.

To sort server console and log records:

  1. Click the Server Logs tab to open the Server Logs view.

  2. In the Server Logs view, click the tab of the server console or server log that contains the records to sort.

  3. Click the View Menu icon . A menu opens.

  4. To sort the records according to their type, select Sort Column By > Type and then complete one of the following steps:

    • Select the Ascending menu item to sort the records in ascending alphabetic order from a - z in the Type column. The Type column header displays the ascending order symbol .

    • Select the Descending menu item to sort the records in descending alphabetic order from z - a in the Type column. The Type column header displays the descending order symbol .

  5. To sort the records according to the time they were generated, select Sort Column By > Time and then complete one of the following steps:

    • Select the Ascending menu item to sort the records in ascending alphanumeric order from a - z and 1 - n in the Time column. The Time column header displays the ascending order symbol .

    • Select the Descending menu item to sort the records in descending alphanumeric order from z - a and n - 1 in the Time column. The Time column header displays the descending order symbol .

  6. To sort the records according to their thread ID, select Sort Column By > Thread ID and then complete one of the following steps:

    • Select the Ascending menu item to sort the records in ascending numeric order from 1 - n in the Thread ID column. The Thread ID column header displays the ascending order symbol .

    • Select the Descending menu item to sort the records in descending numeric order from n - 1 in the Thread ID column. The Thread ID column header displays the descending order symbol .

  7. To sort the records according to their contents, select Sort Column By > Contents and then complete one of the following steps:

    • Select the Ascending menu item to sort the records in ascending alphabetic order from a - z in the Contents column. The Contents column header displays the ascending order symbol .

    • Select the Descending menu item to sort the records in descending alphabetic order from z - a in the Contents column. The Contents column header displays the descending order symbol .


Searching server console and log records in the Server Logs view

In the Server Logs view, you can search server console and log records for any search string. By default, the scope of your search is restricted to strings that are found in record type fields and record content fields, but you can narrow or expand the scope of your search by including or excluding other kinds of record fields.

To search server console and log records:

  1. Click the Server Logs tab to open the Server Logs view.

  2. In the Server Logs view, click the tab of the server console or server log that contains the records to search.

  3. Click the View Menu icon . A menu opens.

  4. In the menu, select Find. The Find window opens.

  5. In the Find field, type the string to find in the server console or log records.

  6. In the Scope field, select the check box beside each kind of record field to search.

  7. Click Find. If the search string is found, the Find window displays the first record where the string occurs and highlights the string. If the search string cannot be found, the message String not found is displayed over the Find button.

  8. Click Find again to search the server console or log records for the next occurrence of the string. The remaining content of the current record will be searched first followed by the contents of other server console or log records.
  9. When you have finished searching for the string, click Close to close the Find window.


Displaying server console and log record properties in the Server Logs view

In the Server Logs view, you can display the properties for any server console or log record. The properties include the type, time, thread ID, and contents of the record. If you have enabled cross-component trace with data capture, the properties for FFDC records and invocation records, such as Start, End, and Fail invocation records, will also include invocation data.

To display server console or log record properties:

  1. Click the Server Log tab to open the Server Logs view.

  2. In the Server Logs view, click the tab of the server console or server log that contains the record for which you want to display the properties.
  3. Right-click the record and select Properties. The Properties window opens. If you have enabled cross-component trace with data capture and you are displaying the properties for a Start invocation record, such as Start invoke, start component, or Start import, the Properties window will contain a Data area than displays invocation data.

  4. Complete one of the following steps:

    • To view the record contents in a translated format that is easy to read and assimilate, ensure that Translated is selected.

    • To view the record contents in the raw native format in which they were originally generated, select Raw.

  5. When you have finished viewing the record properties, click OK to close the Properties window.


5.4.10. Refresh server console records in the Server Logs view

By default, server console records are automatically refreshed every 5 seconds in the Server Logs view. However, you can choose a different refresh rate for automatic refreshes or you can choose not to have the records automatically refreshed at all. You can also choose to manually and immediately refresh server console records that are displayed in the Server Logs view.

To refresh server console records:

  1. Click the Server Logs tab to open the Server Logs view.

  2. In the Server Logs view, ensure that at least one server console tab is open and selected for a running server.

  3. To create manually and immediately refresh the server console records in the Server Logs view, click the Refresh icon .

  4. To change the refresh rate for automatic refreshes:

    1. Beside the Refresh icon, click the down arrow icon . A menu is displayed.

    2. Select one of the following menu items: No Refresh, 5 Seconds, 10 Seconds, or 20 Seconds. The new refresh rate is displayed in the lower left corner of the Server Logs view.


5.4.11. Loading invocation records into the integration test client

By default, invocation records in the Server Logs view are displayed in hierarchical format with check boxes. This enables you to select the invocation records for direct loading into the integration test client, which is useful when you are working with server console or log records that were not generated by the test client or when you are working with log records that were provided by someone else. When you load invocation records into the test client, the test client displays test events that correspond to the invocation records.

Before you can work with invocation records, you must generate them by enabling cross-component tracing. Information on enabling cross-component tracing is found in the topic "Enabling or disabling cross-component tracing."

To load invocation records into the integration test client:

  1. Ensure the modules and libraries that are associated with the invocation records are resident in the workbench.

  2. Click the Server Logs tab to open the Server Logs view.

  3. In the Server Logs view, click the tab of the server console or server log that contains the invocation records to load into the integration test client.

  4. Ensure the tab is filtered to display invocation records in hierarchical format. (Invocation records are displayed in hierarchical format by default. Detailed information about displaying invocation records is found in the topics "Filtering server console and log records in the Server Logs view" and "Overview of cross-component tracing.")

  5. In the tab, select the check box beside the top invocation record, which is typically a Start invoke record. This will automatically select the check boxes of all records within the invocation.

  6. Click the Load into Test Client icon . The test client opens and displays the events that correspond to the invocation records. If you encountered an ServiceRuntimeException when running a test that involved asynchronous invocations from a mediation flow, the exception is expected and can be ignored. It is thrown when the mediation flow polls for results but the invocation response is not yet available.


Use the integration debugger for problem determination

In IBM Integration Designer, you can debug modules and several kinds of business integration components using the integration debugger. These components include visual snippets, business object data maps, business processes, state machines, mediation flows, business rule sets, and decision tables. You can also debug XML maps, but you can only debug them within the workspace and not on a server.


Component debugging

The integration debugger is an IBM Integration Designer tool that you can use to visually debug local or remote business integration components, such as business processes, business object data maps, mediation flows, and others.

To perform debugging, you need:

  • The test environment
  • The integration debugger

The test environment and the integration debugger are described in greater detail in the following sections.


The test environment

The test environment features runtime support for Process Server, and helps you to debug many of the business integration components that can be created in IBM Integration Designer, including mediation flows.


The integration debugger

The integration debugger uses and extends the Java development tools (JDT) debugger. However, unlike the JDT debugger, the integration debugger features a graphical debugging environment for debugging the following types of business integration components:

  • Business processes
  • Business object data maps
  • Business rule sets and decision tables
  • Business state machines
  • Visual snippets
  • Mediation flows
  • XML maps

Note that you can only debug XML maps within the workspace and not on a server, because debugging will only pause for breakpoints set in the XML map when you are testing or debugging within the workspace. Breakpoints will not cause the maps to pause when running on the server.

The integration debugger documentation provides sufficient information about the basic JDT debugger tools to enable you to work with the integration debugger.

In the integration debugger, you can set breakpoints on component elements and source code. For example, in business processes, you can set breakpoints on activities and Java snippet code. You can then step through the component, change the values of its variables or messages, and step into elements or source code. These capabilities enable you to debug a wide variety of problems in a component, such as:

  • Links that have incorrectly implemented transition conditions
  • Infinite loops not intended to be infinite
  • Improper Java conditions

If a monitor model has an event of type .xsd and it contains & in the event file name, the debugger will not operate on this model. To correct this condition, remove the & from the event .xsd name.


Integration debugger

In IBM Integration Designer, the integration debugger is the designated tool for debugging business integration components. The integration debugger features a sophisticated user interface that enables you to and precisely perform component debugging.

The integration debugger is primarily controlled from the Debug perspective, which is shown in the following figure:

In the Debug perspective, there are five major features that are typically used by the integration debugger. These features are listed in the following table.

Feature Description
1 Debug view
2 Integration test client
3 Component editors
4 Variables view
5 Breakpoints view

These five features consist of an intuitive and flexible user interface for the integration debugger and are described individually in the following topics.

Restriction: Monitor Debugger does not support using special XML characters like ', ", <,> ,& in file name of event definition *.xsd *.cbe, and the monitor model element's ID.


Integration test client

The integration test client is an IBM Integration Designer tool that you can use to test your modules and components. You can also use the test client to automatically start the integration debugger and create a running instance of your component that you can debug.

The integration test client is shown in the following figure:

The test client supports component debugging by automatically performing the following tasks:

  • Deploy your module and components to the server

  • Start the server in Debug mode
  • Creating a component instance that you can pass values and debug

You can open multiple windows of the test client in the workbench and then use each test client window to create a different instance of the same component or another component, which you can simultaneously debug in the integration debugger.

The integration debugger documentation provides sufficient information about the integration test client to enable you to use it with the integration debugger. However, to learn more about the integration test client, see the integration test client topic "Testing modules."


Component editors and the integration debugger

The component editors are IBM Integration Designer tools that are used to create business integration components, such as business processes or mediation flows. In the component editors, you can set breakpoints on component elements or source code and then use the integration debugger to graphically step through instances of the components and work with their variables or messages.

The integration debugger can be used in conjunction with the following component editors:

  • Business process editor
  • Business state machine editor
  • Business object map editor
  • Business rule set editor and decision table editor
  • Visual snippet editor
  • Mediation flow editor
  • XML map editor

In the component editors, there are several integration debugger symbols that can appear either before, during, or after a debugging session. These symbols are described in the following table.

Symbol Description
The breakpoint is installed and enabled.
The breakpoint is installed and disabled.
The breakpoint is enabled but restricted to one or more threads of the business process.
The breakpoint is enabled in a line of source code in the Java™ snippet editor or the condition editor.
The breakpoint is enabled in all threads of the component.
The breakpoint is disabled.
The breakpoint is popped.
In a business process, the link followed if a transition condition evaluates to true. Or, in a mediation flow, the connection that was run.
In a business process, the link followed if a transition condition evaluates to false.
The link followed in a business process if a transition condition is skipped.
A condition evaluated to true or an action was run in a business rule set or decision table.
A condition evaluated to false or an action was not run in a business rule set or decision table.
An exception was encountered in executing a mediation primitive in a mediation flow.


Breakpoints view in the integration debugger

The Breakpoints view displays the breakpoints that are set on component elements and source code in all components. In the Breakpoints view, you can remove, disable, or enable breakpoints. If you are working with business processes, you can also apply hit counts to breakpoints and restrict breakpoints to specific process threads.

The Breakpoints view is shown in the following figure:

In the Breakpoints view, each breakpoint is identified by one of several symbols (which are also used in the component editors). These symbols are described in the following table:

Symbol Description
The breakpoint is installed and enabled
The breakpoint is installed and disabled
The breakpoint is enabled but restricted to one or more threads of the business process
The breakpoint is enabled in a line of source code in the Java™ snippet editor or the condition editor
The breakpoint is enabled in all threads of the component
The breakpoint is disabled

If you double-click a breakpoint in the Breakpoints view, the component editor that contains the breakpoint is opened.

If you are debugging a business process, you can select a breakpoint in the Breakpoints view and then open the breakpoint Properties window to enable or disable the breakpoint, apply hit counts to the breakpoint, or restrict the breakpoint to specific process threads.


Debug view in the integration debugger

In the integration debugger, use the Debug view to control the processing of component instances and alter their state at run time. When you start your server in Debug mode and then create and start one or more component instances, the Debug view is populated with component-related entities, such as component threads and stack frames.

The Debug view is shown in the following figure:

The component-related entities shown in the figure are described in the following table:

Entity Description
1 A component thread, which consists of the thread ID and the thread status. In the Debug view figure, the thread ID is 46855 and the thread status is:

Suspended at <mainProcess.bpel ( Suspended at Receive ) >) A component thread is identified by one of the following symbols:

  • The suspended thread symbol
  • The running thread symbol
  • The terminated thread symbol

2 A stack frame, which consists of the component name and the stack frame information. A stack frame is a location indicator that shows you where the component thread is currently paused. For example, in the figure of the Debug view, the stack frame identifies the business process name mainProcess.bpel and the stack frame information (Suspended at Receive). Stack frames are identified by one of the following symbols:

  • The business process stack frame symbol
  • The business state machine stack frame symbol
  • The business object data map stack frame symbol
  • The business rules stack frame symbol
  • The visual snippet stack frame symbol
  • The mediation flow stack frame symbol


Variables view in the integration debugger

The Variables view displays all variables, messages, and associated values for the stack frame selected in the Debug view. For example, for business processes, the Variables view displays process variables, partner variables, and correlation set variables. And for mediation flows, the Variables view displays messages.

  • Show or hide the type names of all variables and messages (if the Layout > Show Columns menu item is not in the selected state).
  • Show the logical structure of variable types.
  • Change the values of variables and messages.

In the Variables view, variables, messages, and their elements are identified by the symbols shown in the following table:

Icon or Symbol Description
Process variable and its elements (symbol)
Partner variable and its elements (symbol)
Correlation set variable and its elements (symbol)
Mediation flow message and its elements (symbol)


Icons and symbols for the integration debugger

In the integration debugger and other IBM Integration Designer tools, icons are images that are used to invoke actions. Symbols, by comparison, are images that simply represent workbench elements and they are not used to invoke actions.

For example, in the Variables view of the Debug perspective, you can show the type names of variables by clicking the Show Type Names icon . However, you cannot perform any action by clicking the process variable symbol .

The icons and symbols used in the integration debugger are primarily found in the following views of the Debug perspective:

  • Debug view
  • Component editors
  • Breakpoints view
  • Variables view

The icons and symbols found in these views are described in the following sections.


Debug view

The following table describes the integration debugger icons and symbols that are used in the Debug view.

Icon or Symbol Description
Resume the component thread execution (icon)
Suspend the component thread execution (icon)
Terminate the component instance execution (icon)
Step into the element or executing code (icon)
Step over the element or executing code (icon)
Step out of the element or executing code (icon)
Component thread suspended (symbol)
Component thread running (symbol)
Component thread terminated (symbol)
Business process stack frame (symbol)
Business state machine stack frame (symbol)
Business object data map stack frame (symbol)
Business rules stack frame (symbol)
Visual snippet stack frame (symbol)
Mediation flow stack frame (symbol)


Component editors

The following table describes the integration debugger icons and symbols that are used in the component editors.

Icon or Symbol Description
The breakpoint is installed and enabled (symbol)
The breakpoint is installed and disabled (symbol)
The breakpoint is enabled but restricted to one or more threads of the business process (symbol)
The breakpoint is enabled in a line of source code in the Java™ snippet editor or the condition editor (symbol)
The breakpoint is enabled in all threads of the business process (symbol)
The breakpoint is disabled (symbol)
The breakpoint is popped (symbol)
In a business process, the link followed if a transition condition evaluates to true. Or, in a mediation flow, the connection that was run. (symbol)
In a business process, the link followed if a transition condition evaluates to false (symbol)
The link followed in a business process if a transition condition is skipped (symbol)
A condition evaluated to true or an action was run in a business rule set or decision table (symbol)
A condition evaluated to false or an action was not run in a business rule set or decision table (symbol)
An exception was encountered in executing a mediation primitive in a mediation flow. Or a ServiceBusinessException exception was thrown when unmatched conditions were detected in a decision table.


Breakpoints view

The following table describes the integration debugger icons and symbols that are used in the Breakpoints view.

Icon or Symbol Description
Remove selected breakpoints (icon)
Remove all breakpoints (icon)
The breakpoint is installed and enabled (symbol)
The breakpoint is installed and disabled (symbol)
The breakpoint is enabled but restricted to one or more threads of the business process (symbol)
The breakpoint is enabled in a line of source code in the Java snippet editor or the condition editor (symbol)
The breakpoint is enabled in all threads of the component (symbol)
The breakpoint is disabled (symbol)


Variables view

The following table describes the integration debugger icons and symbols that are used in the Variables view.

Icon or Symbol Description
Show or hide the names of the variable types (icon)
Show or hide the logical structure of the variable types (icon)
Process variable and its elements (symbol)
Partner variable and its elements (symbol)
Correlation set variable and its elements (symbol)
Mediation flow message and its elements (symbol)


Keyboard shortcuts for the integration debugger

In the integration debugger, you can perform many of the available debugging actions by using keyboard shortcuts.

Many of these keyboard shortcuts can be invoked from the menus, which you can open by pressing Shift+F10.

In the Debug perspective, keyboard shortcuts are available in the following views and windows:

  • Debug view
  • Breakpoints view
  • Breakpoint Properties window
  • Variables view
  • Component editors

The shortcut keys for each of these views are described in the following sections.


Debug view

The following table describes the integration debugger shortcut keys that you can invoke in the Debug view:

Key combination Function
(Shift+F10)+M Resume the component thread execution
(Shift+F10)+S Suspend the component thread execution
(Shift+F10)+T Terminate the component instance execution
(Shift+F10)+I Step into the element or executing code
(Shift+F10)+O Step over the element or executing code
(Shift+F10)+U Step out of the element or executing code


Component editors

The following table describes the integration debugger shortcut keys that you can invoke in the component editors:

Key combination Function
(Shift+F10)+B+N Add/remove entry breakpoint
(Shift+F10)+B+A Enable/disable entry breakpoint
(Shift+F10)+B+X Add/remove exit breakpoint
(Shift+F10)+B+B Enable/disable exit breakpoint
(Shift+F10)+B+A Add breakpoint in source code (when the entire line of code is highlighted)
(Shift+F10)+B+R Remove breakpoint in source code (when the entire line of code is highlighted)
(Shift+F10)+B+E Enable breakpoint in source code (when the entire line of code is highlighted)
(Shift+F10)+B+D Disable breakpoint in source code (when the entire line of code is highlighted)
(Shift+F10)+B+X Run expression in a business process
(Shift+F10)+B+Y Display expression in a business process
(Shift+F10)+B+E Inspect expression in a business process


Breakpoints view

The following table describes the integration debugger shortcut keys that you can invoke in the Breakpoints view:

Key combination Function
(Shift+F10)+O Remove the selected breakpoints
(Shift+F10)+L Remove all the breakpoints
(Shift+F10)+D Disable the selected breakpoints
(Shift+F10)+E Enable the selected breakpoints
(Shift+F10)+R Open the business process breakpoint Properties window


Breakpoint Properties window

The following table describes the integration debugger shortcut keys that you can invoke in the breakpoint Properties window when you are debugging business processes:

Key combination Function
(Shift+F10)+E Enable the breakpoint
(Shift+F10)+H Enable hit counts
(Shift+F10)+I Specify a hit count value
(Shift+F10)+R Restrict the breakpoint to the selected process threads


Variables view

The following table describes the integration debugger shortcut keys that you can invoke in the Variables view:

Key combination Function
(Shift+F10)+C Change the value of the selected variable or message.


Breakpoints in the integration debugger

In the integration debugger, you can add, disable, enable, or remove breakpoints. Breakpoints in the integration debugger are conceptually similar to breakpoints in the Java™ development tools (JDT) debugger. They are set at specific locations in a component where you want the component instance to pause so that you can determine the status of the component.

In the integration debugger, you can set breakpoints on one or more elements of a component. You can also set breakpoints in the source code of Java snippets and conditions. When a component thread pauses at a breakpoint, you can control program flow or alter the state of the running component.

Depending on the kind of component that you are debugging, you can set a breakpoint, entry breakpoint, or exit breakpoint on a component element. If you set an entry breakpoint on an element, the breakpoint will pop before the element is invoked. If you set an exit breakpoint on an element, the breakpoint will pop after the element is invoked.

The effectiveness of a breakpoint in stopping code execution when it is reached depends on whether it is enabled or disabled. An enabled breakpoint causes normal code execution to stop and the integration debugger to be invoked if an attempt is made to invoke the instruction at the location of the breakpoint. By comparison, a disabled breakpoint will not stop code execution.

If you are debugging a business process, a breakpoint that is set in a process will automatically be set in all instances of the process. If you create new instances of the process, they will inherit all of the breakpoints. However, you can choose to restrict a breakpoint to one or more specific threads of a process. Any breakpoint that is removed from a process is also automatically removed from all other instances of the process.

In the Debug perspective, you can work with breakpoints in both the component editors and the Breakpoints view. The elements that you can set breakpoints on are listed in the following table:

Component editor Business integration components Elements that you can set breakpoints on
Business process editor Business processes Activities, Java snippets
Business state machine editor State machines States
Business object map editor Business object data maps Transformations, Java snippets
Business rule set editor Rule sets Rules, templates, conditions, actions
Decision table editor Decision tables Conditions, actions, values, terms
Visual snippet editor Visual snippets Nodes, custom visual snippets, Java visual snippets
Mediation flow editor and mediation subflow editor Mediation flows Mediation primitives, nodes
XML map editor XML maps Transformations

Note that when use the Refactor menu item to change a component, all breakpoints associated with the component are either automatically modified or deleted. Also, if you change a component file outside of the IBM Integration Designer environment, any associated breakpoints may also be modified or deleted automatically.


Set preferences for the integration test client

By default, the user-definable preferences for the integration test client are already optimized for testing modules. However, in the course of your testing activities, you may find to change some preferences.


Disable warnings about hot code replacement in the integration debugger

Hot code replacement enables you to modify your component without republishing or restarting the server. By default, you receive a warning whenever hot code replacement will not work for a component that you are debugging. For example, hot code replacement does not work for business rule groups. However, you can set an integration debugger preference to disable warnings about hot code replacement.

To disable warnings about hot code replacement:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. In the Preferences window, expand Business Integration and select Debug. The Debug page opens.

  3. Select the Ignore hot code replace warnings check box.

  4. Click OK.


Disable warnings about refactoring in the integration debugger

By default, you receive a refactoring warning whenever your business process breakpoints have been updated as a result of changes you made to your module. The warning cautions you the updated breakpoints will not take effect until after you have redeployed the module to the server. However, you can set an integration debugger preference to disable these warnings about refactoring.

To disable warnings about refactoring:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. In the Preferences window, expand Business Integration and select Debug. The Debug page opens.

  3. Select the Ignore refactoring warnings check box.

  4. Click OK.


Disable warnings about server synchronization in the integration debugger

By default, you receive a server synchronization warning whenever a component in your workspace is out of synchronization with the version of the component running on the server. This most typically occurs when you have made updates to your component in the workspace but you have not yet redeployed the component to the server. As a result, the server is running an older version of the component than is currently found in your workspace. However, you can set an integration debugger preference to disable warnings about server synchronization.

To disable warnings about server synchronization:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. In the Preferences window, expand Business Integration and select Debug. The Debug page opens.

  3. Select Ignore server out of synchronization warnings.

  4. Click OK.


Disable warnings about components that cannot currently be debugged in the integration debugger

By default, you receive a warning about any component that cannot be debugged in the integration debugger. For example, business rules may need to be rebuilt before you can debug them. However, you can set an integration debugger preference to disable warnings about components that cannot currently be debugged.

To disable warnings about components that cannot be debugged:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. In the Preferences window, expand Business Integration and select Debug. The Debug page opens.

  3. Select the Ignore warnings about files may not be debuggable check box.

  4. Click OK.


Enable prompting when duplicate files are encountered in the integration debugger

When you begin to debug a component that has the same file name as one or more other components in the workbench, you will be prompted to confirm the correct component when the first breakpoint is encountered in the component being debugged. By default, you will only be prompted once and then your selection will be used for all subsequent debugging sessions involving a component of the same file name. However, you can set an integration debugger preference to enable you to be prompted every time you begin to debug a component that has the same file name as one or more other components in the workbench.

To enable prompting when duplicate files are encountered:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. In the Preferences window, expand Business Integration and select Debug. The Debug page opens.

  3. Select the Always prompt for file selection if there are duplicate files found in workbench check box.

  4. Click OK.


Specifying how invalid breakpoints should be handled in the integration debugger

In business integration components, breakpoints can become invalid over time. For example, breakpoints can become invalid if refactoring occurs and the breakpoints are not updated or removed. However, you can set a preference to specify how you want invalid breakpoints to be handled in the integration debugger during the course of your debugging tasks.

To specify how invalid breakpoints should be handled:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. In the Preferences window, expand Business Integration and select debug. The debug page opens.

  3. In the Cleanup invalid breakpoints radio button group, choose one of the following radio buttons:

    • Select Always to have invalid breakpoints automatically removed. This is the default selection.

    • Select Never to prevent invalid breakpoints from being automatically removed.

    • Select Prompt to be prompted for a decision on whether to automatically remove invalid breakpoints whenever they are detected.

  4. Click OK.


Enable all variables to be displayed in the integration debugger

If you have stepped into a Java snippet in the integration debugger, the Variables view displays all of the Java variables in the snippet except for the this variable. However, you can set an integration debugger preference that enables the this variable to be displayed in the Variables view.

To enable all variables to be displayed:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. In the Preferences window, expand Business Integration and select Debug. The Debug page opens.

  3. Select the Always show all variables check box.

  4. Click OK.


Enable debug trace logging in the integration debugger

A debug trace log contains problem determination information that is helpful to IBM support personnel. By default, debug trace logging is not enabled when you are working with the integration debugger. However, you can set an integration debugger preference to enable debug trace logging.

To enable debug trace logging:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. In the Preferences window, expand Business Integration and select Debug. The Debug page opens.

  3. Select the Enable trace log check box.

  4. Click OK. From this point on, the integration debugger debug trace will be logged in the widv6debug.log file and the .log file in the .metadata folder.


Enable or disable the integration debugger

In IBM Integration Designer, the integration debugger is enabled by default. However, you can set a preference that disables or enables the debugger.

To enable the integration debugger:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. In the Preferences window, expand Business Integration and select Debug. The Debug page opens.

  3. Depending on whether you want to enable or disable the integration debugger, either select or clear the Enable business integration debugger (restart required) check box.

  4. Click OK.

  5. RestartIBM Integration Designer.


6.4.10. Enable or disable debugger tracing on servers

By default, integration debugger tracing is disabled on servers. Although you can set a preference to enable tracing (which will allow debugger trace information to be displayed in server consoles and server logs in the Server Logs view), you should only enable debugger tracing on the advice of IBM Software Support personnel.

To enable debug trace logging:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. In the Preferences window, expand Business Integration and select Debug. The Debug page opens.

  3. Depending on whether you want to enable or disable integration debugger tracing on the server, either select or clear the Enable debugger tracing on the server (restart required) check box.

  4. Restartyour server or restart IBM Integration Designer.

  5. Click OK.


6.4.11. Change Java breakpoint query timeout values

When a Java breakpoint is encountered while running an application on the server in Debug mode, the integration debugger queries whether a Java snippet is running. If the debugger cannot make the determination before the query times out, the debugger handles the Java breakpoint as though it is not associated with a snippet event. If necessary, you can increase (or reduce) the timeout value for Java breakpoint queries.

To change Java breakpoint query timeout values:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. In the left frame of the Preferences window, expand Business Integration and select Debug. The Debug page opens.

  3. In the Java breakpoint query timeout (in milliseconds) field, specify a value in milliseconds. The default value is 180000 milliseconds, which is 3 minutes.

  4. Click OK.


6.4.12. Specifying regular debugging or problem determination debugging

By default, the integration debugger is optimized for regular debugging of application modules and components in IBM Integration Designer. However, if you are experiencing problems with the debugger, you can specify options that enable you to perform problem determination on the debugger under the guidance of IBM support personnel.

To specify regular debugging or problem determination debugging:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. In the Preferences window, expand Business Integration and select debug. The debug page opens.

  3. In the debug options radio button group, choose one of the following radio buttons:

    • Select IBM Integration Designer debugging for regular debugging of application modules and components. This is the default selection and you should leave this option selected unless you need to perform problem determination on the debugger under the guidance of IBM support personnel.

    • Select Internal debugger debugging to perform problem determination on the debugger run time code under the guidance of support personnel.

    • Select System debugging to perform problem determination on the runtime system code under the guidance of IBM support personnel. (When this option is selected, certain aspects of breakpoint processing are ignored, which enables the breakpoint information to be displayed more quickly.)

  4. Click Apply.

  5. If you have selected the System debugging option, then you must disable step filtering for all com.ibm.* subclasses by completing the following steps:

    1. In the navigation tree of the Preferences window, expand Java and expand debug.

    2. Select Step Filtering. The Step Filtering page opens.

    3. If the Use step filters check box is selected, then clear the com.ibm.* check box in the Defined step filters list and click Apply.

  6. Click OK to close the Preferences window.


If you have chosen a debug option that enables you to perform problem determination on the debugger, you must remember to re-select the IBM Integration Designer debugging option and the com.ibm.* step filter when you have finished with your problem determination.


6.4.13. Change integration debugger thread filters

In IBM Integration Designer, the recommended thread filters are already set by default for use with the integration debugger. However, you can view or change the thread filters if circumstances warrant it.

To change integration debugger thread filters:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. In the left frame of the Preferences window, expand Run/Debug and expand Java and Mixed Language Debug, then select Thread Filters. The Thread Filters page opens.

  3. To ensure the recommended thread filtering preferences are set for the integration debugger:

    1. Ensure the Apply thread filters check box is selected. (Note that if you wanted to show all threads, you would clear the check box.)

    2. Ensure the Java Threads check box is selected. This thread filter will filter the Java™ threads of IBM Business Process Manager from the Debug view in the Debug perspective. When Java threads are filtered, they will not appear in the Debug view unless a debug event occurs within them, such as a breakpoint.

    3. Ensure the WBI Thread Filter check box is not selected. This will enable IBM Integration Designer threads to be displayed in the Debug view.

    4. Click OK.


6.4.14. Change integration debugger timeout values

If you are experiencing problems with the integration debugger timing out before you can begin your debugging session, you can change the debugger timeout values to allow the debugger more time to start.

To change integration debugger timeout values:

  1. From the Window menu, select Preferences. The Preferences window opens.

  2. In the left frame of the Preferences window, expand Java and select Debug. The Debug page opens.

  3. In the Debugger timeout (ms) field, ensure the value is at least 300000 milliseconds, which is five minutes.

    You can increase the debugger timeout value as needed.

  4. In the Launch timeout (ms) field, ensure the value is at least 20000 milliseconds.

    You can increase the launch timeout value as needed.

  5. Click OK.


Prepare for remote debugging

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 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

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 Process Server runtime environment directly.

To prepare for remote debugging:

  1. 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 to use for the server): installDir/profiles/profileName/bin
    • On IBM Integration Designer: installDir/pf/wps/bin

  2. 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.
  3. When the server has finished starting, open a browser window and load the URL for the BPM administrative console on the remote machine; for example, http://localhost:9060/ibm/console or http://remote_host_name:9060/ibm/console.

  4. In the User ID and Password fields of the administrative console Login page, specify the user ID and password and then click Log in.

  5. Ensure the server starts up in debug mode by completing the following steps:

    1. 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.

    2. In the Application Servers page, click the server1 link. The server1 page opens.
    3. Scroll down to the Additional Properties section and click the Debugging Service link.

      The Debugging Service page opens.

    4. Ensure the Enable service at server startup check box is selected.

    5. 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.)

    6. 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

    7. Click Apply to save the changes so they are picked up the next time the server is started.

    8. Click the Save link to save the changes.

  6. Disable the transaction timeout values by completing the following steps:

    1. In the left frame of the administrative console, click the Application Servers link.

      The Application Servers page opens in the right frame.

    2. In the right frame, click the server1 link. The server1 page opens.
    3. Scroll down to the Container Settings section and expand Container Services, then click the Transaction Service link. The Transaction Service page opens.

    4. In the Total transaction lifetime timeout field, type 0 to indicate there should be no timeout.

    5. In the Client inactivity timeout field, type 0 to indicate there should be no timeout.

    6. Click Apply.

    7. Click the Save link to save the changes.

  7. 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:

    1. In the left frame of the administrative console, click the Application Servers link.

      The Application Servers page opens in the right frame.

    2. In the right frame, click the server1 link. The server1 page opens.
    3. Scroll down to the Container Settings section and expand Container Services, then click the ORB Service link. The ORB Service page opens.

    4. In the Request timeout field, type 0.

    5. In the Locate request timeout field, type 0.

    6. Click Apply.

    7. Click the Save link and then click the Save button to save the changes.

  8. At the top of the administrative console, click the Logout link to log out of the administrative console.
  9. On your local IBM Integration Designer machine:

    1. Set the integration debugger timeout values by following the instructions in the debugger topic "Changing timeout values".

    2. Open the component 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.

    3. Create a server instance for your remote IBM Business Process Manager by following the instructions in the deployment topic " Create servers in the test environment".

    4. In the Servers view, ensure 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.)

    5. In the Servers view, right-click your new server and select Restart > Debug to restart your remote IBM Business Process Manager in debug mode.
    6. 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.)


Create a component instance

Before you can work with the integration debugger, create an instance of the component to debug. A component instance is a running component that can be run in parallel with other instances of the same component, such as a business process.

The integration test client is the recommended tool for creating a component instance for debugging, especially if the module that contains your component is not yet complete. The test client can automatically deploy your module and components to the server and start the server in Debug mode. However, if your module is complete and capable of running on its own, you can also use other methods to create a component instance for debugging without the use of the integration test client, such as a JAX-RPC web service, JSP, the Business Process Choreographer Explorer, or the IBM Integration Designer application framework.

To create a component instance using the integration test client, the module that contains the component must have one of the following exports:

  • An export with an SCA binding.
  • An export with a JMS binding that is referenced by the import of another module.

If you have an export with a JMS binding that is not referenced by the import of another module, or if you have an export with a SOAP binding, you can still use the integration test client to initiate debugging. However, you would need to use the attach facility of the integration test client to attach the test client to your module and then use a client of your own to create a component instance.

To create a component instance:

  1. In the Business Integration perspective, open the component to debug in the component editor. For example, to debug a business process, you would open the process in the business process editor.

  2. In the component editor, right-click the first element in the component where you can set a breakpoint and then 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.

    Save changes and close the component editor.

  3. If you are debugging an XML map, complete one of the following steps:

    • In the Business Integration view, right-click the map and select Test.

    • In the mediation flow editor, right-click the Mapping primitive that is associated with the map and select Test XML Map.

    The integration test client opens.

  4. In the Business Integration view, right-click the module that contains your component and select Test > Test Module. The integration test client opens.

    Note that if you are debugging an XML map, you can right-click the map in the Business Integration view and select Test or you can right-click the Mapping primitive (that is associated with the map) in the mediation flow editor and select Test XML Map. The test client will open. To open the Debug perspective before each transform in the map runs, you can select the Stop for debug before transformations check box in the test client.

  5. In the Business Integration view, In the Events area of the integration test client, an Invoke event is automatically generated whenever the test client is started. An Invoke event is an interactive event, which means that you must manually select an operation to test and specify some initial request parameters values for the operation before the test can continue.

  6. In the Detailed Properties area of the integration test client:

    1. In the Component field, ensure the selected component is the component to debug.

    2. In the Interface field, ensure the component interface is selected that contains the operation to invoke.

    3. In the Operation field, ensure the interface operation is selected to invoke.

  7. In the Initial request parameters value editor, specify the input values for the selected operation in the Value column, as shown in the figure below:

  8. Click the Continue icon. The Deployment Location wizard opens.

  9. Ensure the correct deployment location is selected in the Deployment Location wizard.

  10. In the Mode drop-down list, ensure that Debug is selected and then click Finish. The following tasks are automatically performed:

    • The interface operation selected in the test client is invoked.
    • The component and the rest of the module are automatically deployed to the server.
    • The server is started in Debug mode.
    • A moment or two after the server is started in Debug mode, the Console view displays a message that indicates the server is ready for debugging the component.
    • A component instance is created and started.
    • The Debug perspective is opened.
    • The component editor that contains the breakpoint is opened in the Debug perspective and the component thread pauses at the breakpoint set in the editor.

When you have finished creating the component instance, you can repeat the steps to additional instances of the same component (or to create new instances of different components) in the integration test client and then debug them simultaneously in the integration debugger. To learn more about the integration test client, see the integration test client topic "Testing modules."


Manage breakpoints in the integration debugger

In the component editors, you can add, disable, enable, or remove breakpoints on component elements and Java™ code. You can also use the Breakpoints view to manage the breakpoints.


Add breakpoints in the integration debugger

When you are working with the integration debugger, you can add breakpoints directly on component elements in a component editor or in lines of code in the Java™ snippet editor or condition editor. Any breakpoint that is added in a component instance is also automatically added to all other instances of the component and you do not need to restart any of the instances.

In the integration debugger, you use menu items to add breakpoints in components. The specific menu items that are available for adding breakpoints is dependent on the following factors:

  • The kind of component you are adding breakpoints in
  • The status of the integration debugger (started or not started)

To add a breakpoint:

  1. If you are working with a business process in the business process editor, save the most recent changes to your business process. You should always save the most recent changes to your business process before you add any new or additional breakpoints.

  2. To add a breakpoint to a component element, right-click the element in the component editor and select one of the following menu items:

    • Debug > Add Breakpoint (or Debug > Add/Remove Breakpoint)
    • Debug > Add Entry Breakpoint (or Debug > Add/Remove Entry Breakpoint)
    • Debug > Add Exit Breakpoint (or Debug > Add/Remove Exit Breakpoint)
    • Local Debug > Add Entry Breakpoint
    • Local Debug > Add Exit Breakpoint

    If you add an entry breakpoint to an element, the breakpoint will pop before the element is invoked. If you add an exit breakpoint to an element, the breakpoint will pop after the element is invoked.

  3. To add a breakpoint to a line of code in a Java snippet or condition, complete one of the following steps:

    • In the Java snippet editor or condition editor, right-click the left margin beside the line of code where you want to set a breakpoint and select Add Breakpoint.

    • In the Java snippet editor or condition editor, highlight the line of code where you want to set a breakpoint, then right-click the line of code and select Debug > Add Breakpoint (or Debug > Add/Remove Breakpoint).


Disable breakpoints in the integration debugger

When you are working with the integration debugger, you can disable breakpoints directly in component elements in a component editor or in lines of code in the Java™ snippet editor or condition editor. You can also use the Breakpoints view to select and disable breakpoints. Any breakpoint that you disable in a component instance is also automatically disabled in all other instances of the component and you do not need to restart any of the instances.

In the integration debugger, you use menu items to disable breakpoints in components. The specific menu items that are available for disabling breakpoints is dependent on the following factors:

  • The kind of component you are disabling breakpoints in
  • The status of the integration debugger (started or not started)

To disable breakpoints

  1. To disable an individual breakpoint in a component element, right-click the breakpoint in the component editor and select one of the following menu items:

    • Debug > Disable Breakpoint (or Debug > Enable/Disable Breakpoint)
    • Debug > Disable Entry Breakpoint (or Debug > Enable/Disable Entry Breakpoint)
    • Debug > Disable Exit Breakpoint (or Debug > Enable/Disable Exit Breakpoint)
    • Local Debug > Disable Entry Breakpoint
    • Local Debug > Disable Exit Breakpoint

  2. To disable a breakpoint in a line of code in a Java snippet or condition, complete one of the following steps:

    • In the Java snippet editor or condition editor, right-click the breakpoint in the left margin and select Disable Breakpoint.

    • In the Java snippet editor or condition editor, highlight the line of code where the breakpoint is set, then right-click the line of code and select Debug > Disable Breakpoint (or Debug > Enable/Disable Breakpoint).

  3. To disable one or more selected breakpoints in the Breakpoints view:

    1. In the Debug perspective, click the Breakpoints tab to open the Breakpoints view.

    2. In the Breakpoints view, clear the check box beside each breakpoint to disable.

  4. To disable an individual breakpoint in a business process through the Breakpoint Properties window:

    1. In the Debug perspective, click the Breakpoints tab to open the Breakpoints view.

    2. In the Breakpoints view, right-click the breakpoint in the business process to disable and select Properties. The breakpoint Properties window opens.

    3. In the left frame of the Properties window, ensure that Common is selected.

    4. In the right frame of the Properties window, clear the Enabled check box and click OK.


Enable breakpoints in the integration debugger

When you are working with the integration debugger, you can enable breakpoints directly in component elements in a component editor or in lines of code in the Java™ snippet editor or condition editor. You can also use the Breakpoints view to select and enable breakpoints. Any breakpoint that you enable in a component instance is also automatically enabled in all other instances of the component and you do not need to restart any of the instances.

In the integration debugger, you use menu items to enable breakpoints in components. The specific menu items that are available for enabling breakpoints is dependent on the following factors:

  • The kind of component you are enabling breakpoints in
  • The status of the integration debugger (started or not started)

To enable breakpoints:

  1. To enable an individual breakpoint in a component element, right-click the breakpoint in the component editor and select one of the following menu items:

    • Debug > Enable Breakpoint (or Debug > Enable/Disable Breakpoint)
    • Debug > Enable Entry Breakpoint (or Debug > Enable/Disable Entry Breakpoint)
    • Debug > Enable Exit Breakpoint (or Debug > Enable/Disable Exit Breakpoint)
    • Local Debug > Enable Entry Breakpoint
    • Local Debug > Enable Exit Breakpoint

  2. To enable a breakpoint in a line of code in a Java snippet or condition, complete one of the following steps:

    • In the Java snippet editor or condition editor, right-click the breakpoint in the left margin and select Enable Breakpoint.

    • In the Java snippet editor or condition editor, highlight the line of code where the breakpoint is set, then right-click the line of code and select Debug > Enable Breakpoint (or Debug > Enable/Disable Breakpoint).

  3. To enable one or more selected breakpoints in the Breakpoints view:

    1. In the Debug perspective, click the Breakpoints tab to open the Breakpoints view.

    2. In the Breakpoints view, select the check box beside each breakpoint to enable.

  4. To enable an individual breakpoint in a business process through the Breakpoint Properties window:

    1. In the Debug perspective, click the Breakpoints tab to open the Breakpoints view.

    2. In the Breakpoints view, right-click the breakpoint in the business process to enable and select Properties. The breakpoint Properties window opens.

    3. In the left frame of the Properties window, ensure that Common is selected.

    4. In the right frame of the Properties window, select the Enabled check box and click OK.


Remove breakpoints in the integration debugger

When you are working with the integration debugger, you can remove breakpoints directly from component elements in a component editor or from lines of code in the Java™ snippet editor or condition editor. You can also use the Breakpoints view to select and remove breakpoints. Any breakpoint that is removed from a component instance is also automatically removed from all other instances of the component and you do not need to restart any of the instances.

In the integration debugger, you use menu items to remove breakpoints in components. The specific menu items that are available for removing breakpoints is dependent on the following factors:

  • The kind of component you are removing breakpoints from
  • The status of the integration debugger (initialized or not initialized)

To remove breakpoints:

  1. To remove an individual breakpoint from a component element, right-click the breakpoint in the component editor and select one of the following menu items:

    • Debug > Remove Breakpoint (or Debug > Add/Remove Breakpoint)
    • Debug > Remove Entry Breakpoint (or Debug > Add/Remove Entry Breakpoint)
    • Debug > Remove Exit Breakpoint (or Debug > Add/Remove Exit Breakpoint)
    • Local Debug > Remove Entry Breakpoint
    • Local Debug > Remove Exit Breakpoint

  2. To remove a breakpoint from a line of code in a Java snippet or condition, complete one of the following steps:

    • In the Java snippet editor or condition editor, right-click the breakpoint in the left margin and select Remove Breakpoint.

    • In the Java snippet editor or condition editor, highlight the line of code where the breakpoint is set, then right-click the line of code and select Debug > Remove Breakpoint (or Debug > Add/Remove Breakpoint).

  3. To remove one or more selected breakpoints simultaneously in the Breakpoints view:

    1. In the Debug perspective, click the Breakpoints tab to open the Breakpoints view.

    2. In the Breakpoints view, highlight one or more breakpoints to remove.

    3. Click the Remove Selected Breakpoints icon .

  4. To remove all breakpoints simultaneously in the Breakpoints view:

    1. In the Debug perspective, click the Breakpoints tab to open the Breakpoints view.

    2. In the Breakpoints view, click the Remove All Breakpoints icon .


Applying hit counts to breakpoints in the integration debugger

In the integration debugger, you can add hit counts to breakpoints that have been set in business processes. When a hit count is applied to a breakpoint, the breakpoint suspends execution of the process thread when the specified hit count value is encountered. The process thread execution remains suspended until it is enabled again or until the hit count is changed or disabled. To apply a hit count to a breakpoint:

  1. In the Breakpoints view, right-click the breakpoint to which you want to apply a hit count and then select Properties from the menu. The breakpoint Properties window opens.

  2. In the left frame of the Properties window, ensure that Common is selected.

  3. Select the Hit Count check box.

  4. In the Hit Count field, type the hit count value to apply to the breakpoint.

  5. Click OK to close the window.


Restrict breakpoints to specific process threads in the integration debugger

In the integration debugger, you can restrict a breakpoint to one or more threads of a business process. This enables you to work more easily with just those threads that you are currently interested in, rather than with all threads of the process. To restrict a breakpoint to one or more process threads:

  1. In the Breakpoints view, right-click the breakpoint to restrict to one or more threads and then select Properties from the menu. The Breakpoints Properties window opens.

  2. In the left frame of the Properties window, ensure that Filtering is selected.

  3. In the Restrict to Selected Threads list box, select the check boxes of those threads to which you want to restrict the breakpoint.

  4. Click OK.


Stepping through component instances in the integration debugger

In the integration debugger, you can step into, step over, or step out of various elements in a component instance.


Resuming component thread execution in the integration debugger

In the integration debugger, you can resume the execution of any component thread that is currently paused. To resume component thread execution:

  1. In the Debug view, ensure the correct stack frame is selected for the component thread to resume.

  2. Click the Resume icon . The component thread pauses at the next available breakpoint. If there is no breakpoint at which any of the component threads can pause, the component instance runs to completion and terminates.


Stepping into component elements in the integration debugger

Depending on the kind of business integration component that you are debugging, you can use the integration debugger to step into component elements.

The elements that you can step into for each kind of business integration component are listed in the following table:

Business integration component Elements that can be stepped into
Business processes Java™ snippets, visual snippets
State machines None
Business object data maps Submaps, Java snippets,
Business rules Rule set templates
Visual snippets Custom visual snippets, Java visual snippets
Mediation flows Subflows

To step into component elements:

  1. In the Debug view, ensure the correct stack frame is selected.

  2. In the component editor, ensure the component thread is paused at a position immediately before the element to step into. For example, to step into a Java snippet in the business process editor, ensure the Java snippet activity has an entry breakpoint on it and the component thread is paused before the breakpoint.

  3. In the Debug view, click the Step Into icon . The element that you are stepping into opens and the component thread pauses at the first location where a breakpoint exists or can be set. For example, if you step into a Java snippet, the component thread pauses at the first line of code that contains a breakpoint or where you could set a breakpoint.


Stepping over component elements in the integration debugger

Depending on the kind of business integration component that you are debugging, you can use the integration debugger to step over various types of component elements.

The elements that you can step over for each kind of business integration component are listed in the following table:

Business integration component Elements that can be stepped over
Business processes Activities
State machines States
Business object data maps Transformations
Business rules Rule sets (rules, templates, conditions, actions) and decision tables (conditions, actions, values, terms)
Visual snippets Nodes
Mediation flows Mediation primitives, nodes

To step over a component element:

  1. In the Debug view, ensure the correct stack frame is selected.

  2. In the component editor, ensure the component thread is paused at a position immediately before the element to step over.

  3. In the Debug view, click the Step Over icon . The component thread resumes and steps over the element and then pauses at the next element where a breakpoint either exists or can be added. For example, if the component thread is paused at an activity in a business process, the component thread steps over the activity and pauses at the next available activity. (Similarly, if the component thread is paused at a code execution point inside a Java™ snippet, the component thread steps over the code statements and pauses at the next point in the code where a breakpoint either exists or can be added. When the last line of execution is reached in the Java snippet, the component thread exits the Java snippet and pauses at the next element in the component where a breakpoint exists or can be added.)


Stepping out of component elements in the integration debugger

Depending on the kind of business integration component that you are debugging, you can use the integration debugger to step out of component elements that you stepped into.

The elements that you can step out of for each kind of business integration component are listed in the following table:

Business integration component Elements that can be stepped out of
Business processes Java™ snippets
State machines None
Business object data maps Submaps, Java snippets
Business rules Rule set templates
Visual snippets Custom visual snippets, Java visual snippets
Mediation flows Subflows

To step out of component elements:

  1. In the Debug view, ensure the correct stack frame is selected.

  2. Click the Step Return icon . The component thread resumes and steps out of the element that you had stepped into and it pauses at the next available component element. For example, if you had stepped into a Java snippet in a business process, the component thread steps out of the Java snippet and pauses at the next available process activity.


Suspending component thread execution in the integration debugger

In the integration debugger, you can suspend the execution of all component threads except for business process and business state machine threads.

To suspend component thread execution:

  1. In the Debug view, ensure the correct stack frame is selected for the component thread to suspend.

  2. Click the Suspend icon . The component thread suspends and is flagged with the suspended component thread symbol .


Terminating component instances in the integration debugger

In the Debug perspective, you can terminate the execution of all component instances except for business processes and business state machines. Terminating one or more component instances may be necessary in some situations rather than letting the instances exit naturally as a result of your debugging tasks.

To terminate one or more component instances:

  1. To terminate a single component instance and leave its threads visible in the Debug view:

    1. In the Debug view, ensure the correct stack frame is selected for the component instance to terminate.

    2. Click the Terminate icon . The component instance terminates and its threads are flagged with the terminated component thread symbol .

  2. To terminate a single component instance and remove its threads from the Debug view:

    1. In the Debug view, ensure the correct stack frame is selected for the component instance to terminate.
    2. Right-click the selected stack frame and select Terminate and Remove. The component instance terminates and its threads are removed from the Debug view.

  3. To simultaneously terminate all active component instances in the Debug view:

    1. In the Debug view, ensure that a stack frame is selected for any one of the component instances to terminate.
    2. Right-click the selected stack frame and select Terminate All. All active component instances terminate and their threads are flagged with the terminated component thread symbol .


Run to a transformation in the integration debugger

When you are debugging business object data maps in the integration debugger, you can select a transformation in the business object map editor and then have the integration debugger run to the selected transformation in a single action.

To run to a transformation:

  1. In the Debug view, ensure the correct stack frame is selected.

  2. In the business object map editor, right-click the transformation that you want the integration debugger to run to, then select Debug > Run To. The integration debugger runs to the selected transformation.


Manage test variations

A test variation is a specific set of variable values for a test case. Although each test case is automatically assigned a default test variation, you can create multiple test variations for a test case that each contain a different set of variable values. When a test case is run, all of the test variations for the test case are run.


Showing variable type logical structures in the integration debugger

In the Variables view of the integration debugger, the logical structure of some variable types is shown by default. This includes Java types associated with business object data maps, business rules, and decision tables. However, you can choose to expand the content of the Variables view to show the full implementation details of the variable types.

To show the implementation details of variable types:

  1. In the Debug view, ensure the correct stack frame is selected for the variable types whose implementation details you want to show.

  2. In the Variables view, click the Show Logical Structure icon . The content in the Variables view is expanded to include the full implementation details.

  3. If you later want to show the logical structure for the variable types, click the Show Logical Structure icon again. This filters out the implementation details and reduces the content displayed in the Variables view to just variables, business object fields (or variable parts), and values.


Showing variable or message type names in the integration debugger

In the Variables view of the Debug perspective, you can choose to either show or hide the type names of all listed variables or messages, such as the Java™ type names String, int, or boolean.

To show or hide type names:

  1. In the Debug view, ensure the correct stack frame is selected for the variables or messages whose type names you want to show or hide.

  2. In the Variables view, click the arrow icon .

  3. From the menu, select Layout and remove the check mark beside the Show Columns menu item.

  4. In the Variables view, click the Show Type Names icon . The icon toggles between showing and hiding the type names of the variables or messages.


Change variable or message values in the integration debugger

In the Debug perspective, all variables or messages associated with a selected stack frame are displayed in the Variables view. You can change the value of many (but not all) variables and messages.

For example, if you are debugging a business process, you can change the value of process variables but not the value of partner or correlation set variables. And if you are debugging a mediation flow, you can change the values of elements in the context or body sections of a message, but you cannot change the values of elements in the header section of a message. To change variable or message values:

  1. In the Debug view, ensure the correct stack frame is selected for the variable or message.

  2. In the Variables view, locate the variable part or message element that has the value you want to change.
  3. Right-click the variable part or message element and select Change Value. The Set Value window opens.
  4. Type the new value into the text area and click OK.


Evaluating expressions in the integration debugger

If you are debugging a business process in the integration debugger and execution suspends at a breakpoint in a Java™ snippet, you can evaluate expressions in the context of a stack frame.

Expressions can be entered and evaluated in the following areas:

  • Detail pane of the Expressions view
  • Java editor when it is displaying source and it is not read-only

To evaluate expressions:

  1. Select the stack frame in which an evaluation is to be performed. For the detail pane of the Expressions view, the evaluation context will be a selected variable. If no variable is selected, the selected stack frame will be the context.

  2. Select the expression to be evaluated and select Display, Inspect or Execute from the context menu. The result of a Display or Inspect evaluation is shown in the Expressions view. Note that Execute does not display a result. The expression is just run.


Example

Note: Evaluations cannot be performed in threads that have been manually suspended.


Limitations for the integration debugger

From time to time, you may encounter some limitations when using the integration debugger. In most situations, you can work around these limitations and continue to successfully debug your business integration components.

Some of the more common limitations encountered when using the integration debugger are:

  • A business process running in the debugger is not picking up your changes
  • Old breakpoints are causing problems or confusion

These limitations are discussed in the following sections.


A business process running in the debugger is not picking up your changes

If you are debugging a business process in the Debug perspective and you find that you need to edit the process, it is recommended that you first run the process to completion by repeatedly clicking the Resume button until the process exits. When you have finished running the process to completion, you can then edit the process. If you edit the process while the server is running, it is generally recommended that you right-click your server in the Servers view and select Publish. Although some changes to business processes will automatically be picked up by a running process instance, selecting Publish will ensure that all of your changes will be picked up.


Old breakpoints are causing problems or confusion

When debugging business processes, there are some situations where you should manually remove your old breakpoints to avoid encountering problems or confusion in your debugging tasks.

For example, if you have set breakpoints in a condition that you built using the visual snippet editor and you then decide to further develop the condition by editing the Java™ code directly, you should remove the old breakpoints that you added in the visual snippet editor. Similarly, if you have set breakpoints in a condition that you built by editing the Java code directly and you then decide to further develop the condition by editing the condition in the visual snippet editor, you should remove the old breakpoints that you added by editing the Java code directly.

Another situation where you may need to remove old breakpoints is when you are working with a business process expiration condition (for a Staff or Invoke activity) or a time-related condition (such as a Wait activity or onAlarm activity). For example, if you switch from the Duration setting to the Date setting, any breakpoint that was set in the Duration setting is not properly removed and you must manually remove it. Similarly, if you switch from the Date setting to the Duration setting, any breakpoint that was set in the Date setting is not properly removed and it must be manually removed.


Creation of a Process Server on a Process Center causes a prompt for credentials

A Process Server that is connected to a Process Center is called a Process Server on a Process Center. When you create a Process Server on a Process Center, you might be asked for user ID, password, and port credentials. This request is caused by a difference between the Process Server and Process Center credentials.

The Process Server and Process Center are assumed to use the same credentials. Suppose you created a process application on a Process Center with credentials that are different from the Process Server. Then, you created a Process Server on the Process Center to run the process application. Since the credentials are different, you are prompted for a user ID, password, and port.

To correct the problem, see your system administrator for the credentials needed and enter them in the fields provided.


+

Search Tips   |   Advanced Search