Page tree

Good Practices / Tips / Tricks   (under construction)

although most subjects are somehow described in the Uniface Anywhere Administrator Guide, some of the subjects here may be off assistance to you.

Multi-tier setup

The Uniface Anywhere Host server can handle only a certain amount of applications within acceptable levels. The amount of applications that it can handle depends a lot on how the application is setup and used by the users.

There is no golden rule on how many users can simultaneously make use of the Uniface Anywhere Host, however to less processes are started on the Host, the more users can make use of one Uniface Anywhere Host.

Good practice is to off-load as much processes as possible to other servers.

Applicable specifically for Uniface applications that are used through Uniface Anywhere:
Having the Uniface Anywhere server also processing the application business logic is obviously going to effect scalability. Application business logic could be held in the forms (displayed or hidden), or in Uniface Services. 

  • 2-tier, with C/S forms containing all the processing is obviously going to take up resources, which then limits the resources available to serve multiple clients.
  • 3 or n-tier deployment with Uniface services deployed with the Uniface App Server on the same physical server is also going to take up resources. 
  • A partitioned application, using the Uniface Application Server to off load as much processing as possible on separate server(s) to the Uniface Anywhere server(s) will maximize scalability.
  • The more GUI objects on C/S forms, the more each session has to manage, therefore taking up more resources. It’s better with newer OS versions, but simple design practices will help.

Whenever the above practices are not sufficient, there is the possibility to partition Uniface Anywhere clients across multiple servers, using a ‘Relay server’ to manage clients across multiple servers.

Relay server setup

In a Relay server setup technically the number of clients is infinite, as adding servers / hosts to the relay server is infinite. We know of sites who have more than 1500 concurrent users.

Every client will connect to the Relay server and the Relay server will assign the session to a connected Dedicated server.
The Relay server will then step out of the connection but will monitor it in case when needed to reconnect.

To maximize performance on the Relay server, there is no need to have applications other than Uniface Anywhere, installed on it.
Although for applications to be published through Uniface Anywhere, the applications executable must be accessible.
This latter could be achieved by installing only the Uniface product in the same location local (no need to configure), or if you want to save also disk space, then you can place the Uniface executable only in the local directory on the Relay server.
Be aware that the path to the local executable needs to be the same as the fully installed Uniface product on the Dedicated servers.

Flexible scalable setup

Adding Uniface Anywhere servers to a relay server is very easy, as it just requires the Relay Server Name to be entered on the to be Dedicated server in its cluster manager and the Uniface Anywhere Application Publishing Service to be restarted on that server.

You may say, but what about the Uniface Anywhere licensing?
The easiest way to avoid having to order new licenses for every server that's being added, is to setup a centralized license server.
A standalone License server is than a option, however in a Relay setup the most convenient is to use the license mechanism on the Relay server and having all Dedicated servers connect to the relay server for their licenses.
This will have the advantage, that a new instance (clone) of a Dedicated server, can be brought in to service very quickly to increase overall processing power (scaling up).

To achieve this use of a dedicated license server, create a file called license.lic in the Uniface Anywhere\Programs directory on the dedicated servers and place the following in the file:

SERVER <servername.domainname> ANY 27000

Where you have to replace <servername.domainname> with your actual license server or Relay server name.

On the Relay Server or dedicated license server, you will need to open the communication ports used by the license services in the used firewall on Windows.
The most easiest and flexible way is on the firewall to add an Inbound Rule to allow communication for the following two processes:

firewall inbound rule
%ProgramFiles%\Uniface\Uniface Anywhere\Programs\lmgrd.exe
%ProgramFiles%\Uniface\Uniface Anywhere\Programs\blm.exe

This will means that when the ports used by the license services have changed, you will not have to change the port configuration in the firewall, as it will automatically follow.

However, when this automatically changing of the firewall configuration is not desirable, you can fixate the ports used by the License services by adding / changing the License file on the Relay server as follows:

SERVER <server_name> <Host_id> <port_number1>
DAEMON blm port=<port_number2>

You are allowed to change the port_number in the SERVER line and add the port=port_number to the DAEMON line without invalidating the license file.
Default port for SERVER is 27000, the default port for DAEMON is variably and set during start of the daemon.

It is strongly advised that the SERVER port_number and the DAEMON port_number should NOT be made the same.

Applications publishing considerations

As it is possible to publish applications in Uniface Anywhere that have their program executable(s) and libraries on network shares, it is good practice to have the application(s) locally installed on the Uniface Anywhere HOST Server.
We know of customer situations where the availability of the network shares are sometimes just gone for unknown and/or unexplained reasons and having their application crashing because of it.
Having the application locally installed on the Uniface Anywhere Host will solve this.

Publishing multiple Uniface applications

Published application that a user does NOT have the 'read' and 'execute' rights on the executable, will not be shown in the clients 'Program Window' after the client has successful started a Uniface Anywhere Session.

In the situation where you have multiple Uniface applications to publish that only differs in the INI and/or ASN files, restriction to start up a specific application can be done by revoking group/user rights for that specific group/user on the ASN and INI files of the application that they are not allowed to use.
This will indeed prevent the starting of that application, but if this user has rights to start another Uniface Application that is also published, all Uniface Applications icons will be shown in the Program Window, even the ones that the user can't use.

There is an easy solution to prevent showing of the application icons that a user doesn't have rights on to start it.
Find the uniface.exe executable in the <uniface-installdir>\uniface\common\bin\, copy and rename it in to the same directory.
Give group/user rights to this 'renamed' uniface.exe executable. Instead of publishing the uniface.exe in the cluster manager for this application, publish the 'renamed' uniface.exe file.
Users who do not have the rights on the 'renamed' uniface.exe file, will not see the application icon in the Program Window.

Note to remember: When the Uniface application is being patched to a higher patch level, you will have to copy and rename the new uniface.exe again as described above.

Limited usernames for multiple users (shared users)

Uniface Anywhere is designed to handle sessions where every user uses an unique username to setup a session on the host.
Whenever a limited number of usernames are defined to access the Uniface Anywhere Host and multiple clients/users makes use of the same username to setup a session, it is strongly advise to define these shared usernames within the Cluster Manager in the Shared Account box on the General tab page in the Host properties.
Define in the Shared Account box ALL usernames that can be used by multiple users divided by semicolon.