The Application Object Server (AOS) provides the infrastructure to execute the business logic of the Microsoft Dynamics AX application. The AOS handles the required connectivity, security, and database connection management. You can install the AOS on a single computer or on multiple computers and group these computers in a load-balanced cluster.
In Microsoft Dynamics AX 2009,you can create a single cluster or multiple clusters of AOS servers.
Microsoft Dynamics AX requires Windows-integrated authentication for all servers in the system, which means that you must be running Active Directory. For security reasons, the AOS must be installed on a Windows server operating system.
A system used for demonstrations, development, or testing can be set up to use more than one AOS instance. For details about developer installations of Microsoft Dynamics AX 2009, see the Installation Guide.
In Microsoft Dynamics AX, the AOS is implemented as a Microsoft Windows
Service to take advantage of the following features:
- Windows service applications run in the security context of a specific user account that is different from any logged-on user or the default computer account. The AOS service uses a system account for authentication during start up. This account is used by the AOS to access the file server and database server.
- A Windows service application runs in its own Windows session and takes advantage of the service control manager (SCM, a feature of the Windows Server 2003 operating system or higher) to maintain status information and to provide the user interface for managing the AOS.
- Windows services can be configured to start at system startup or upon demand, and they continue to run even when no user is logged into the system.
- Server status can be reported to the Windows event log, allowing administrators to view errors and warnings that can aid in troubleshooting problems.
The following diagram provides a view of the architecture of the AOS.
In one of my projects I was using the System.IO.StreamWriter to write data into a text file in X++. Everything went well until I started testing for exception in order to handle them (the System.IO is a .Net class that allows us to maniluplate file operations, including folders. So, I though in catching the exception with the Exception::CLRError one. )
The problem I was having was that when an exception was raised by a problem creating the file (Incorrect file name), the operation will not fall into the Exception::CRLError exception, Instead, it would just crash and I wasn't able to properly handle the exception.
The reason for this is that when using an AX class that runs on the server, the exception never comes back to the client and therefore cannot be handled correctly. I'm using the SalesFormLetter class main method to call my own class after an invoice is generated, and this class (SalesFormLetter) is (1) an abstract class and (2) runs on the server and I really did not want to do this.
A workaorund is to use the TextIO class in AX along with the FileIoPermission. For example, when using the TextIo to create (and/or overwrite) a file, we get a null value when the file could not be created (and/or overwritten). Then, we can throw an exception when the object is null.
In my case I have a central class that handles all errors, so when the TextIO object is null, I call this class and I throw an error, then the error comes back to my method and falls into the Exception::Error exception.
The following is the code
