Quick note about debugging in Process Builder
Late Friday night, I had an epiphany of sorts. Some of you know that I've been debugging a process in Process Builder (PB) and encountering some problems. It occurred to me that in the debugging process, I went a bit too far and started debugging the Process Builder debugger. (Ooops.) While there are issues with the process debugger, it's helpful to know when to draw the line between your code and the actual EMC code.
The confusion is most likely going to occur if you're debugging using Composer and the PB debugger together and stepping through your code. In the Debug perspective in Composer, whenever you are stepping through any code in ProcessEngine.jar, you're more than likely going through the PB engine that simulates the method server. This is the part of the code where fake workitems are created and so forth to test the workflow without actually doing it on the Content Server itself.
If you happen to encounter an error in this section of your debugging session, just keep in the back of your mind that you could be running into an error with the PB debugger and not necessarily an error with your code. There's a chance it could would on the actual Content Server in a real workflow. The debugger is pretty darn good, but I know it isn't perfect. For a feature that's fairly new, I give it a A- and I'm not going to stop using it. I happened to dig a bit too deep and thought the error I was having was with the DFC or part of the core BPM processes, but now it looks like it's the debugger.
There isn't any documentation about where in the debug process your code starts and ends, but from my usage I can pass along a bit of info. When the workflow process first starts, anything past the GenericWorkflow execute is going to be your code. Since you can't place a breakpoint in Composer until your code actually is executed, I wouldn't worry too much about getting into trouble. Once you get past the return statement in your custom workflow code, you're back into the ProcessEngine.jar and into the psuedo method server. Most of your attention should be on the return statement value, which if your code worked is going to be zero. If the simulator reports back that the method failed and you're absolutely sure that your code is correct, try running your custom workflow method on the content server to be sure. There's a small chance the debugger may be throwing an error. Having your code run perfectly on a simulated method server is no guarantee that it will work on the real thing. Try it out in your development environment to be sure.
Categories
- All Categories
- Cloud Editions
- 1 Thrust Services
- cat as link
- 1 Core SaaS Application development
- 10 Developer Announcements
- 15 General Questions
- 33.4K TeamSite
- 141 Application Governance & Archiving
- 15.2K Designing Analytics Reports
- 1K DevShare Downloads
- Core SaaS Applications
- nested parent
- 4.3K Developing Analytics Applications
- 8.8K Documentum Developer Forum
- Media Management developer
- 159 Transactional Content Processing (TCP)
- 1.7K Web Experience Management
- 55 Tempo Social
- 1 XM Fax