Failure to catch exception in service method when exposed as inbound port - why?

Question Status

Alex P Brown asked a question on 10 May 2013 11:46 AM

The following service method never executes the catch block.  


public str testExceptions()


   str returnValue = "Success";



       error("Error in code.");

       throw Exception::Error;




       info("in catch block.");

       returnValue = "Caught exception #1";


   return returnValue;


The error returned from the service is:

<AifFault xmlns="" xmlns:i="">

<CustomDetailXml i:nil="true"></CustomDetailXml>

<FaultMessageListArray i:nil="true"></FaultMessageListArray>

<InfologMessageList xmlns:b="">



<b:Message>inside Message.</b:Message>




<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.


Joris de Gruyter responded on 10 May 2013 12:19 PM

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.

Alex P Brown responded on 10 May 2013 2:04 PM

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.  

Dick Wenning responded on 11 May 2013 2:43 AM

is the inbound service configured correctly, is the option return errors active.

look also in the aif exception log. what do you see?

Alex P Brown responded on 11 May 2013 8:24 AM

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?

Dick Wenning responded on 12 May 2013 12:53 AM

info and warning needs to be incapsulated, look at next lines:

 AifFault::checkFailedLogFault("what effer");

 throw AifFault::faultList("@SYS98197", #ValidationFailed);

Alex P Brown responded on 13 May 2013 9:20 AM

Does anybody know if I can avoid this transaction wrapping by using the business connector instead?

Dick Wenning responded on 19 May 2013 2:54 AM

with the BC you don't use xml it is just .net integration.

Alex P Brown responded on 20 May 2013 12:04 PM

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?

Alex P Brown responded on 20 May 2013 12:05 PM

Right.  But do you know whether my call will still be wrapped in a transaction?  Or does the BC circumvent this?