The web Process Designer has no step-through debugger for coaches; its Debug command starts the service in a new tab and stops at server-side steps only. For coach and client-side script problems use the browser instead - the CSHS runs in the browser, so the browser debugger is the real debugger:
- Run the human service (Run / playback), press F12, tab Sources. Client-side scripts of the CSHS appear as evaluated scripts; put debugger; as the first line of the client-side script or the coach view handler you want to stop in - the browser breaks there, with tw.local and the coach view objects inspectable.
- In coach view code, console.log(this.context.viewid, this.context.binding.get("value")) in load / change prints the data flow; the Console shows exceptions from handlers that the coach framework otherwise swallows.
- Use page.ui.get("Control").getData() in the console to look at any control at run time.
- Network tab: every service flow call is a POST /rest/bpm/wle/v1/service/... (or /teamworks/...) - inspect the request and response JSON to see what the server received.
// client-side script in a CSHS
debugger; // browser breaks here when dev tools are open
console.log("order before coach", JSON.stringify(tw.local.order));The Debug button of the web designer is still useful for service flows (server-side steps, variables panel, step over) - what gets "stuck at coach events" is that the debugger has nothing to show for browser-side steps: when it reaches a coach it hands over to the running page; continue there and come back for the next service flow. The desktop designer's inspector behaved the same way for CSHS; only heritage human services had server-side coach steps to debug.
References