We are using DAX 2012 CU3 (feature pack version). I have a put to gather a custom SOA service to create vendor payment journals in AP/Vendor payment journals. Testing the code from VS and upon debugging it is complaining at the line of the code
if (_custVendTransOpen.checkPwpEnabled(_custVendTransOpen)) (line number 79 no customization has been done to this out of the box method) and the control doesn’t go into this method when the service is called from Visual studio. This code can be found in the CustVendOpenTransManager.updateTransMarked() method.
I do not see a problem with the code when I tested the same from the AOT by writing a job and it creates the journal and the line and marks the line in the VendTransOpen open line (in the form) and also the line is inserted in the SpecTrans table as expected. However, when I run it from the VS and call the service it is throwing error. I am trying to find out the reason why it doesn’t go into that method even when I put a break point in VS debugging (attached the AX32Serv.exe process in another VS session for debugging) when the control gets to the line of code if (_custVendTransOpen.checkPwpEnabled(_custVendTransOpen)) and doesn’t go into this and throwing some unknown exception even though when I put a break point in it. However, when I buy pass this line by dragging the control with the mouse to the specTransManager.insert() line of code in the VS it successfully creates the journal as it does when ran from the AOT. Seems like there is something not doing as it suppose when called as a service on the AOS. Have any body run into these scenarios?
I am not sure if missing something here. Any inputs will be appreciated.
SOA is “service-oriented architecture”, not a type of service. Do you mean SOAP?
Running the same code from job is actually a completely different thing - it’s executed in a different process (client vs AOS) with a different processor architecture (32-bit vs 64-bit), by different runtime (AX runtime vs CLR) executing different code (X++ vs CIL) under a different account (yours vs AOS service account) and potentially on different computers. You should test it in an environment that’s closer to what you’re trying to test. For example, you can execute code through SysOperation framework, which allows you to run it in CIL on server.
You may want to rebuild X++ and then CIL before doing anything else.
What you can tell us about the unknown exception? It must have some type, at least.
Yes, it is SOAP. I see when it runs on AOS is not same as running from the AOT. I checked to the System adiministration/Periodic /Services and appliation integration framework/Exception and I do not see anything in there. I also verified the Event viewer/windows logs/Application nothing in there either.
It doesn’t give me any exception it simply doesn’t go into the method . I have put a try {} catch{} block in the CustVendOpenTransManager.updateTransMarked() to get the specifics of the exception still no luck.
I was able to get the exception. Please ignore my previous post. Here is the exception it is complaining about
nnerException {“Unable to cast object of type ‘Dynamics.Ax.Application.CustVendTransOpen’ to type ‘Dynamics.Ax.Application.VendTransOpen’.”} System.Exception {System.InvalidCastException}
Message “Exception has been thrown by the target of an invocation.” string
OK, [CustVendTransOpen] is a map, [VendTransOpen] is a table, definitely cannot cast the type there. You will have to do some manipulation through X++.
Thanks all for the inputs. Ran into similar situations before as well. Here is the code I put together to cast CustVendTransOpen map to VendTransOpen and it seems like working now
VendTransOpen vendTransOpenLocal;//declare a local variable for the VendTransOpen
if (_custVendTransOpen.TableId == tableNum(VendTransOpen))
{
vendTransOpenLocal = _custVendTransOpen;
}
if (isConfigurationkeyEnabled(configurationKeyNum(PSAPwp)) && (_custVendTransOpen.TableId == tableNum(VendTransOpen)))
{
if (_custVendTransOpen.checkPwpEnabled(vendTransOpenLocal))//pass in the vendTransOpenLocal instead of _custVendTransOpen
…
CLR appears to be very strict when it comes to type casting where x++ obviously not. I see why all the DAX objects are being compiled into CLR in the latest versions of DAX.