API operations the request information from, or submit changes to, the Automation Engine are performing using XMLRequest, or subclasses thereof. The typical procedure looks something like this:
- If you are submitting AE requests asynchronously, start a response handler to handle responses from the AE.
- Instantiate an object of the XMLRequest subclass that corresponds to the operation you wish to perform. E.g., OpenObject, FolderTree, ExecuteObject, etc.
- Set any options using the methods of that class.
- Submit the XMLRequest using either sendRequest (asynchronous) or sendReqeustAndWait (synchronous).
- Use the getMessageBox method to return a MessageBox object containing the status of the request and any messages returned by the Automation Engine.
In this way, your app can be designed to handle warnings, errors, or other messages returned by the Automation Engine.
We had been operating under the assumption that the getMessageBox method would reliably tell us the overall final result of any XMLRequest operation. However, we had recently seen cases wherein getMessageBox returned null even though errors had occurred.
This morning CA Development informed me that three XMLRequest classes do not return all errors via getMessageBox. Instead, these three classes require additonal case-specific error handling: