Quantcast
Channel: code.bkwDesign » Dynamics AX
Viewing all articles
Browse latest Browse all 4

Getting the AOS Machine Name

$
0
0

I had found elsewhere on the internet a little query for divining the AOS machine name. It worked great initially. However, when I deployed the code to our test environment, none of the users could run the method of this class which contained the query. Here’s the query I was using:

public static str getAOSMachineName()
{
SysClientSessions cliSessions;
SysServerSessions svrSessions;
;
select svrSessions
exists join cliSessions
where cliSessions.SessionId == sessionID()
&& cliSessions.ServerID == svrSessions.ServerId;

return substr(svrSessions.AOSId, 1, strfind(svrSessions.AOSId, ‘@’, 1, strlen(svrSessions.AOSId))-1);
}

It turns out, trying to give users the right security for the above tables was a bit difficult. These tables don’t even show up in the AOT! According to MSDN, the security keys for both SysClientSessions and SysServerSessions is AdminTables. But, it didn’t seem to matter what security mix was applied to various user groups, we couldn’t grant our users access (short of making them admins) that would allow the above query to execute. Even after wrapping it in a try/catch, I couldn’t figure out why the above query was failing to execute. Please post a comment if you know the problem I’m running into. Would love to know!

Anywho, after further experimentation, I discovered the SysServerConfig table, which does show up in the AOT. The resulting method is even shorter, and the security for this table seems to work in a straightforward fashion.

public static str getAOSMachineName()
{
SysServerConfig conf;
int atSignPosition;
;

select conf;
atSignPosition = strfind(conf.ServerId, ‘@’, 1, strlen(conf.ServerId));
atSignPosition++;

return substr(conf.ServerId, atSignPosition, 166);
}


Viewing all articles
Browse latest Browse all 4

Trending Articles