In response to your comment above...
First of all, by "web service account" I don't mean web services. I mean the service account on the web server under which the web application runs. This could perhaps be the account of the user logged in to the website, or the default IIS account, etc. The best way to address this would be to fully qualify the path to soffice.exe
when calling it, that way you don't have to worry about the PATH
environment variable. (Additionally, you don't have to worry as much about another application being run maliciously or by accident and doing something unexpected with unknown permissions.)
Second, there seems to be a critical design flaw in your approach. Even if you do manage to get the application to launch on the server, it's going to launch on the server. Is the resource manager sitting at the actual web server? If not, then opening the file in the application on the server will do him no good whatsoever. If he is sitting at the server, then he's the only person who can use this.
You don't want to open the file on the server. You want to deliver the file to the client. Then if the user (the resource manager in your example) can open the file in soffice.exe
on his local machine. If his environment is set up correctly, it should open automatically. (Though the browser will also give him the option to save the file locally and then open it.) Simply linking to the file should suffice. Is there any particular reason why it wouldn't?
If you need to use a form post rather than simply a link in order to deliver the file, you can still stream the file from your server-side code. Here's a previous question discussing how to do that. Basically the process involves clearing the output buffer, setting the headers (content length, content type, suggested file name, etc.), streaming the bytes, and flushing/closing the output buffer.