Using trace

If you cannot get enough information about a particular problem from the entries that are available in the various logs, the next troubleshooting method to consider is using trace. Trace provides more details about what is happening while code runs. The information that is produced from trace is sent to a specified trace record so that you or IBM® support personnel can analyze it to discover the cause of your problem.

Trace is inactive by default, and must be explicitly activated by using a command, the IBM App Connect Enterprise web user interface, or the REST API.

There are two main types of trace available in IBM App Connect Enterprise: user trace and service trace. Typically, you run user trace for debugging your applications; you can trace integration nodes, integration servers, and deployed message flows. With service trace, you can activate more comprehensive integration node tracing, and trace the execution of all the commands that are described in Commands.

When you start user tracing, you cause extra processing for every activity in the component that you are tracing. Large quantities of data are generated by the components, so you can expect performance to be affected while trace is active. You can limit this extra processing by being selective about what you trace, and by restricting the time during which trace is active.

For more information about starting and stopping Trace nodes, see Switching Trace nodes on and off.

You can also trace a specific command, without modifying trace settings on the integration server, by specifying the trace flag when you run the command. For more information, see the explanation of the --trace parameter in the relevant command topic.

For more help with data collection, you can use the aceDataCollector command command.