Server Settings

Server Ports

BrightServer, by default, opens and listens to incoming client messages on two ports, one being a standard HTTP Port, and other being a secure encrypted HTTPS Port. By default, these are set to 8080 and 8443 respectively. The secure port provides an end-to-end secure channel for client and BrightServer to exchange messages. Despite the fact that communications over a secure channel will be slightly slower than the standard channel, it should be preferred method of communications between the remote field devices and BrightServer.

The Remote Tracing Server Port is the port BrightServer can connect to, to get live remote tracing from the server. This port is 12921 by default. Information on how to connect to Remote Tracing can be found in the Remote Tracing section of this document.

Changing any of these values will require a BrightServer restart for the port changes to take effect. Any additional changes made to the server may not be saved, so it is recommended to execute any port changes independently to the other settings of the BrightServer instance. Finally, if the BrightServer instance starts up, but cannot open or listen via the ports configured, it will exit on startup.

Authentication Type

Every client connection to BrightServer must be authenticated for obvious security reasons. There are two types of authentication methods available : basic and form authentication. Basic authentication is standard mechanism that comes with the HTTP protocol. The form authentication is a more secure and thus the recommended method, even though it requires a larger authentication message between the client and BrightServer.

Advanced Settings

Advanced Settings include following options :

Compress message sent to clients : Whether to use compression when sending message to the field client devices. This option should normally be set to compress the message sent from BrightServer to the client devices. Remember that there is mirror image of this setting on the client BrightForms side, where you have the option to set the compression for the messages sent from client to BrightServer.

Send server system clock for clients to synchronise : Whether to send the server clock so that connecting clients can synchronise their system clocks to the server. This can be used in situations where the client device system clocks need to be updated regularly as they connect to BrightServer. Note that the server time is always is sent in GMT (UTC) format so that the devices in different time zones can also update their clocks correctly.

Ignore client time zones : If true, the system sends and retrieves date-time values in local times such that local time values on the server will be exactly the same as on the device and vice versa - regardless of both the server's and device's time zones. For example, '2015-02-15 00:00:00.000' in UTC+10:00 will be '2015-02-15 00:00:00.000' on the device, even if it's in a different time zone, such as UTC±00:00. In other words, date-time values will be transmitted in local time format rather than in UTC time format.

By default, this is set to false, date-time values are converted to the UTC time format before it is sent over the wire to the receiver, then converted back to the local time after they are adjusted using the locale of the device. As such, datetime values represent specific points in time, rather than times independent of time zones. In the above example, if the device was set to UTC±00:00, '2015-02-15 00:00:00.000' sent from the UTC+10:00 server will result in the value  '2015-02-14 14:00:00.000' being synchronised to the device.

Session Timeout : This is an important configuration parameter and determines how BrightServer clears the inactive session from its session list. Every time a client connects to BrightServer, BrightServer creates a unique communication session to handle the client messages. To do this, BrightServer allocates some system resources to this session such as computer memory etc. In normal client connections, as the client disconnects from BrightServer, BrightServer releases the system resources. Due to the nature of mobile connectivity and communications such as connection drop outs, BrightServer needs a mechanism to reclaim the system resources for those inactive sessions belonging to the disconnected dropped out client connections. This session inactivity period is defined by this Session Timeout parameter. Every so often BrightServer goes through the list of current client sessions, and removes the inactive sessions to reclaim the systems resources allocated for those sessions.

If the server is configured to run BrightWeb, this is the period in which devices may idle before being logged off. For more information, refer to BrightWeb > Work Flow and Timeout Management.

Disable data synchronisation to and from clients : When ticked ON, the server will not service data synchronisation requests from client devices. That is, the clients will not be able to receive data from server and also they will not be able to send any data to server. This feature can be very handy while the server is being configured or a new server configuration is being deployed, or some major changes are being implemented on the server data sources. This way, the user accounts do not have to be manually deactivated one by one. Once the necessary changes have been carried out on the server, then this option needs to be ticked off for the resumption of the data synchronisation services. While the data synchronisation is disabled, remote client devices can still connect server and pick up licenses from the server license pool. This would be helpful for verifying the connection between clients and server and the correctness of BrightForms user and server settings.

Data Size Limits

The maximum number of records sent out in a single packet determines how to segment the data synchronised from the server. Each segment will be chunked into individual packets sent to the client. The maximum size for a single packet, or data chunk, limits the size of each packet in kilobytes. The maximum number of records returned by online queries limits the number of records returned when the client is accessing the server via online queries and not normal synchronisation. Online queries will only return the number of records configured here even if there are more records retrieved by the query. The default values for these settings are suitable for the majority of the mobility deployments.

Application Distribution - Deployment Directory

BrightServer provides a seamless mechanism to distribute applications and application updates to remote field devices. BrightServer can distribute multiple applications to different users based on their user profile settings. For an application (i.e. a BrightForms BSP project) to be distributed to remote devices by BrightServer, it should be first exported to a directory known by BrightXpress. When a client connects to the server, as a part of authentication process, BrightServer will check the application distribution requirements as configured in the user account details. If an application name is defined, and the version of the application is different than what the user device has already received, it then reads the exported application files and sends them to the remote field device to carry out the application updates.

To select the application deployment directory, click on the Browse button which will open the following dialog. Remember that this deployment directory refers to a location on the server machine which BrightServer will be running, which possibly may be different to the machine BrightBuilder is running on. 

Select the directory where the application definition files are export and click on Select button.

Logging User Activity

BrightXpress allows you to capture the user activity into a relational database. When enabled the server will log user logon and log off times, the total time online, amount of data sent and received to and from server etc into the runtime statistics database. By default, the server does not log the user activity. You need to tell it to do so by checking Log User Activity check box.

The server creates database records in the BS__SYNCSTAT table in the runtime database statistics database which is configured via System Databases tab on this panel. Normally you do not need to change the default database details as BrightBuilder allows viewing the user activity stats via the Server's User Activity panel.

System Databases

BrightServer uses a set of relational databases to carry out the mobile data gateway functionality. These databases are used to store internal sync states, runtime configuration data, sync statistics and more. The system can operate on a single database servicing these data storage requirements or it can be configured to use different databases on distinct data sources.

The server needs to have an access to three different databases :

System Database : This is the database where the internal system specific data is stored. By default this is configured to be using an instance of a brightdb database stored in the "brightdb" folder where the server is installed. This internal database is a robust scalable relational database where a large number of users in the field can be serviced. However this database can be configured to use an industry leading commercial database product where clustering is provided in order to service thousands of remote users in the field.

Runtime Configuration Database : This is the database where all the runtime configuration and settings are managed through the remote configuration tools provided by BrightBuilder via the Servers panel. The data includes user account configuration, server settings, licenses deployed etc. By default this is configured to be using an instance of a brightdb database stored in the "system" folder where the server is installed. Configuring an external database would be useful for easier and centralised data back up and storage purposes, if dictated by your companies internal policies.

Runtime Statistics Database : This is the database where the mobile data is captured. The mobile data refers to the server's day-to-day operations including user activity data. This database by default is configured to use the System Database. You may only need to change this database configuration if the mobile data needs to be accessed by your backend systems for reporting and monitoring purposes. Otherwise since you can access the data captured through BrightBuilder, you can leave the default configuration as is.

To change the default settings, tick off the "Use the default configuration ..." checkbox, and click on the Configure button for the system database to be modified. This will display the database configuration dialog.

Choose the data base type from the Database Type drop down list and fill the necessary database details.