I have an email template that I want to observe the steps of the preparation so I can understand what is wrong with it. I can set breakpoints in the email template's preparation, but the debugger will not stop on them.
The email template is being sent from a screen action in a web block. I need to debug what happens in the preparation of the actual email template being sent.
I haven't seen where this is not possible in all my reading today on sending emails, but it is never addressed specifically. Is there something different that I need to do aside of launching the debugger?
Thanks for your help!
Hello Jason,
I never had a probl to debug email preparations before.
But they have a characteristic that is similar to the timers. They are executed in their own session and launched by a service in the server, not your app.
This means that you can't debug in your personal area (F6). You need to have your Service Studio debugging in the public area.
Not that this is the problem, but if you are debugging your application on personal are, try to do it in the public area.
Another possibility is that the service is not even reaching the email preparation.
Did you check in Service Center monitoring tab to see if it is trying to send the mail? And eventually what is the error?
Cheers.
Thanks for that pointer. All of my code was functioning, emails being sent, preparations running, etc but the fact I couldn't hit a breakpoint was disturbing. I did not have problems with the code. I only needed to see the data coming back from one of the calls.
Jason Pirok wrote:
In that kind of situation, I'll sometimes set up a test harness to call the action/function that returns the data, so I can view it more easily. Debugging via breakpoints is only one tool in the developer's toolbox. :-)
Questions:
In Order:
"That is work that I shouldn't have to do."
Perhaps I wasn't clear what I meant regarding extracting logic to a separate Server Action.
When something doesn't work, whether it's code, electronics, mechanical, I follow some basic troubleshooting questions or procedures:
What I asked regarding moving the logic to a separate Server Action falls under the third category. Not saying you should necessarily always have a separate Server Action (though that can make sense sometimes), but rather that if the logic in the preparation works and can be debugged in a Server Action, that may give you useful information in troubleshooting.