Job Queue: Callbacks not supported running excel

asmilie2b

We are in the throws of upgrading to 2013.
I am trying to set up our job queues on 2013, and am receiving the below "Callback not supported.." error on one of them. The job queue is calling a codeunit which runs an excel (excel buffer) report. (I know not good to run excel like this but it always worked..). It would seem that there is SOME kind of a dialog being thrown up, though I know it is not from my CU or report as this always worked on 5.1. I thought it might be related to this, perhaps a permission screen is comming up running the automation for the first time. If so how to clear it?! Any advice apreciated.

viewtopic.php?f=32&t=57992&hilit=Client+callbacks+are+not+supported+on+Microsoft+Dynamics+NAV+Server

Server instance: DynamicsNAV70UAT
Session type: Background
Session ID: 8
User:
Type: Microsoft.Dynamics.Nav.Types.Exceptions.NavNCLCallbackNotAllowedException
SuppressMessage: False
FatalityScope: None
Message: Microsoft Dynamics NAV Server attempted to issue a client callback to create an Automation object: 00024500-0000-0000-c000-000000000046 (Report 50091 PAC RAC State Unit Sales -Auto). Client callbacks are not supported on Microsoft Dynamics NAV Server.
StackTrace:
at Microsoft.Dynamics.Nav.Runtime.HeadlessClientCallback.CreateAutomationObject(Guid classId, String licenseKey, Boolean newServer)
at Microsoft.Dynamics.Nav.Runtime.NavAutomation.Create(DataError errorLevel, Boolean newServer, Boolean clientSide)
Source: Microsoft.Dynamics.Nav.Ncl
HResult: -2146233088

asmilie2b

As a test I tried logging in as the domain user that is set to run the NAS, and ran the codeunit manually. I received the screen warning about running the automation, and I clicked "Always allow". Then tried running again from the NAS but the result was the same. So perhaps it isn't the automation warning message doing this. I guess I will have to debug the NAS... #-o

BardurKnudsen

I assume you are using Excel via table 370. The NAS process runs on the server (NST) while the Excel interop (xlApp) is declared as RunOnClient=Yes. Since there is no client, the creation of this variable will fail.
Apart from this, it is generally adviced not to run office apps on a server because the applications are not thread safe, so if one instance of an application is running, started by user A, user B may or may not be interacting with user A's instance.

If you really want to do this anyway, you could create your own variant of table 370, but with the interop variables set to RunOnClient=No. Or even better; just remove the parts where you start excel (e.g. in function GiveUserControl) and let the server create the xlsx document serverside and then do with it what you want (I assume you want it either stored or sent to someone).

asmilie2b

Many thanks Badur for the response.
As this excel get's created and then emailed, there is no need for any control to excel to be given. So first I think I will try removing those parts first.

asmilie2b

I have checked into this further.
I was able to confirm the report that exports to excel using excel buffer never gives control to the user. GiveUserControl is never called, the automation never set to visible.

I tried also creating a copy of excel buffer table, making all of the dotnet automations RunOnClient=No. Still the result is the same.
I may just change the report to create a text file instead of an excel file for now to get around this. But would love to hear any other thoughts.