Introduction to Remote Access Server

The Remote Access servers can be used by Component Enabler to access applications.

The server-side deployment consists of a number of platform-specific Remote Access servers that handle communications between clients and applications. Clients and servers communicate, using RATL protocol running on TCP/IP. This protocol is a simple wrapping of a standardized and extended set of NOF messages that provide all the functionality needed to support GUI forms.

Clients establish normal sessions with applications through the Remote Access servers using a TCP/IP connection. These servers perform a number of checks, such as authenticating users and verifying the application exists, before granting the client access. The servers then receive transaction requests from client programs over a TCP/IP connection and pass them to the application. Transaction responses from applications are passed back to the clients over the same TCP/IP connection. Remote Access servers can also pass back asynchronous messages, such as messages from Reports, to a client application.

Remote Access servers can also use the Microsoft Message Queue (MSMQ) server for connections instead of TCP/IP connections.

The Remote Access servers are designed to offer connectivity, throughput, and transit times comparable to terminal access to the applications on the same host applications. Each client application runs independently of all other clients, with its own connection back to the application server. There are no points of single threading or possible congestion in the transaction path to add overheads or reduce performance.

Installing Remote Access Server

Codefile

The codefile is automatically installed to the CCF system pack.

CCF params file

COMS

Register the entities to COMS via the Utility window with the following file:

       (<ABSUITE usercode>)NGEN28/SAMPLE/COMS/CONFIG/RATL ON <ABSUITE dictionary pack>     

For Big Buffers, set the Maximum Message Text size for Global Activity to 65000.

CCF Configuration

Use the CCF components to configure the server entities as follows:

Router

Identify the server as a PCM to the router and enable it, using the following syntax:

Add PCM <name>
 codefile = <filepath>
Enable PCM <name>

Example:

 Add PCM <name>
  codefile = <filepath>
 Enable PCM <name>

CUCI

As part of the CCF configuration you must configure a:

Connection Device

Configure a device to the CUCI PCM to associate device connection attributes with each dialog. Attributes are assigned using the following syntax:

 Add Device <device name> 
  acvt = <VTname>, 
  ccenable = <boolean>,
  controlcapable = <boolean>, 
  dynamic = <boolean>, 
  marccapable = <boolean>, 
  maxinput = <number>, 
  maxoutput = <number>, 
  messages = <category>, 
  securitycatlist = <name>, 
  ndlheader = <boolean>, 
  screen = <boolean>,
  usage = <category>

Example

 Add Device RATLweb
  acvt = transparent, 
  ccenable = false, 
  controlcapable = false, 
  dynamic = true, 
  marccapable = false, 
  maxinput = 10000, 
  maxoutput = 10000, 
  messages = none, 
  securitycatlist = SCL_NOF, 
  ndlheader = false,
  screen = false, 
  usage = IO

Connection Service

Configure a service to the CUCI PCM to associate device connection attributes and to identify the connection path for each dialog. Attributes can be assigned using the following syntax:

 Add Service RATLon
  closeaction = <number>, 
  device = <name>, 
  logoffdisconnect = <boolean>,
   dynamic = <boolean>
 Enable Service RATLon

Example

 Add Service RATLon 
  closeaction = 3, 
  device = ratlweb, 
  logoffdisconnect = true
 Enable Service RATLon

TCPIP Port

Define a port to the TCPIP PCM to associate port attributes for the dialogs. Attributes can be assigned using the following syntax:

 Add Port <port name> 
  stationname = <name>, 
  checkinterval = <number>, 
  device = <name>,
  framing = <category>, 
  maxoffer = <number>, 
  maxoutput = <number>, 
  service = <name>, 
  socket = <number>, 
  transport = <category>, 
  windowsize = <number>
 Enable Port <port name>

Example

 Add Port RATL
  stationname = actlinc/#, 
  checkinterval = 5, 
  device = ratlweb, 
  framing = standard,
  maxoffer = 1,
  maxoutput = 10000,
  service = ratl, 
  socket = 2449, 
  transport = tcpip, 
  maxoffer = 500
 Enable Port RATL

Using StationName

This attribute names a connection to COMS. It provides a flexible format from which station names can be generated.

When developing a station name, you need to consider uniqueness and determinability. For example, you might require that the station name be consistent each time a particular user connects, and will not change over time. You might also require that more than one connection be used from the same client or from any number of clients and each name used is unique.

You also need to consider any COMS security that is applied to station names and how these stations comply.

For the best means of ensuring a consistently unique name, use the <tcpip psnf> attributes $yourhost or $yourIPaddress within the stationname attribute value.

If a hostname is desired but an IP address is formed for the stationname instead, that is the letters IP are inserted in front of the address, it might be possible to use TCP/IP mapping to set the hostname. Refer to the TCP/IP Implementation and Operations Guide for more information on mapping IP addresses.

On some networks, such as Dynamic Host Configuration Protocol (DHCP), IP addresses are not consistent over time. In this situation there are two possible alternatives:

