Super Tips Testing Dynamics AX File Permission Access

Batch processes which use file input are very common designs in Dynamics AX, but there are often assumptions made by the AX developer as to their ability to read/write/execute files at the time they will be processed. Reading a file for input to AX is generally pretty simple, but a different permission set may be needed when AX needs to write results out to a file in a batch process. Further complicating the issue is that often these batch processes are tested with a manual run (probably processing code on the AX client) then executed in production using the automated batch process (which runs on the AOS server). If care isn’t taken to ensure that your export code can execute on the server (which is very common), you may encounter a situation where the test export runs fine, but the production batch fails writing the file.

We have a periodic routine which reads table data in AX and exports a flat text file to a file share for use by an Electronic Data Interchange (EDI) partner. Our custom class which collects the data and exports to the file runs on the client by default. In the custom class we can develop around the usual file handling problems using InteropPermissions, but when we run the export on the batch in production AX, the job failed writing the output file. The problem isn’t so much that we don’t know how to handle this scenario in code, but that our users may want a tool in AX to show them whether or not a batchable job will have access to write and output file prior to tossing it onto the batch and hoping for the best.

Our solution here will show how to borrow some code from the Application Integration Framework to test file IO permissions from both the client and server contexts given an output file path. With this tool we should be able to test file permissions before scheduling a batch job, giving us a high degree of certainty that our batch process will finish successfully.

We found some very relevant code in the AifFileSystemAdapter class, validateTransportAddress method which provides a sort of template for how we can test file path permissions.

The resulting code looks like this: