The following service method never executes the catch block.
public str testExceptions()
str returnValue = "Success";
error("Error in code.");
info("in catch block.");
returnValue = "Caught exception #1";
The error returned from the service is:
<AifFault xmlns="schemas.microsoft.com/.../Fault" xmlns:i="www.w3.org/.../XMLSchema-instance">
<b:Message>inside Error in code.</b:Message>
at Dynamics.Ax.Application.CCPreAuthorizeService.Testexceptions() in CCPreAuthorizeService.testExceptions.xpp:line 13
at Microsoft.Dynamics.Ax.Services.SHICCPreAuthorizationService.Microsoft.Dynamics.Ax.Services.SHICCPreAuthorizeService.Testexceptions(SHICCPreAuthorizeServiceTestExceptionsRequest testExceptionsRequest)
The same method returns successfully - returning "Caught Exception #1" when executed from a job or within AX.
I suspect that (because AX does not support catching exceptions from within transactions) this is because the service is somehow wrapping this in a transaction, but I can't figure out how to circumvent that.
Does anyone have any insight? Is anybody able to replicate? Thanks in advance.
You can call the global "appl" variable and ask for the tts level (appl.ttsLevel()). Anything bigger than 0 means you're inside a transaction. That should give you the answer on the transaction scope at least.
I have no personal experience with catching transactions in a service, so no direct opinions there.
Dynamics AX MVP | My Blog | Sikich | Twitter @JorisdG
The answer is yes. We already verified that we are in a transaction in that way and also, aborting that transaction and then doing our operation also does not seem to solve the problem.
is the inbound service configured correctly, is the option return errors active.
look also in the aif exception log. what do you see?
+31 6 147 989 53
3905 PE - Veenendaal
OTHER CONTACT INFORMATION
We did turn on the option to show errors and they are being reported in the exception log. But the error message is the message in the try block, not the catch block.
Is there some way to prevent the service from wrapping it in a transaction so that it can catch the error?
info and warning needs to be incapsulated, look at next lines:
throw AifFault::faultList("@SYS98197", #ValidationFailed);
Does anybody know if I can avoid this transaction wrapping by using the business connector instead?
with the BC you don't use xml it is just .net integration.
That is a great trick, thanks for that!
Unfortunately, it does not seem to help with figuring out why the inbound port is wrapping my method in a transaction. Any other ideas?
Right. But do you know whether my call will still be wrapped in a transaction? Or does the BC circumvent this?