Overriding the Stationname by Client

When a station name is set by the client it overrides the configured setting defined for RATL connections above. Refer to the Agile Business Suite Component Enabler User Guide for more information on setting the station name by client. The station name supplied by the client might have a numerator applied to uniquely qualify the name, where multiple connections are desired from the same client. The numerator is represented by a string of one or more consecutive hash characters (#) appended to the station name which is converted to a unique ascending number. The number of consecutive hash characters indicates the minimum number of digits to be appended. For example, a supplied station name of user### results in names of the form: USER001, USER002, USER003 ... USER999, USER1000, USER1001 etc

The effect of StationName on station name (Glb.Stn)

The setting of the internal station name, or attribute Glb.Stn, is affected by the external (COMS) station name.

For Component Enabler (or NOF) based connections the value of Glb.Stn is based on the COMS station name value and the Remote Access service attribute StationNamePrefix value. If the StationNamePrefix is not defined then Glb.Stn is prefixed by the letters RAT, as shown in the first example below. If the derived station name is longer than the limit of 17 characters, the connection attributes for yourhost is used, as shown in the second example below. If the value for yourhost is not known or it is longer than the 17 character limit, the value for youripaddress is used. If this value is also too long the IP address is converted to its integer equivalent, as shown in the third example below.

The following example shows the resulting COMS and station names for a client with the specified Port Stationname format, a station name prefix set or not set to SNP, a hostname of Timbertown, and an IP address of 123.132.213.231:

RATL Configuration

Configure the following entities:

RATL Configuration Syntax

You can use the following verbs in CCF to configure the server for Component Enabler, or Web Enabler:

Service

Identify a service to the PCM to associate the connection path for dialogs. Attributes are assigned using the following syntax:

 Add Service <service name> 
  service = <name>, 
  NOFidentity = <name>, 
  SwitchToFireUp = <boolean>, 
  StationNamePrefix = <name>
 Enable Service <service name>

Example

 Add Service RATL
  service = LINC,
  NOFidentity = SCL_NOF,
  SwitchToFireUp = False,
  StationNamePrefix = AL/
 Enable Service RATL

Configuring Remote Access Server Entities

The Remote Access configuration entities for the COMS Security Category List names must be configured in at least one of the following attributes of the CCF configuration:

Refer to RATL Configuration Syntax for more information about the syntax used to configure the server in an MCP environment.

When configuring entities you can change their names, but the names must remain unique. You can define additional Port and Service entities ensuring that a connection path can be resolved through CCF, encompassing the PCMs from TCIP using the Remote Access server to CUCI. Refer to the ClearPath HMP NX/Services Administration Guide or ClearPath HMP Series CCF Administration Guide for more information on using CCF.

View

You can identify Views to the PCM to associate connection criteria for Component Enabler users to access applications. A View can refer to one or more applications, or different Views might apply to the same application.

To identify at least one application, you can assign attributes using the following syntax:

 Add View <view name> 
  application = <system>, 
  level = <number>, 
  window = <name>, 
  usercode = <usercode>, 
  language = <language>
   comsstatuscheck = <boolean>
 Enable View <view name>

Example

 Add View sample_auto
  application = (USER1)SAMPSYS on DICTPACK,
  level = 0,
  window = SAMPLE
  usercode = anonymous,
  language = english
 Enable View sample_auto

Language

Identify a language to associate the ISO Country code and an ISO Language code with a language name. The ISO Language code is defined in ISO 639 while the ISO Country code is defined in ISO 3166. These standards are available in the official ISO website, http://www.iso.ch/.

Language names are configured in the application. Attributes can be assigned and enabled using the following syntax:

 Add Language <language>
  ISOC = <country code>,
  ISOL = <language cod

Example

Add Language english
 ISOC = EN,
 ISOL = EN

Message Queuing

Message Queuing allows multiple concurrent users of Component Enabler to access an Agile Business application, by making more efficient use of system resources, and reducing the overheads associated with establishing and maintaining individual connections for each user session. This is an alternative to the existing method of connecting to the Runtime application using individual TCP/IP connections.

Refer to the Agile Business Suite Component Enabler User Guide for more information on how to use message queuing for Component Enabler Scalability.

The following entities are added to the PCM section of the CCF params file to configure the request queues and connection details of the FalconMQ Server and FalconMQ Client library:

MQServer

 Add MQServer <name>
  Servername = <name>,
  IPaddress = <ipaddress>,
  Port = <number>,
  Domain = <name>,
  UserName = <name>,
  Password = <name>,

Set attributes associated with the FalconMQ server using the following syntax:

You can also use the following commands:

Example (italics denote responses):

 Add MQserver FMQS
  IPaddress = 123.1.2.3,
  Port = 1100,
  Domain = realm,
  UserName = dnote,
  Password = test,
MQserver FMQS added
Show MQserver FMQS
1 FMQS
  IPaddress = 123.1.2.3
  Port = 1100
  Domain = realm
  UserName = dnote
  Password = test

MQClient

Set attributes associated with the FalconMQ client using the following syntax:

 Add MQclient <name>
  Functionname = <name>

You can also use the following commands:

Example (italics denote responses):

 Add MQclient FalconMQSupport
 MQclient FALCONMQSUPPORT added
 Enable MQclient FalconMQSupport
 MQclient FALCONMQSUPPORT enabled

MQrequest

Set attributes associated with the request queue using the following syntax:

 Add MQrequest <name>
  MQclient = <name>,
  MQserver = <name>,
  Pathname = <name>,
  Processes = <number>,
  Station Name = <SNformat>,
  Usercode = <identifier>,
  View = <name>,
  Service = <name>

You can also use the following commands:

Example (italics denote responses):

 Add MQrequest sampleQ
    MQclient = FalconMQSupport,
    MQserver = FMQS,
    Usercode = legion,
    View = samplesystem,
    Service = ratl
 MQrepuest sampleQ added
 List MQrequests
 MQrequests:
 1 sampleQ

COMS Configuration

To define connection types to applications, you need to define two COMS configuration entities. These are Security Category List and Installation Data entities. The names used in the CCF configuration for SecurityCatList (CUCI device attribute), and NOFidentity, should correspond to the names of Security Category List entities in the COMS configuration. Each Security Category List entity needs a corresponding Installation Data entity. The value assigned to the INTEGER1 attribute determines the type of connection for that entity. Currently, the only allowable value for INTEGER1 is 9.

You can define Component Enabler (NOF) based connection types for applications using the following COMS configuration entries:

 CREATE INSTALLATION_DATA RATL_NOF
  INTEGER1 = 9
 CREATE SECURITY_CATEGORY_LIST RATL_NOF
  ID = RATL_NOF

Remote Access Server Commands

Clear Command

This command is used to clear connections from the PCM.

Syntax:

 Clear Dialog<#,name, or list>

Example:

 Clear Dialogs 1,4-7,9

Option Command

The following list outlines the options users can set:

Administering the Remote Access Server

Administering the Remote Access Server involves the following tasks

Starting and Stopping

Use the CCF commands to start and stop the server and to monitor or trace server activities.

Because the server is configured as part of CCF, starting and stopping CCF starts and stops the server:

Alternatively, the server can be started and stopped without disrupting CCF:

Monitoring

You can monitor the status of any Remote Access server component configured in CCF, such as Languages, Views, and Dialogs. You can use the CCF STATUS or SHOW commands to display the status of the selected component.

The following example uses the STATUS command to display the status of the PCM. It displays the version, timestamp, internal program options and default language.

 NA CCF RATLPCM STATUS

This command returns the following data:

 Unisys Corporation COMSock
 RATLPCM 44.201.1 -09/20/98 - 10:29:31
 Compile Options:Trace, Assert
 Language = ENGLISH

The following example uses the SHOW command to display the status of the connected dialog.

 NA CCF RATLPCM SHOW DIALOG 1

This command returns the following data:

 Sunday 09/20/98 10:29:31
 1 RATL/UNO
 Client = Open
 Transport = Open
 Service = Open
 Input Seq Num = 8
 Output Seq Num = 6
 NOF = True
 GUI = False
 View = UNO
 Language = SPANISH
 Device = RATLWEB
 Maxoutput = 6000
 HostName = ACUSAHA
 ACVT = Default

Security

If a host application supports password aging and the Remote Access server is compliant with the application then user passwords can be changed when using the Remote Access server.

Refer to the MCP/AS Security Administration Guide for more information on setting password aging on an A Series host.

Tracing

Use CCF commands to start and stop tracing and to set the tracing attributes. Tracing can be initiated either by the operator, or by the client as part of the connection request. Tracing is normally used only for problem resolution, as it might impact the performance of the server.

The options for the CCF TRACE command are:

You can set trace attributes to specify which activity is traced. The trace attributes are listed in the following table:

An example of the CCF command to start tracing all dialogs for the Remote Access server is as follows:

 NA CCF RATLPCM TRACE ON +ALLDLGS

Remote Access Server Protocol Response Messages

In particular situations the server sends protocol messages, with a number of possible response codes, to the client.

The following table outlines some of the more common codes and possible causes, to assist in determining the cause of the message:

Localization of Messages

Remote Access Server messages can be translated using the MCP-based Multilingual System (MLS). The user messages are stored in the program SYSTEM/LINC/PCM/RATL in the following arrays:

Configuring TLS 1.2 Remote Access Server

A TLS certificate must be installed on the server to ensure a secure connection and protect all important information. You must first create a TLS 1.2 certificate on the MCP host machine before importing the security certificate using Security Center.

To configure the TLS Remote Access Server, perform the following:

Refer to the MCP Security Overview and Implementation Guide and TCP/IP Distributed Systems Services Operations Guide for more information on MCP security.