During our AX 2012 upgrade from RTM to R3, we found that we could no longer have reports run in Batch that print via email with an attachment. This worked perfect in RTM, but R3 seems to have introduced some new .NET based classes that behave differently. I'll show you a work around we have found, while we await a response from Microsoft.
When you run a report in batch, you cannot have the printer be set to 'Screen' for obvious reasons...it isn't printing on a client computer. Instead, you can have the ERP system print the report to a network share, printer archive, or send it to you as an attachment via Email. Our users prefer the latter option, as they can have reports run once a week, once a month, and have it right in their inbox.
With R3, Microsoft added a lot of enhanced features in Print Management, specifically in the area of Tokens so that you can specify sending an Invoice to the default contact at a customer, without specifically detailing an individual email address. The system will just use whatever is most current at the time the report runs. Very handy, however I assume this is the change that prompted what we feel is buggy behavior.
If you try to email a report to yourself while running synchronously ( read: Not in batch mode ) then it will ask for you to setup Outlook. We believed this was also the problem when trying to run in batch, but it isn't. We decided to trace the process for ourselves to determine why it was failing in batch, with no infolog details or error messages. Below is our trace.
All internal AX reports use the SysOperation Framework to call the SrsReportRunService.runReport() method:
You'll see on line 40, the Printer class is populated based on what the user selected, and on line 43, the printer.printReport() method is run.
In the SrsReportRunPrinter.printReport() method, you'll see it uses a switch statement to determine the type of printer. In our case, it was of type "Email" and on line 18 it executes the toEmail() method.
Here the report is actuall rendered to a file on line 16, and then on line 30 is sent to the SrsReportRunMailer.emailReport() method.
At this point, we validate the data contract on line 16 and then use the mailer.quickSend route if we are running in batch on line 23.
Finally, things get interesting. You'll see in the parameters for this method, it has the usual suspects for an email message: from, to, subject, body, cc, and attachments. You'll see that for whatever reason, the cc string is defaulted to an empty string on line 108. Instead of an empty string however, a null is passed in.
On line 133, we see it check if the cc variable is an empty string, of which it is not as it is "null" and then attempts to add this address to the message on line 136. This ends up issuing a CLR exception with no message, so your batch will fail for no apparent reason and the email will not be sent.
Our workaround? To specify a real cc address, in addition to the "to" address. We've submitted this to Microsoft Premier, and I'll update the ticket with any details.