Creating Sessions

The key to writing script for  MES is the session.

To use any functionality, you must first create a session.

You use the aaFactMES.aaClientSession object to create and manage a session. There is only one aaFactMES.aaClientSession object created for an application, but there may be many references to that object. 

You get a reference to the object by calling the aaFactMES.aaClientSession.GetInstance method. The first time this method is called, it creates the object; all subsequent calls return a reference to that object.

For an example, see the sample Init script in Starting Sessions.

Understanding the Client Session

An understanding of the Client Session class is important when developing any client application. When instantiated, the Client Session is a stateful object that authorizes the client to access the Middleware (i.e., handles licensing and security checks) and maintains commonly required information pertaining to the current users, jobs, etc that can be accessed simply via properties of the object.

Generally speaking, the creation of a Client Session and a login is required before any other MES operations can be performed using the client API as these methods will be validated based on a valid user and the user's privileges.

There is only one instance of the Client Session created for an application but there may be many references to that object.

It is important to note from this statement that the Client Session is application specific and this relates to where the script is executed. If the script is part of an System Platform object script then the script is executed on the Object Server under the App Engine hosting the object and so the Client Session is associated with that Object Server/App Engine. Any other System Platform objects running scripts under that App Engine can access this Client Session. If the script is part of a graphic symbol (whether inside an System Platform object or not) and that graphic is run in an InTouch application then the Client Session is associated with the InTouch View application.

This is an important concept to be aware of. For example, the MES .NET controls that are covered in a later section create and reference a Client Session associated with the InTouch application that is hosting the control. If other System Platform graphics are used in that environment that include graphics based script, then that script will reference the same Session. However, if the script is run in the System Platform object rather than the graphic it will have no reference to this Session but will rather reference the Session resident on the Object Server.

Furthermore, any objects developed with server side scripting that are to be used for client side access to the middleware will need to have the client session credentials passed to the objects.

These concepts are covered more in the section on development tiers.

The Client Session Class does not contain all the calls a developer might expect. One way to think of the Client Session is to consider what is available through the Operator application. The majority of the functionality of Operator is exposed through the Client Session (and contained classes). If a specific functionality is not found in the Stateful API, then please use the Stateless API, which includes additional functionality.

Client Session Class Structure

The structure of the Client Session class is explained in the following diagram:

Note that in this diagram not all methods and properties are shown.

The 'aaClientSession' class exposes a number of methods to get an instance, create a session and logon users. It maintains a number of stateful objects exposed as properties such as

• SystemAttrs is an 'aaSystemAttrs' class instance that provides access to the values of all the general system parameters set in the database.
• curUser is an 'aaUser' class instance that is set to the last user that was logged on and can be altered by using the 'SwitchUser' method.
• curEnt is an 'aaEnt' class instance set to the last entity that the user logged onto. This can be set via script to any entity the user has logged into.
• JobExec is an 'aaJobExec' class instance that by default is set to the currently running job (on the current entity).
• UtilExec is an 'aaUtilExec' class instance that provides utilization information for the current entity.

So by simply creating a session and logging onto a session and entities there is a lot of information that is maintained as properties for easy access when scripting.