Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: MatthiasVDE on October 13, 2016, 01:34:15 am
-
I wrote a C# application for exporting html reports. When I run the .exe manually it works fine, but when it starts from a scheduled task I get the following error:
The remote procedure call failed. (Exception from HRESULT: 0x800706BE)
EA.Repository repo = new EA.Repository();
repo.OpenFile(conn); --> The error is on this line.
-
It would probably help seeing the contents of conn.
q.
-
string conn = @"C:\EA\Shortcut.eap";
But how can you explain that it only fails when the application is executed by the scheduler?
-
EA needs a user to be logged in.
This does work as a scheduled task only if the user is still logged on, not when executed as a service.
Geert
-
EA needs a user to be logged in.
This does work as a scheduled task only if the user is still logged on, not when executed as a service.
Geert
So it is'n possible to schedule/plan an export?
-
Only with a logged-on user. We did that using a work station sitting somewhere with a user logged on and a sign telling "Do not switch off".
q.
-
Only with a logged-on user. We did that using a work station sitting somewhere with a user logged on and a sign telling "Do not switch off".
q.
It seems to me that Sparx should allow the specification of the user on the command line - say the service account being used for the job and also the ability to run a script from the command line (as with most other Desktop /Office product). That would greatly help in automating processes for unattended repository maintenance.
Paolo
-
]It seems to me that Sparx should allow the specification of the user on the command line - say the service account being used for the job and also the ability to run a script from the command line (as with most other Desktop /Office product). That would greatly help in automating processes for unattended repository maintenance.
Why would they replicate the functionality of runas or the command scheduler?
Edit: Or the PoSH Start-Process cmdlet.
-
Chiming in,
This issue is a very annoying one, and it's one which, I'm quite certain, prevents adoption of EA in larger organisations. You can't claim to have an automation capability if your automated tasks require people to be present.
They did introduce scheduled tasks (http://sparxsystems.com/enterprise_architect_user_guide/13.0/model_repository/additional_functionality_using.html) with the cloud service a few years back, but "currently" (since then) that's limited to updating a time series chart. (Has anyone ever used that, btw?)
Anyway, seems to me this is the way forward. Clearly the cloud service runs fine under a service account and can do all the things the GUI can.
I would suggest adding the following capabilities to the cloud service task scheduler, in order of priority:
- Run a named script. This covers everything you can do through the API.
- Run an HTML dump.
- Run a document generation from a master/model document.
Things can be added to this list of course, but really the script thing should be enough and everything else should be added to the API.
/Uffe
-
Clearly the cloud service runs fine under a service account and can do all the things the GUI can.
Actually, the cloud service doesn't directly include EA functionality. It's a thin wrapper around a database that EA can use.
The Windows task scheduler has the ability to specify a user to run as (including saving the password if they aren't logged in) and EA can be started and used from an external JScript/VBScript. That has been sufficient for my needs in the past.
Are either of those not working?
-
The Windows task scheduler has the ability to specify a user to run as (including saving the password if they aren't logged in) and EA can be started and used from an external JScript/VBScript. That has been sufficient for my needs in the past.
Surely you've learnt Powershell by now? 8)
-
Clearly the cloud service runs fine under a service account and can do all the things the GUI can.
Actually, the cloud service doesn't directly include EA functionality. It's a thin wrapper around a database that EA can use.
Ow. Ow. Ouch.
But it's not SQL between the EA client and the cloud service, surely?
So if you published the interface, allowing custom-built clients to connect to the cloud server, that should work.
The Windows task scheduler has the ability to specify a user to run as (including saving the password if they aren't logged in) and EA can be started and used from an external JScript/VBScript. That has been sufficient for my needs in the past.
Are either of those not working?
Well I'm not the OP, but what I need is automation that can run on a server in a server context -- without a GUI, and under an unprivileged service account. The primary use cases for this concern import and export of information to/from a project: hypertext/document generation, synchronization with other data sources, version control.
/U
-
Clearly the cloud service runs fine under a service account and can do all the things the GUI can.
Actually, the cloud service doesn't directly include EA functionality. It's a thin wrapper around a database that EA can use.
Ow. Ow. Ouch.
But it's not SQL between the EA client and the cloud service, surely?
I'm pretty sure it's not much more then a database access layer, possibly grouping some SQL statements to gain some performance. Almost certain it contains no business logic at all, and it doesn't use the EA core or API.
Geert
-
Surely you've learnt Powershell by now? 8)
Yes, I've toyed with it, but I haven't seen a need to re-write my scripts.
-
I don't think this is an EA problem - this sounds like the user account running the Scheduled Task (possibly SYSTEM) does not have access to the file you're specifying.
What credentials are you running the Scheduled Task under? You could do one of the following:
1) (recommended) Create a new local user on the PC, and give it full access to the folder. Changed the scheduled task to "run as" this user (saving the password).
2) Just use your credentials in the "Run as...". This means storing your password with the task, which you probably don't want to do if it's a network account.