Dynamics GP 2013 Web Client Infrastructure Overview

  • Article

Aaront Donat - Click for blog homepageWith the newly announced release of Microsoft Dynamics 2013 Beta to all partners, what better time to begin talking about the Dynamics GP Web Client since there is HUGE excitement around this feature.  With the "BUZZ" floating around the Fargo campus this week, now is the time to start sharing the foundation of what GP Web Client really is, what are those required and deployed components and how does this product actually function. Over the next few posts, I will be covering these dependencies attempting to get you to started thinking about the GP Web Client as much as you think about Dynamics GP today. We all realize that in order to have a successful deployments, the single most important component in any deployment is the pre-planning and coordination effort. We want to help you in that planning and coordination and will do the best we can through documentation and videos. With that said, everyone's focus right now is getting the GP Web Client up running in your environment and begin understanding the requirements so you can position and sell it to our customers.

In this blog, I want to spend time talking about the components that comprise a GP Web Client deployment. Understanding the components of the Web Client will be key in your planning and troubleshooting efforts.  There are 9 specific components involved with getting the GP Web Client to function. Out of those 9 components, I would like to call out 4 components that I consider KEY and are troubleshooting components.  This four components are:

  • Session Central Service
  • Session Host
  • Session Service
  • Runtime Service

Below is the architecture design flow of how these components are connected with each other. 

 

IIS/GP Web - This is the Internet Information Services website that will serve up the GP Web aspx pages and the GP Web Silverlight application.  This will be the entry point for users interacting with GP Web by processing their logon information, show existing sessions, create a new session, recover an existing session, and ultimately launch the GP Web Silverlight application. The virtual directory is named GP.  Other facts about this component:

  • Must be deployed under a Web Site that has been enabled for SSL
  • Contains 5 .aspx pages:
      
  • Logon.aspx - This is the primary login page for GP Web Client
  • Session.aspx - This is the page that displays existing session for the user.  It allows the user to re-connect to an active session that they had disconnected from.
  • GPWeb.aspx - This is the page in which the Silverlight application runs in
  • Errors.aspx - This is the page that displays any exception that occurs within the Web Site code
  • Default.aspx - This is a hidden page that is used for re-direction back to the Login.aspx or Session.aspx pages

 

The relationship between these .aspx file is displayed below. What makes this Web Application different than others, is that there is very little interaction with IIS itself.  Other than processing user login information or presenting session information back to the users, the Silverlight application has no interaction with the GP Web virtual directory.

 

 

IIS/GP Web Management - This is the Internet Information Services website that will serve up the GP Web Management Console virtual directory and run two Silverlight applications. Those applications are:

  • Session Management - This is used to see all of the Dynamics GP Runtime processes that are running across all session host machines
  • Tenant Management - This is used to manage multi-tenant information

This will be the entry point for administrators to manage / monitor tenants and sessions. The virtual directory is named WebManagementConsole.

Session Central Service -  This is a Windows Service that is installed on the Web Server (required). This service communicates with the Web Site as well as the Session Service as show in the diagram above. This service is the main component that maintains the communication with all of the session host deployed and collects data from those hosts.  This data enables the Session Central service to determine the number of active Dynamics GP sessions that are running on each host and directs new logon requests to the session host that is the MOST AVAILABLE. This service also creates a WCF endpoint that is used for other services to communicate with it such as:

  • GP Web
  • GP Web Management
  • Each Session Host

Some of the operations it performs are: 

  • GetSessionHosts()
  • AddSessionHost()
  • RemoveSessionHost()
  • SuspendSessionHost()
  • GetLeastUtilizedSessionHost()
  • GetSummaryofActiveSessions()

Note: There will be future article that talks about what each of these are doing.

The service also uses a configuration file to manage functionality and logging of actions. This service can run under either HTTP or HTTPS. From the support perspective, enable the service to run under HTTPS. The default physical install path for this service is:

  • C:\Program File\Microsoft Dynamics\GP Web Client\SessionCentral

The configuration file that is supporting this service is called: SessionCentralService.config  In addition, the files deployed in this folder are shown below. 

 

