2

I have a script that is scheduled to run multiple times on a daily basis and is automated through TaskScheduler. Inside this script is a chunk of code to send an email when the process is completed.

When I run the script manually (without using TaskScheduler) the email gets eventually sent, through this code that is at the bottom of the script:

OutApp <- COMCreate("Outlook.Application")
    ## create an email
    outMail = OutApp$CreateItem(0)
    ## configure  email parameter
    outMail[["To"]] = paste ("xxx@xxx.com",
                             "xxx@xxx.com",
                             sep = ";", collapse = NULL)
    outMail[["subject"]] = "Some text"
    outMail[["body"]] = "Some text"
    ## send it
    outMail$Send()

But when exactly the same script runs through TS, I got this error in the log:

Error in COMCreate(guid, existing = FALSE) : Failed to create COM object: Server execution failed Calls: COMCreate -> getCOMInstance -> COMCreate Execution halted

It looks like TS is blocking the send - any workaround?

TylerH
  • 20,799
  • 66
  • 75
  • 101
Francesco Pagliara
  • 21
  • 2
  • What's the file name of your R script? I just resolved a similar issue where my script would run as expected (send email with attachment using RDCOMClient), but wouldn't run using TS. Turns out my script file name had a space in it which TS didn't like. Replaced space with understore and it worked. – macsmith Dec 02 '20 at 15:30

1 Answers1

0

Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.

If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.

As a workaround, you may consider using a low-level API (Extended MAPI) on which Outlook is based on either. Or just use any third-party wrappers around this API such as Redemption.

Eugene Astafiev
  • 47,483
  • 3
  • 24
  • 45
  • Thanks for your feedback @EugeneAstafiev, although I am not sure I have got enough knowledge to understand all of it. It sounds I cant do it basically and there is no workaround, right ? I have therefore to look for an alternative solution - if any – Francesco Pagliara Aug 09 '19 at 16:21
  • As a workaround, you may consider using a low-level API (Extended MAPI) on which Outlook is based on either. Or just use any third-party wrappers around this API such as Redemption. – Eugene Astafiev Aug 09 '19 at 17:23