Installation in a First-level Production Environment

The first-level production, or pilot, phase is the second step in rolling out a successful Synapta Services Builder implementation. In this phase, the scope is broadened — design-time tasks have been completed and development is no longer bound to a Windows environment.

A first-level production environment is distributed across separate servers. The run-time, MCS, and design-time components have been separated. However, there is likely to be only one instance of Synapta Services Builder running.

Workflow

  1. After receiving the necessary files from the developer, the system administrator creates a script to publish tasks to a single production Runtime Service and MCS.

  2. The system administrator verifies automated pool modifications, such as changes to configurations or refreshed NavMaps.

  3. The system administrator and developer work together to verify that the newly published system is working.

  4. The system administrator monitors and logs information via a production version of MCS, accessing the MCS user interface through a supported browser in a Windows environment.

Configuring the Pilot Environment

During the pilot phase, you can have multiple remote Runtime Services, all pointing to a single MCS server. This server is the repository for the tasks recorded during design-time.

In the following diagram, the pilot phase is using two servers, both with the same configuration as was used in design-time. The implementation is confined to two regional offices to verify that the tasks and management configurations are in place and working correctly.

This diagram could illustrate a pilot phase for a production environment in which the number of offices being served could be increased to many regional offices and several thousand individual clients. Of course, the pilot phase you use depends on your particular business needs.

First-level production or pilot environment

Session Management

In the pilot phase, you must decide how many session pools each MCS server will handle. This will allow you to correctly set the pool configurations and balance the expected workload across your system, ensuring an acceptable response time from the Runtime Service for the client application.

For example, if your production environment will include regional offices and over 10,000 individual clients, you can configure each MCS server to have a single pool handling a maximum of 2,000 sessions. You can assume that all 2,000 sessions will be used, but not constantly allocated. The following settings in the MCS for Screens General Configuration dialog box are based on this example. In this situation, you could use default values for options not listed. For more information about configuring session pools, see Creating Session Pools under Related Topics.

Option Setting Remarks
Maximum Sessions 2000  
Maximum Free Sessions 1000 This setting assumes that the 2000 maximum sessions will be load-balanced between two run-time servers.
Miinimum Free Sessions 0  
Initial Free Sessions 0 When this value is set to 0 (zero), users must wait approximately one additional second (depending on the host) when new sessions are brought online for the first time.
Related Topics
Bullet Installation, Overview
Bullet Installing in Windows
Bullet Installing in UNIX
Bullet Creating Session Pools
  Attachmate