mibuso.com

I am trying to port some legacy NAV code to 2013, and it uses the MSXML automation components. However, in a web service this fails as NAV wants to issue a prompt to allow the automation component to run (i.e. Allow for this session, always allow, never allow, etc.). Is there a way to pre-allow automation components to run?

I suppose I could log in as the service account (which is currently Local System... this would need to change) and run it in a process in the GUI to allow it, but this is not a very clean method.

How did you find out that is the problem? Anything instantiated at the server doesn't pop up the dialog. It only opens when you instantiate the automation at the client.
I suggest to use dotNET type instead of automation control. The performance is much better.

Thanks for the reply.

The error is obvious enough coming from NAV, and I used the debugger to debug the web service through until it issues a CREATE statement.

Additionally, the 2013 help explicitly says not to issue a FALSE value to the OnClient parameter:



I definitely agree on the DotNet variable, but that would require a decent amount of rewrite. Right now we are just trying to get it up and running on 2013.

There should be a way to pre-allow automation components, no? I'm sure this is a registry setting or some other setting.

Since the webservice runs probably on the server, the onclient may be set to true.
Next is your conclusion: Because the webservice fails at the create issue, you instantly think it's the confirmation dialog. While it may be the automation itself that is already created (due to an omitted isclear check), or something else.

Next is the help of 2013 actually stating that when an automation is created on the server, a runtime error will appear. Which is like saying that the old onserver option is wrong and the default option of onclient is false is something like a bad joke.

Create the automation on the client (which is still the server) and see if that resolves your error.

I'm not sure if I was clear. You *have* to create an automation with the client parameter set to TRUE. It won't compile otherwise in 2013 - try it out to see the message you get.

The issue at stake here is not was the automation already instantiated. I have seen this same error before in previous NAV versions:



I have also created it in a simple processing report to confirm that it wants to prompt for access to the automation object. These are not things I need help with, but I do appreciate the input. Troubleshooting this is 100% simple - figuring out how to get around this needless security obstacle is not.

Just to reiterate back to my OP: Does anyone know how to automatically set an automation component to always allow the creation?

We set the service to run under a user account, ran a batch process to prompt for the creation of the same component and chose "always allow", but we still get the same prompt under the context of the web service. The inclusion of this prompt is frustrating, and any help is appreciated.

Also 32 bit automation are not supported on Service tier in 2013.

ara3n is right, your problem is the component itself for sure! I bet it's 32bit COM component, which won't work with 64-bit NAV service Tier...
And therefore you're forced to create the component on the client (Param Client = TRUE). I assuem even if it would be a 64bit COM Component it wouln't work because they prevent to create an instance for com objects on the server side.

Refactor your application for using .net XMLDocument Class, and your fine. Almost all methods are the same as for MSXML Automation, only syntax changes have to be done (I've done that in the past).