how to access a file on client when you coding is executing on ser

[Huzaifa Gain]

when i try to use WinAPI::fileExistsClient method in server class.
it throws this error:
The method calls WinAPI::fileExistsClient method to check for the existence
of the given file.

The server-side impersonated (RunAs) session tried to invoke a method that
is available for client-side processing only.

how can i access files on client when my code is running on the server.

[Mykola Galak]

Hi Huzaifa,

Class WinAPI has property RunOn set to "Client". Thus it will be executed on
client.
Class WinAPIServer is dedicated for server needs.

I suspect origin of the problem is in the wrong path to file. Are you using
something like: winapi::fileExists(@"c:\folder\filename.ext)?

Mykola

[Huzaifa Gain]

WinAPIServer::fileExists gives a FileIO Permission error.

[Andy S.]

Hi Huzaifa--

One thing to consider is that if the file was specified by the user on the
client, then one likely cannot attempt to load the file from the server,
unless it's 100% certain that it's a network path. Even then, the server may
not have access to that network location.

The safest solution to this problem--if possible--is to load the file before
this process begins and store the requisite data into a list or some other
structure that is serializable. This serialized data could then be used by
the server at execution time.

Also, if this is not a headless (client-less) process running through the
new batch framework (RunBaseBatch), one could create a "static client" method
that loads the file on the client and returns the results through a
serialized list.

What version of Ax are you using and what's your precise scenario? It looks
like you're injecting your code into something being executed through
RunBaseBatch.

[Huzaifa Gain]

I am working on a batchable class that generates an electronic payment file.
when it is run by the user it generates the file but when its run through the
batch it gives an error. when using winapi::fileexistclient(filename) it
gives an impersonation error. when I use winapiserver::fileexists(filename)
it gives fileiopermission error.
also does it have to do with the runsimpersonated method as I haven't
understood what's this method used for.

[Andy S. [MS]]

What version of Ax are you working on?

To clarify your scenario, by "access a file", you mean "checking if the file
exists before you write to it?"

Thanks!

--
This posting is provided "AS IS" with no warranties, and confers no rights.

[Huzaifa Gain]

I have first check and then write, so both
AX 2009

[Andy S. [MS]]

When overridden and programmed to return true, "runsImpersonated" instructs
the batch framework to use the new and improved "headless" batching
introduced in Ax 2009. This new batching mode allows for more robust
parallelism, with dependencies (amongst many other cool things) and no need
for a host client--which is very awesome.

One side effect of the (new) headless (clientless) batch framework is that
you *cannot* run client-dependent code in that batch process--thereby
requiring that you either remove client-dependencies or branch around them
when running in batch.

In this case, I believe you've taken the correct initial approach in using
winapiserver instead of winapiclient (although I suspect the problem may be
deeper than this).

I'll ping the appropriate people about winapiserver and find out if that's a
legal call from a batched process.

In the mean time, I have a hunch that the AOS is running as a user that does
not have access to the file location specified.

To check this, do the following:
1) Locate the AOS that the batch is running on (make sure you account for
all the AOS's if running in a multi-AOS environment).
2) On the AOS machine, determine what user the AOS process is running under
by viewing the service in the Services explorer and right clicking on it,
selecting "properties" and then going to the "Log on" tab. If you're in a dev
environment, this will probably be the "NETWORK SERVICE" account.
3) On the AOS machine, browse out to the file path and verify that the
account you determined in step (2) has permissions to read and write there.
If not, you've determined your error.

If this does turn out to be the problem, I have a couple of conclusions that
I'll share with you. :)

[JoyTriviani]

hy,

I have the same problem: i can't create a file with a batch class under 2009.
My method is a server static, i use a fileiopermission.asset before a new on
asciiio class.

Is possible that there are permission problems on the service user?

How work runImpersonated?

thanks

[Andy S. [MS]]

The AOS service runs under a fixed Windows user. When you attempt to access a
file on the server, it will attempt to access the file as the user it's
running under--not the AX user--even if runsImpersonated is used.

runsImpersonated is meant to impersonate an AX user. This allows batch jobs
to run under the account of the user that created them, rather than an
ellevated system account, e.g.

I recommend that you identify which user the AOS service is running under
and verify that the identified user has access to the file(s) in question.

--
This posting is provided "AS IS" with no warranties, and confers no rights.

[JoyTriviani]

Thank you very much

[Justin Biggs]

Not sure if this behavior is specific to AX2009, but it didn't work for me in
4.0 SP1. I set an AOS user that I verified had access to the given file
location and it still threw the same error trying to create the TextIO class
object when running the code in batch (i.e. on the server).

What DID work was discovered by a co-worker of mine was using the system
class FileIOPermission. Here's a code snippet:

#File
TextIO io;
FileIOPermission permission;
;

//Explicitly ask for file permission to the
//location we want to write the file to
permission = new FileIOPermission(filename, #IO_Write);
permission.assert();

io = new TextIO(filename, #IO_Write);
if (!io)
{
throw error(strfmt("Error writing file %1",filename));
}
...
<do whatever writing you need to do here>
...

// Release permission
CodeAccessPermission::revertAssert();

This allows the process to work whether it's executing on the server or the
client. Hope this helps.
--
Best Regards,
Justin