Using Breakpoints When Debugging Flow Services

Within Designer, a breakpoint is a point in a flow service where you want processing to halt when you debug that flow service. Breakpoints can help you isolate a section of code or examine data values at a particular point in the execution path. For example, you might want to set a pair of breakpoints before and after a particular segment of a flow so that you can examine the pipeline in the Variables view before and after that segment executes.

When you execute a service that contains a breakpoint or call a child service that contains a breakpoint, the service is executed up to, but not including, the designated breakpoint step. At this point, processing stops and the debug session suspends. To resume processing, you can execute one of the step commands or select Run > Resume. After you resume the debug session, Designer stops at any subsequent breakpoints.

Breakpoints are persistent in Designer.

Breakpoints are also local to your Designer workspace. Breakpoints that you set in your workspace do not affect other developers or users who might be executing or debugging services in which you have set breakpoints.

Breakpoints are only recognized when you execute a service in debug session. Breakpoints are ignored when you run a service.

To set a breakpoint in a service, you must have Read access to a service. However, if the service is invoked within another service (a top-level service) to which you have Read access, you can set a breakpoint on the service within the top-level service.

When you delete a flow step or transformer that contains a breakpoint, Designer removes the breakpoint.

You can use breakpoints as markers in your flow services. To do this, assign a breakpoint to the flow step that you want to use as a marker. In Breakpoints view, you can quickly go to the flow step by right-clicking the breakpoint and selecting Go to File or by double-clicking the breakpoint.

Breakpoints can be used in flow services that contain transactions, however, the breakpoint must be set before the transaction starts or after the transaction commits or rolls back. Do not set breakpoints within the transaction. If you do so, transactionality will not be honored and the flow service may throw an exception.

When using breakpoints in a flow service that performs an asynchronous request/reply with webMethods messaging where Universal Messaging is the messaging provider, insert the breakpoint at or before the service that initiates the request and/or after the service that retrieves the request. That is, insert the breakpoint at or before the invocation of pub.publish:publishAndWait or pub.publish:deliverAndWait and/or after the invocation of pub.publish:waitForReply. Do not set a breakpoint on a step that occurs after the initiating the request but before retrieving the reply. When you run a flow service in debug mode, Designer considers every Run, Step Into, Step Over action to be a new service execution. The request/reply channel created by the publishing service is removed when Designer encounters the breakpoint. Setting a breakpoint after the publish but before retrieving the reply results in the removal of the request reply/channel which means that there is no channel from which the pub.publish:waitForReply service can retrieve a reply document.