Session Host - This is a server machine that hosts the Session Service and one or more instances of the Dynamics GP 2013 client.  This is the machine that performs the majority of the work because it hosts all of the Dynamics GP runtime processes that support a specific GP Web Client user session. There can also be more that one Session Host deployed for load balance and utilization purposes.

Session Service - This is a Windows Service that runs on the Session Host machine and is responsible for authorizing users, creating user sessions, retrieving existing sessions, and monitoring sessions to report back to Session Central.  The Session Service will also start a shell instance of Dynamics GP,  also referred to as a Runtime.Process.exe, at the time a requesting GP Web Client users is authenticated as a valid user.  This service can run under either HTTP or HTTPS. From the support perspective, enable the service to run under HTTPS. The configuration file that configures the Session Service also contains the Base Runtime Address value.  This value is very important as it becomes the URL that the Silverlight application uses to communicate with the specific instance of Dynamics GP.

Some of the operations it performs are:

  • Authorize()
  • CreateSession()
  • GetSessions()
  • SessionAbletoCreate()
  • ClearCredentialCache()

Note: There will be future acrticle that talks about what each of these are doing.

The service also uses a configuration file to manage functionality and logging of actions. This service can run under either HTTP or HTTPS. From the support perspective, enable the service to run under HTTPS. The default physical install path for this service is:

  • C:\Program File\Microsoft Dynamics\GP Web Client\SessionService

The configuration file that is supporting this service is called: SessionService.config  In addition, the files deployed in this folder are shown below:

 

Session Monitor - This is an internal component of the Session Service that is responsible for running on a configurable interval to inspect the running sessions, perform any cleanup tasks, and report the information to Session Central.  Through the Session Monitor the Session Service will report its load to Session Central which will ultimately aid in the determination of which Session Host (in a multiple machine environment) can receive requests to create new sessions. 

GP Runtime Service - This is a WCF Service that is responsible for handling the interactions between the GP Web Silverlight. This service isn't visible or configurable as it doesn't have a specific config file on its own. This Runtime Service is started by the Session Service.  After the web user has been validated as a GP Web Client user, an instance of Dynamics GP is started (this is similar to just double-clicking on the Dynamics.exe directly). In addition to that startup, a WCF endpoint is also dynamically started.  This end point ends up being the GP Runtime Service.  This WCF service is specific to the instance of Dynamics GP that was just started. This is accomplished by taking the process ID (pid) for the instance of Dynamics GP that was just started and appending to the Base Runtime Address.  The base Runtime address is used by the Silverlight application to talk specifically to that instance of GP. Also, SSL is also required for the Runtime Service to function. The format of the full Runtime address is:  https://mymachine.contoso.com:46652/RuntimeService/1234

This address also makes some assumptions here as well.  The first assumption is that my certificate support fully qualified names such as mymachine.contoso.com. The second assumption here is that the Runtime Service is also listening on port 48652.  This is the default port that the installer chooses, but is configurable by the end user who is installing. The third and last assumption is the Process ID (1234).  This value is auto-generated by the operating system when the application starts.

Tenant Management Service - This is a WCF service that is responsible for managing tenant configuration information for applications that will be utilizing tenant services. The primary purpose behind this service is for cases where there is more than one instance of Dynamics GP being hosted on a Session Host. In most cases, on-premise customer will not have a need to use this service as it is mostly focused on hosting environments.

Tenant Discovery Service - This is a WCF service that is leveraged by the Web Site to determine the tenant that the calling user has access to. Again, this is primarily used in a hosting environment.

 

I certainly hope that you find this information useful and will keep it as a reference point when troubleshooting your Web Client deployment. Please let me know your feedback and anything else you are wanting to learn.  Some of the future articles I will be posting will be covering:

  • Certificate Generation (which one should I be using)
  • A quick Step-by-Step article to get the Web Client deployed on your machine within a Domain environment
  • Understanding the various configuration files and what they specifically do
  • Troubleshooting techniques that you can perform on your own before opening a support case.
  • What's under the Hood!

What would be nice is to get some feedback on what people want to see next.  I am assuming it is going to be the Quick Step-By-Step article.  But let me know what you want to hear and I will work on that next.

Thanks for reading and hope you enjoyed the content.

Aaron Donat