daxis: Dynamics Ax 4.0 Session Types

[Blog bot]

Источник: http://blogs.msdn.com/daxis/archive/...anagement.aspx
==============

In this blog post I will provide details on the management of the various user sessions inside the Dynamics Ax server (AOS). I will use the Online users form as a reference to provide context to the material provided below. I hope to provide answers to some of your questions regarding various session types with my post.

Background and Basics

In versions prior to 4.0, Dynamics Ax used to persist the session information in a file which had a “.udb “extension. This file was stored along with the other application files and it had data about the current servers and rich clients (Ax32.exe) currently running in a deployment. Due to scalability and stability concerns we changed the architecture significantly in 4.0 and moved this information to the backend database.

In the 4.0 release the following database components are responsible for persisting and managing the session information in the database

· SysServerSessions table – This table is used to manage the AOS instances. Each running AOS in an installation has a row in this table with the STATUS column equal to 1.

· SysClientSessions table – This table is used to manage the various client sessions connected to different AOS servers. Each client session has a row in this table with the STATUS column equal to 1.

· CREATESERVERSESSIONS stored procedure – This stored procedure is used to populate the SysServerSessions table. This stored procedure is invoked during the startup of an AOS server.

· CREATEUSERSESSIONS stored procedure – This stored procedure is used to populate the SysClientSessions table. This stored procedure is invoked each time a client is launched.

The stored procedures main purpose is to provide a unique ID which is used as an identifier for each session in the AOS. They are also used to enforce the license checks which limit the number of concurrent active sessions based on the numbers specified in the license file.

You don’t need to access the database to get a glimpse of the session data as most of this information is exposed via the Online users form that is available to administrators. You can also use the xSession API to programmatically access the session related information.

Online Users Form – Server Instances

You can use this tab in the form to get information on both the current AOS instances and client sessions. Let’s first take a quick look at the Server Instances tab.





Most of the information is quite obvious but there is couple of things I would like to point out.

· Server instance name is based on the name that is specified in the server configuration. You can use this name to identify each AOS in your installation, you can also use the port information if you are running multiple AOS installations on the same machine.

· Status – This column should indicate “Alive” which represents an active AOS server that is accepting new clients. There are 2 other special states that you should be aware of. These are:

o Dead – Each AOS server has a background thread that pings the database periodically at an interval of 5 minutes. If the AOS does not ping the database then its status is set to “Dead” in the form. Usually this will happen if the AOS has terminated due to an unexpected situation. After an interval of 6 hours one of the other AOS servers running in the same database will update the STATUS column in the SysClientSessions table to 0 for the client sessions rows belonging to the dead AOS server. This prevents a dead AOS from forever consuming licenses by making the system count the client sessions that were still connected to it when it went down.

o Draining – In this state the AOS will not accept new clients and you can trigger the AOS to enter this state by clicking the “Reject new clients” button. You should use this button to manage the load balancing properties of an AOS.

Now let’s look at the other tab containing client sessions information, this tab has lot more interesting data that can be sometimes used for troubleshooting session related issues.

Online Users Form – Client Sessions

You can this form to keep track of all the active client sessions in the system. You can check when the client logged on, the AOS it is connect to and its session id.





I will now describe some of the interesting columns from this grid.

· Session type – This column is used to provide information on the client type. The following client types are valid client types in Dynamics Ax.

o User – This corresponds to the rich client (Ax32.exe). For each rich client instance that is running there will be a row in this tab representing that client with this user type.

o Business Connector – This is used to represent the session that is established when the Logon or LogonAs methods are called using the Business Connector (BC).

o Worker – This session type is overloaded to represent different session types but it is primarily seen in the context of the Business Connector. When BC is used to connect to an AOS, 2 sessions are initially created. The Worker session type corresponds to the main session that is used to represent the BC process. Each time a Logon related method is called a Business Connector session is created, when LogOff is called then the Business Connector session type is removed from the AOS memory and in the database. But the Worker session will be present as long as the BC process is active. This is the reason why there are at 2 sessions shown in the Online users form when connecting using BC.

o Web user – This session type corresponds to an Enterprise Portal (EP) session which is created when using a web browser. EP uses BC as the underlying infrastructure to connect to the AOS so you will see a corresponding Business Connector session in the Online users form. The Business Connector session that is created when using EP is actually a Worker session inside the AOS but it is represented as a Business Connector session in the database because of the way licenses are counted for EP sessions. I will provide more details about the number of licenses consumed for different session types in a later post. One thing to note is that the web user sessions are transient in nature because EP uses session caching and the web user sessions have a very short lifetime as they often map to web page based requests.

o Impersonated session – This session type is created when using the RunAs method in X++.

· Status – This represents the status of the client session. Currently the only value that this column shows is “Running” which represents an active client.

· SPIDs – This column give you the SPID of the connection currently being used by that client. The Ax server uses a connection pool where connections are given to a session on an on-demand basis from a cache. One consequence of this functionality is that if you might not see any SPID for a particular session at that instant if that session is not executing a SQL statement. SPIDS are valuable to troubleshoot database deadlock issues and you can use the functionality provided by the “End Sessions” button to terminate any blocking user. There are various tools available to troubleshoot deadlocks and investigate database blocking issues but I will address that in greater detail in a separate post.

I hope this information has helped you in understanding some aspects of session management inside Dynamics Ax. We are making some enhancements to the online users form in the next release and we would like to hear your comments and feedback in this area.

We plan to have more articles on related areas explaining topics like load balancing, database deadlock troubleshooting etc. We would also like to know if there are any specific topics that you will like to be covered using this forum.

Thanks,

Amar Nalla





Источник: http://blogs.msdn.com/daxis/archive/...anagement.aspx