Question Status

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

The following service method never executes the catch block.  

[SysEntryPointAttribute(false)]

public str testExceptions()

{

   str returnValue = "Success";

   try

   {

       error("Error in code.");

       throw Exception::Error;

   }

   catch

   {

       info("in catch block.");

       returnValue = "Caught exception #1";

   }

   return returnValue;

}

The error returned from the service is:

<AifFault xmlns="schemas.microsoft.com/.../Fault" xmlns:i="www.w3.org/.../XMLSchema-instance">

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

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

<InfologMessageList xmlns:b="schemas.datacontract.org/.../Microsoft.Dynamics.AX.Framework.Services">

<b:InfologMessage>

<b:InfologMessageType>Info</b:InfologMessageType>

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

</b:InfologMessage>

<b:InfologMessage>

<b:InfologMessageType>Error</b:InfologMessageType>

<b:Message>inside Error in code.</b:Message>

</b:InfologMessage>

</InfologMessageList>

<StackTrace>

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)

</StackTrace>

<XppExceptionType>3</XppExceptionType>

</AifFault>

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.

APB

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

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

Reply
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?

Kind regards, 

Kaya Solutions

Dick Wenning

+31 6 147 989 53 

Landjuweel 5

3905 PE - Veenendaal

 

OTHER CONTACT INFORMATION

Reply
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?

Reply
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);

Kind regards, 

Kaya Solutions

Dick Wenning

+31 6 147 989 53 

Landjuweel 5

3905 PE - Veenendaal

 

OTHER CONTACT INFORMATION

Reply
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?

Reply
Dick Wenning responded on 19 May 2013 2:54 AM

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

Kind regards, 

Kaya Solutions

Dick Wenning

+31 6 147 989 53 

Landjuweel 5

3905 PE - Veenendaal

 

OTHER CONTACT INFORMATION

Reply
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?

Reply
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?

APB

Reply