Saturday, February 17. 2007Monitoring Recurring Batch Jobs via .NETI'm currently in the process of migrating our Axapta 3.0 system over to Dynamics Ax 4.0. This is a difficult process due to the number of customisations we have made in the system, and many changes between the two standard code-beds. In light of this, we've been conscious of new developments on the horizon, so some of our customisations had temporary snippets of code in them, waiting for enhancements such as .NET interoperability. One of these temporary snippets of code is responsible for monitoring recurring batch job execution, and ultimately the use of a monitoring system completely outside of Dynamics Ax is preferable. This is where the .NET Business Connector steps in, and since a small number of licenses come with the base Dynamics Ax product, it can be a really useful development tool. Most of what's written here will also apply to the old COM Connector, in principle. Firstly, a bit the back story here. We use Nagios heavily for monitoring all of our systems at the office, often in combination with NRPE-NT. I've put together quite a few custom plug-ins (read: quick and dirty hacks) myself to assist in monitoring some awkward processes we have. We have recurring batch jobs within Axapta which do many important things such as importing information from within flat files such as customer records and inventory from legacy systems, and sometimes due to reasons out of our control, they fail. The reasons might include the batch process machine losing network connectivity, or a power failure that made the UPS shut down the machines, and so forth. In the past, since we had no COM licenses, I jury rigged a system which would use the XmlHttp* classes that were available within Axapta 3.0 to post one line of text to a waiting CGI program on a Linux machine where Nagios resides. This line of text was the class name, and the result would be a zero-byte file with the same class name would have its modified-time changed. This call was made at the end of a recurring batch job run within the BatchRun class. A Nagios plug-in would then calculate the time delta on the modified file time to determine if the batch job had run recently enough. Obviously, this solution is flaky, but still fairly reliable. A better solution, however, is one which would not modify standard Axapta, and one that can determine, independent of the batch processor, the status of a batch job. We know that we can determine if a recurring batch job is running happily by looking in the Batch table, so the obvious solution is to have a Nagios plug-in that connects to Axapta to find these details. Within your own code, make sure you reference the .NET assembly Microsoft.Dynamics.BusinessConnectorNet, and use this reference in your code. You'll find this (if you've installed the connector) as a DLL file within the bin directory of your client's installation. All primary functions are carried out through the object Microsoft.Dynamics.BusinessConnectorNet.Axapta, for which you'll need to instantiate and then logon and subsequently logoff from Ax with. To log into Ax, you have a few choices. The easiest normally would be to use the Ax configuration on the system for the current user using Axapta::Logon(). Here's an example in C#:
Alternatively, you can also specify a specific username/password, keeping in mind that user logins within Ax are based on users within the windows domain. You can also specify other things such as the language and company, along with the specific object server as well. From the Axapta object, you can then create reference objects to records (table cursors) and other objects (classes) within Ax itself. To do this, you use the Axapta::GetRecord() and Axapta::GetObject() methods respectively. You can directly call static methods within classes and tables too, using Axapta::CallStaticRecordMethod(). As an example, I'll use C# to connect to Ax and pull back a customer's name:
The connector is really very simple, allowing you to use table/field names or their ID numbers within the system. The connector can have an unlimited number of parameters for method calls, either using a small number of additional parameters or passing the parameters as an object[] (array). Exceptions are a little odd, since you have normal exceptions along with the exceptions from X++, which messes things up a little at times. To do batch monitoring, I chose C# over my usual preference of C++ as our company is moving towards C#.NET as a "corporate standard". I check the main bit of the source code around line 183 to see how I connected to Axapta. You'll see that I've worked in two different login options, and I'm using a fairly simple X++ select statement to pull data back from the Batch table. The full source-code is available under the GNU GPL and can be found on SourceForge, where you can also easily browse the source code too. If you're lazy and just want the monitoring software, you can go ahead and download it. For this code to work, you'll need Nagios setup, using the check_nrpe plug-in to run this checkdaxbatch plug-in using an instance of NRPE-NT on a windows machine somewhere. Enjoy! Comments
Display comments as
(Linear | Threaded)
No comments The author does not allow comments to this entry
|
Calendar
Creative Commons |
Simon Butcher on : Monitoring Dynamics AX with Nagios