I have a table with a post insert trigger that would invoke a logic block, which would update Directory with emails subtable, etc. I ran into an error message:
Error(s) occurred processing event. MessageId: “2a3bd3f2-f045-4991-bac0-6a47623a7cb0”. Error Descriptions: "Only one primary email is allowed.
My question is there anyway to log the state of the subtable (in some message that is accessible) before calling the WriteDirectory logic block?
Here is the screenshot of he stacktrace:
Hi David! Yes, you can accomplish this via the Log Message action and Application Monitoring.
In your logic block, add a “Log Message” action with the information you want to log. Then, when you run Application Monitoring (see the “Application Monitoring” help topic for more detail), the info you log via Log Message will show up as a data point during your monitoring session.
At this time the two things to be aware of that are different when debugging vs not debugging are these:
Timing. When debugging any async work (i.e. batch job) inherits the debug attribute. That other process shows up as a separate debug session in the debugging tool and waits for instructions (step/run/etc) instead of immediately beginning to execute.
Select behavior. When debugging all DB queries are altered from SELECT to SELECT *. This unfortunate discrepancy in behavior is necessary to enable conditional breakpoints based on values that are not otherwise needed for the logic flow.
To diagnose which of these causes the works/doesn’t work difference you are seeing:
Race condition is a logic flaw in the application. There is no guarantee about when the secondary process executes.
Difference because of the DB query is a platform bug and needs reported along with steps to reproduce. The choice of querying a named set of fields vs all fields should not result in a functional difference.
Hi Brendan, I did read the Application Monitoring utility. It looks like it will monitor the activities upon user interfaction with the application. However, in my case, it is triggered via an inbound integration endpoint that writes a record to a table that has as post-insert trigger to call the logic block in question.
Yeah, in my case, we have an extended table that has 8 update triggers :-).
Question: if there are multiple triggers defined on a table, what will be the order of invocation? Is it by the order listed in the Triggers tab for that table?
I might consider turning off the suspicious trigger(s) to see if the error would go away.
@david.lee If it might help, to see results in Application Monitoring when you’re making an inbound endpoint call, add a NwPerformanceTrackingSessionId header parameter to the call specifying some unique identifier. After the call is complete you should see data in Application Monitoring corresponding to the call that can be analyzed.
The order of execution/invocation of triggers from the base and extension tables cannot be guaranteed @david.lee. If you need certain pieces of logic to execute in a given order i would suggest having one extension trigger defined on the table, and then have that trigger call the other logic blocks in the desired order.
Yeah, that is my next step to do.
For test environment, I can add it to the inbound request header. If I leave it there for production environment, would it cause performance issues?
That header should only be added case-by-case on specific calls that need monitored, not all calls that get made to a Nextworld endpoint. It will meaningfully degrade performance if added to all calls.
