ArcherPoint Microsoft Dynamics NAV Developer Digest - vol 23
The ArcherPoint technical staff—made up of developers, project managers, and consultants – is constantly communicating internally, with the goal of sharing helpful information with one another.
As they run into issues and questions, find the answers, and make new discoveries, they post them companywide on Yammer for everyone’s benefit. We in Marketing watch these interactions and never cease to be amazed by the creativity, dedication, and brainpower we’re so fortunate to have in this group—so we thought, wouldn’t it be great to share them with the rest of the Microsoft Dynamics NAV Community? So, the ArcherPoint Microsoft Dynamics NAV Developer Digest was born. Each week, we present a collection of thoughts and findings from the ArcherPoint staff. We hope these insights will benefit you, too.
Question regarding XML conversion to 2013R2:
Question: I have a client that is using a version of the NAV base codeunit 6224 “XML DOM Management” to interact w/ some of their web services features. They are currently on 2009sp1 and want to upgrade to 2013R2. I recall that Automation Controls cannot work in 2013x versions and have to be reconfigured to .Net interoperability instead.
Discussion: You can still use the XML DOM, but it must be changed to run client side and not on the service tier. That said usually the things for which the DOM was used can be converted to XMLports.
Alternatively, you can use one of the .NET libraries (XMLReader, XMLWriter, Link libraries) instead. This is probably more work, but it may be faster depending on the application. There are other options in the .NET world also if that is going to be explored. Probably need to review the usage and volume of the changes.
I’m thinking this code is used with regard to web services, so it will be used server side, so it must be converted to DotNet Interop.
Conclusion: Since the base codeunit 6224 still exists in newer versions of Nav2013x, it is still possible to use that for the process(es) that were using it for before. In the newer version of codeunit 6224 (same name), they just swapped out all references to Automation Controls w/ the newer DotNet type. Same functions, just now using DotNet.
Notes on bypassing the commit of Report Logging:
Interesting find on the Report Logger. We tested the Login and EndLogin triggers to see if rogue shutdowns would bypass the commit of the report logging data. The log is written to a temp table while the user is logged in. The temp table is necessary due to illegal transaction errors that can occur on the run report triggers during some transactions. So, we commit the log on the EndLogin trigger. What we found was that when logging out using the “x”, or even Ctl-Alt-Delete, the trigger is executed properly. So, the only way a user can improperly log off, thus bypassing the commit, would be to unplug the computer, which apparently happens sometimes, especially in warehouse settings.
Question regarding exposing the To-Do table on Web Services:
Question: Is the To-Do table exposable on Web Services?
Answer: The To-Do page is accessible. It needs to be added in the web service setup. There also needs to be a web service running. I think it runs by default. Also, if it needs to be accessible outside your domain, that will take some extra security setup, so, a dev/tech resource would need to get involved.
Be sure to read more ArcherPoint developer blogs. If you have any further questions about customizing in NAV, please feel free to contact any of the NAV experts at ArcherPoint.