Application Server Installation¶

This chapter documents how to install the runtime code that allows the FWD application server to execute. The configuration and execution of the server is documented in the Bootstrap Configuration, the various sections of Part 2 relating to the directory content and the Running the Server chapters.

Installing the database server is separate from the application server, details can be found in Database Setup and Data Migration.

Configuring the legacy Application Server (OpenEdge AppServer support) is documented in the Chapter 15 Setup and Configuration of Legacy Appservers chapter.

System Requirements¶

Hardware¶

Please see the System Requirements for the Application Server for details on the application server hardware requirements.

Software¶

The FWD Application Server can be run on the same system as the FWD Client OR it may be on a completely separate system. When separated, there is no requirement to have the same operating system for the FWD Application Server and FWD Clients. The application server can be run on a one operating system, while the clients can be run on a different operating system.

It is also not required to setup the FWD Application Server on the same system as a FWD build environment.

If a single system is being installed with more than one of the FWD components/environments, then you will need to make sure that the superset of those requirements are met on the target system. This chapter only focuses on the requirements for the application server. Please carefully review the Application Server software requirements which explains the details.

Networking¶

Network Path to Clients¶

Unless all the clients are on the same system as the application server there will be more network traffic with a FWD implementation than with Progress OpenEdge implementation because of the design of the FWD runtime.

There is one client per ABL client program that is running. This means each interactive user, batch process and Appserver/WebSpeed agent will have a matching client process. There is one socket opened between the application server and each of these client instances. That per-client socket is kept open for the duration of the client's session with the application server. If there are non-ABL applications and/or batch programs that connect to the FWD server, then there is at least one socket open for each of them. Hand coded applications can create more than one session with the server, if they do that, there is 1 socket per session.

If the clients and application server reside on the same system, then there is typically nothing to do to enable connectivity. However, if any clients run on a separate system, then the firewall setup on both the client and the server must be configured to properly support the port(s) in use.

At this time, there isn't a specific equation that can be used to estimate the network traffic, since there are many variable factors. Although the exact amount of traffic is application-specific, ensure high performance for the network connection between the clients and the application server in order to achieve optimal performance.

Network Path to the Database Server¶

It is possible to run the application server and the database server on the same system. In that case, there is typically nothing that must be done to enable the network path.

If there is a firewall or router in the network path between the application server and the database server, then you must ensure that the firewall is configured to allow the related communication flows to occur.

Choosing the Appropriate JVM¶

The core requirement for the JVM is that it must be compatible with Java 8.

Each FWD component (conversion, application server, client, user-defined functions running at the database) can use a different JVM. These can run on the same system or different systems. They can even run on a different operating system platform. There is no dependency between JVMs of different components, since they are separate operating system processes.

The following JVM versions have been well tested:

Oracle JDK 1.8 on Linux
Oracle JDK 1.8 on Windows
OpenJDK 1.8 on Linux
OpenJDK 1.8 on Windows

The specific versions of Oracle JDK 1.8.0_101 and OpenJDK 1.8.0_111 have both been tested and have been found to work well. Generally, it is safe to use any later version of the Java 1.8 platform.

The application server dynamically generates some converted ABL code (at runtime), which means that there are parts of the runtime system that may depend upon tools in the JDK. For this reason, the JDK is required and a JRE (runtime only, no development kit) cannot be used.

The application server process (JVM) is where the majority of working memory exists for each client (accessing the system). The actual memory used will depend on the queries, the block flow, recursion and other features of the original ABL. The converted application code is actually running in the common server process, which is different from how Progress ABL works.

Although either the 32-bit or 64-bit version may be used, with the large memory requirements of server processes, it is expected that the 64-bit version will be necessary in virtually all installations. The 64-bit JVM is a good default choice.

Although it is possible to run smaller server instances using a 32-bit JVM, this is likely to be only useful for very specialized cases. Running a small application (few users and no large working set requirements) would be possible. It might be useful to do this for hardware that is limited (32-bit architecture CPU or very limited RAM).

Installation Process¶

The Linux instructions included here are written (and tested) on Ubuntu 16.04. If the target Linux system is a different distribution, the equivalent commands must be run.

The Windows instructions can be used for any Windows version from Windows XP through Windows 10. These instructions should also work on the equivalent Windows Server versions.

Install the Java Virtual Machine¶

Please check previous paragraphs for details on how to choose the JDK to install.

Linux Windows

Make sure the bin/ directory of the JVM installation is added to PATH variable of the operating system so the application could be executed by using java command in a terminal window: the PATH for the user should be set to include the directory containing the command line executables (e.g. java or javac) of this installation. In Linux this would be the bin/ directory of the Java installation. In other words, this should be the default installation for any shell or command prompt from which the FWD technology will be built or used.

To install OpenJDK 1.8, following commands can be used:

sudo apt-get install openjdk-8-jdk openjdk-8-source
cd /usr/lib/jvm
sudo rm default-java
sudo ln -s java-8-openjdk-amd64 default-java

It is also recommended to set the user's CLASSPATH to current folder (“.”):

export CLASSPATH=.

Please note that this will only set the variable for the current terminal session. You will need to set this each time your start a new terminal session, if it is needed.

The Oracle JDK 1.8 is a well tested option for Windows. The JDK can be downloaded from http://www.oracle.com/technetwork/java/javase/downloads/index-jsp-138363.html.

If you are planning to build FWD binaries on Windows make sure to install the accompanying JRE when installing the JDK, this is the default option of the JDK's installer.

Make sure JAVA_HOME system variable exists and points to the location of the installed JDK. The variable is needed by the FWD build scripts to locate the Java build files. If not defined explicitly it would point to the location of the public JRE installed together with the JDK (or any other JRE set as the default one), which is missing the build files, and the build would fail.

Add %JAVA_HOME%/jre/bin/server to the system PATH variable. This ensures that the FWD client spawner process, spawn.exe, locates jvm.dll correctly.

Note:
Because of a bug in how the gcc C++ compiler processes paths (please see #3273 for further information), this value cannot contain spaces!

There two possible approaches to avoid this depending on the current system configuration:

1. System with no JDK yet installed. Install JDK into directory without spaces, like C:\jdk180 for example.
2. System with JDK already installed into something like "Program Files\path to JDK" containing spaces and there are the reasons to keep this configuration. in this case create symbolic link to JDK that has no spaces inside:

mklink /D SomePathWithNoSpaces "The target path\to JDK with\spaces inside"

an example (having C:\ as current directory):

mklink /D jdk180 "Program Files\Java\jdk1.8.0_121"

The quotation in link creation command is mandatory for mklink to properly resolve the original directory. After link has been created it must be used in JAVA_HOME and JRE_HOME environment variables instead of original path with spaces.

As alternative solution to avoid that, use the legacy 8.3 filenames for tokens that contain spaces. In a default Java installation, they are Program Files or Program Files (x86) must be replaced with PROGRA~1 and PROGRA~2 respectively, but they can differ if Windows was reinstalled. Use dir C:\ /X to see actual legacy name for each file/dir, in second to the last column. The value of this environment variable for default installation will look like this:

JAVA_HOME=C:\PROGRA~1\Java\jdk1.8.0_121

The above listed environment variables must be defined system wide so that they are available to all users. On Windows 7, you can access Environment Variables... in Control Panel/System and Security/System/Advanced System Settings, Advanced tab.

Create the Server's User Account¶

Using the superuser account (on Linux/UNIX this is root, on Windows this is the Administrator or SYSTEM account) would functionally work, but doing so comes with serious security downsides.

The FWD Application Server should run under a dedicated user account that has limited permissions. The idea is that if it is ever compromised, the FWD Server can only access the specific resources that have been granted. If the FWD Server is run using the superuser account, then it will have access to many more resources than necessary, exposing the potential to make any security breach much more severe.

To the degree that the FWD Application Server and FWD Clients are running on the same system, never use the FWD Application Server OS account for any FWD Client session. Otherwise FWD clients would have the ability to modify the directory, access private keys and generally do anything they want.

That FWD account can be named anything. In this chapter it will be named fwd. The folder where FWD is installed will be owned by the fwd user.

Create a user account on the application server system under which context the FWD application server will run:

Linux	Windows
`sudo adduser fwd`	Use the `net user fwd /Add` command or the Windows' `Control Panel/User Accounts` UI.

Install FWD Application Server¶

Once you have a built FWD project, the needed files to run the application server will be found in the dist/server folder of the project, after running the gradlew distribution command; this folder will contain just the server dependencies, while the FWD jar will be found in build/lib/p2j.jar.

Linux Windows

Assuming the FWD project has been locally built in ~/fwd/, the following commands will create and install the FWD application server binaries in the /opt/fwd/lib folder:

sudo install -d /opt/fwd/lib
sudo cp ~/fwd/dist/server/* /opt/fwd/lib/
sudo cp ~/fwd/build/lib/p2j.jar /opt/fwd/lib/
sudo cp ~/fwd/build/lib/libp2j.so /opt/fwd/lib/   # required post-FWD v4
sudo chown -R fwd:fwd /opt/fwd/lib
sudo chmod 0550 /opt/fwd/ /opt/fwd/lib
sudo chmod 0440 /opt/fwd/lib/*

Assuming the FWD project has been locally built in c:\fwd, the following commands will create and install the FWD application server binaries in the c:\opt\fwd\lib folder:

mkdir c:\opt\fwd\lib
copy c:\fwd\dist\server\* c:\opt\fwd\lib\
copy c:\fwd\build\lib\p2j.jar c:\opt\fwd\lib\
takeown /U fwd /F c:\opt\fwd\lib /R
cacls c:\opt\fwd /E /P fwd,r
cacls c:\opt\fwd\lib /E /P fwd,r
cacls c:\opt\fwd\lib\* /E /P fwd,r

Database JDBC Driver(s)¶

Both the H2 and PostgreSQL JDBC drivers are present in the manifest of the fwd.jar file. They will be automatically pulled into the distribution when FWD is built. Due to their inclusion in the manifest, these drivers do not need to be explicitly added to the FWD server's classpath when starting your application.

If any other JDBC driver is needed, make sure that it is available and is explicitly added to the classpath when the server is started.

Necessary Jar Files¶

The FWD runtime will be found in the fwd/build/lib/p2j.jar file. Not all jars in the fwd build are required for the FWD Application Server to run; use the gradlew distribution command in the FWD build project to create the list of Application Server dependencies; after executing this, these dependencies will be found in the fwd/dist/server folder. For more details on each of the jars dependency, see the Software_Dependencies chapter.

Make sure all the files in the fwd/dist/server folder and the fwd/build/lib/p2j.jar file are copied with your application or in the FWD application server (i.e. /opt/fwd/lib).

Text Collator¶

Note:
The content of this page is deprecated. It is temporarily kept just for reference on older installations (installations of FWD with versions older than FWD v4, such as the public downloads mentioned above). Please navigate to H2 String Collation Service Provider Installation for the new version of the resource.
______________

H2 is an in-memory database used implicitly by the FWD runtime for legacy temp-table support and for other internal purposes. This means that even if the permanent database servers being used are not H2, a Java-based text collator used by H2 must be installed on the machine where the FWD Application Server is run. If a permanent database is H2 and is on a different machine, then it must be installed there, too.

To ensure that each H2 database collates its string data in the same manner as Progress, a custom implementation of java.text.spi.CollatorProvider is used. This resource is installed and made available to the FWD runtime using the Java Extension Mechanism. This is necessary in order for J2SE's Locale and related classes to have access to the custom collation services that are needed by FWD.

Make sure that you have built FWD already, so that the p2jspi.jar is available.

Linux Windows

To enable this support, the p2jspi.jar file must be copied from the $FWD/build/lib directory to the Java Extension directory for the target JVM. For an Oracle JVM, this directory is located at $JAVA_HOME/jre/lib/ext. Note that administrator rights may be required, depending upon where the JVM is installed.

If the $JAVA_HOME is set, assume it corresponds to a (for example) /usr/lib/jvm/default-java/ path; otherwise, this path must be found if the JAVA_HOME environment variable is not set. Do not make the mistake of putting the p2jspi.jar into the /usr/lib/jvm/default-java/ext/ directory - this is an empty directory which is NOT used for extensions. The correct directory is /usr/lib/jvm/default-java/jre/lib/ext/ in this example.

After copying it, make sure it can be accessed by all users:

sudo chmod 0444 /usr/lib/jvm/default-java/jre/lib/ext/p2jspi.jar

To enable this support, the p2jspi.jar file must be copied to the target Java environments. The jar file must be copied to BOTH the private JRE of the installed JDK as well as to the default public JRE.

If the JDK home directory is c:\jdk180\, then the p2jspi.jar file must be copied to c:\jdk180\jre\lib\ext which is the "private JRE" location.

Assuming the home directory of your default public JRE is C:\Program Files\Java\jre1.8.0_(RELEASE), the p2jspi.jar must be copied to C:\Program Files\Java\jre1.8.0_(RELEASE)\lib\ext. (A quick and relatively reliable way to find out the default JRE location is to issue the command java -verbose and see where is the rt.jar file loaded from.)

The reason the copy must occur to multiple locations is because different methods of running Java code or its utility programs, may lookup the Java environment differently. Programs may use hidden pathing information in the Windows registry, or the JAVA_HOME environment variable.

To copy p2jspi.jar, administrator permissions may be required if Java was installed in the default location. After copying it, check if the other users have read access to this file.

For the temp-table and dirty databases, the server will automatically default to use the en_US_P2J collation.

To set this value for permanent databases or to override the default for the temp-table and dirty databases, requires a configuration entry in the FWD directory. Please see the Directory and Directory Configuration Reference chapters for more information on the FWD directory.

The directory node path is /server/standard/database/{database_name}/p2j/embedded-collation. The default setting should be en_US_P2J, as in:

<node class="container" name="p2j">
    ...
  <node class="string" name="embedded-collation">
    <node-attribute name="value" value="en_US_P2J"/>
  </node>
</node>

Currently, this custom collation service provider only exists for the ISO-8859-1 character set. If you need to support Progress-like collation for a different character set, you most likely will need to provide a new, custom implementation of java.text.spi.CollatorProvider, which requires special preparation/packaging. Please refer to the Internationalization chapter for additional information.

When using H2 for a permanent database (embedded or not), if the core structure DDL generated during M0 is not used to create the tables, then the collation must be set manually before any table is created. Just execute the following command with the database:

set collation en_US_P2J;

The default setting for the collation can be found in the p2j.cfg.xml file, under the cfg/schema/namespace/dialect-specific/collation node. This value is used during M0 to generate the set collation DDL for the H2 dialect.

<schema metadata="standard" >
   <namespace name=”...”>
...
      <dialect-specific name="h2">
         <parameter name="collation" value="en_US_P2J" />
      </dialect-specific>
   </namespace>
</schema>

Currently, only the en_US_P2J collation is supported.

If the p2jspi.jar file is installed properly and the FWD directory has the embedded-collation property set correctly, the FWD runtime environment will initialize the embedded H2 databases to use the en_US_P2J collation upon server startup.

If the JVM cannot find the en_US_P2J collation rules upon server startup, the following error message is issued to the server log:

Error setting P2J-specific collation;  please ensure p2jspi.jar is installed in Java extension directory

This is a fatal error, which indicates that the p2jspi.jar file is not properly installed as a Java Extension for the server's JVM. In this case, double check that you have installed the jar file for the JVM actually being used to launch the FWD server (avoiding a common mistake when multiple JVMs are installed on a development system), and ensure that you have copied the jar to the correct ext subdirectory (since the HotSpot JVM misleadingly has two of them, as discussed above).

Converted Application¶

Most (if not all) FWD server installations will be used for executing an ABL application which has been converted to Java. Please see the Conversion Handbook for details on how to setup and run the conversion process.

The output of the conversion process is one or more application jar files. These jar files must be copied from the conversion project's build directory into a directory on the application server system. This directory name can be arbitrary.

Linux Windows

Assume that the application name is app and that the conversion project is on the local machine in /opt/cvt/. A target directory for the installation might be /opt/fwd/ and the application jar files might be placed in /opt/fwd/app/.

Usually, the application jars will be found in the conversion project home directory as build/lib/*.jar. These will NOT be found under the FWD project build directory (e.g. fwd/build/lib/). Here are the commands to set this up:

sudo install -d /opt/fwd/app
sudo cp /opt/cvt/build/lib/*.jar /opt/fwd/app/
sudo chown -R fwd:fwd /opt/fwd/app
sudo chmod 0550 /opt/fwd/app/
sudo chmod 0440 /opt/fwd/app/*

Assume that the application name is app and that the conversion project is on the local machine in c:\opt\cvt. A target directory for the installation might be c:\opt\fwd\ and the application jar files might be placed in c:\opt\fwd\app\.

Usually, the application jars will be found in the conversion project home directory as build\lib\*.jar. These will NOT be found under the FWD project build directory (e.g. fwd\build\lib\). Here are the commands to set this up:

mkdir c:\opt\fwd\app
copy c:\opt\cvt\build\lib\*.jar c:\fwd\app
takeown /U fwd /F c:\opt\fwd\app /R
cacls c:\opt\fwd\app /E /P fwd,r
cacls c:\opt\fwd\app\* /E /P fwd,r

In addition to the converted application jar files, arbitrary customer-specific Java application code can be loaded, run and accessed inside the FWD Application Server. Copy any customer-specific application jar files into a directory on the application server system. It can be the same or a different directory as the location of the FWD and converted application jar files.

There is no technical requirement that the FWD jars must be in a different directory from the application jars. Rather, it is highly desirable to keep the FWD jars separate from the application/customer-specific jars so that over time it is easier to update the code separately. Generally, changes may happen to converted application code separately from changes occurring to the FWD project. By keeping the jars separate, updates are made easier.

Server Configuration Files¶

Part 3 of this book documents how to configure the FWD Application Server. Each FWD Server instance requires the following server configuration files:

fully configured directory file
server bootstrap configuration file
server key store
server trust store

Use the above links to understand how to create the associated files. The Quick Start section will provide details on how to use ChUI and GUI project templates to make it easier to create a working configuration.

The server truststore is a requirement only if your application uses Web clients or Appserver Agents, to allow the FWD application server to spawn such clients - see Spawner Setup and Configuration page for details how to install the spawner. The FWD application server on its own doesn't require the truststore to be deployed with it.

Copy each of these files into a directory on the application server system which will be the current (or working) directory for the FWD application server process.

Linux Windows

Assuming that the FWD server's working directory will be /opt/fwd/server/ and the configuration files exist in ~/cfg/, use these commands:

sudo mkdir /opt/fwd/server
sudo cp ~/cfg/directory.xml /opt/fwd/server/
sudo cp ~/cfg/server.xml /opt/fwd/server/
sudo cp ~/cfg/key.store /opt/fwd/server/
sudo chown fwd:fwd -R /opt/fwd/server/
sudo chmod 0770 /opt/fwd/server
sudo chmod 0660 /opt/fwd/server/directory.xml
sudo chmod 0440 /opt/fwd/server/server.xml /opt/fwd/server/key.store

Assuming that the FWD server's working directory will be c:\opt\fwd\server\ and the configuration files exist in c:\cfg\, use these commands:

mkdir c:\opt\fwd\server
copy c:\cfg\directory.xml c:\opt\fwd\server\
copy c:\cfg\server.xml c:\opt\fwd\server\
copy c:\cfg\key.store c:\opt\fwd\server\
takeown /U fwd /F c:\opt\fwd\server /R
cacls c:\opt\fwd\server /E /P fwd,c
cacls c:\opt\fwd\server\directory.xml /E /P fwd,c
cacls c:\opt\fwd\server\server.xml /E /P fwd,r
cacls c:\opt\fwd\server\key.store /E /P fwd,r

Server Startup Script¶

Full details on how to launch the FWD Application Server can be found in Running the Server.

Assuming that the startup script documented in that chapter is used to start the server, the following needs to be done:

Linux	Windows
Your converted application was installed in `/opt/cvt`. Assuming your application is installed in `/opt/fwd/`, use these commands: cd /opt/fwd/ sudo cp /opt/cvt/deploy/server/server.sh server/ sudo chown fwd:fwd server/server.sh sudo chmod 0550 server/server.sh	Your converted application was installed in `c:\opt\cvt`. Assuming your application is installed in `c:\opt\fwd\`, use these commands: cd c:\opt\fwd\ copy c:\opt\cvt\deploy\server\server.cmd server\ takeown /U fwd /F c:\opt\fwd\server /R cacls server\server.cmd /E /P fwd,r

The script will setup the FWD Application Server's classpath to include the application jar files (converted and also any other customer-specific jars). These are prepended to the classpath.

Set File System Permissions¶

Ensure that the following permissions are set for the FWD application server's user account (fwd):

the FWD installation and the application folder will be owned by the fwd user
it must be able to launch a java process with the necessary amount of RAM to provide for the maximum heap size + some amount of overhead in the JVM itself
it must be able to read all of the jar files copied from the FWD build
it must be able to read all of the jar files copied from the converted application build
it must be able to read all of the customer-specific application jar files, including any 3rd party jars that are used from the application
it must have read and write and change directory access to the entire contents of the directory in which the FWD application server configuration files have been copied (the FWD application server may edit the configuration files and will write its log files to this directory)
the startup script must have read and execute permissions
the server configuration files (except for the directory) should be read-only and only visible to the fwd user
the server's directory file should be read/write and only visible to the fwd user
it must be able to establish an outbound TCP socket connection (with subsequent 2-way communication) to the Database Server host and port needed for the database access
it must be able to open and listen for inbound TCP socket connections (with subsequent 2-way communication) on at least 1-3 ports (a secure socket, an insecure socket and a HTTPS server socket used by web or embedded clients and for administrative purposes)
it must have read access for the installed p2jspi.jar collator

The following table collects all commands to set the permissions for the FWD application server installation:

Linux

Windows

sudo chown -R fwd:fwd /opt/fwd
sudo chmod 0550 /opt/fwd/ /opt/fwd/lib /opt/fwd/app
sudo chmod 0440 /opt/fwd/lib/* /opt/fwd/app/*
sudo chmod 0770 /opt/fwd/server
sudo chmod 0660 /opt/fwd/server/directory.xml
sudo chmod 0440 /opt/fwd/server/server.xml /opt/fwd/server/key.store
sudo chmod 0550 server/server.sh
sudo chmod 0444 /usr/lib/jvm/default-java/jre/lib/ext/p2jspi.jar

takeown /U fwd /F c:\opt\fwd\ /R
cacls c:\opt\fwd /E /P fwd,r
cacls c:\opt\fwd\lib /E /P fwd,r
cacls c:\opt\fwd\lib\* /E /P fwd,r
cacls c:\opt\fwd\app /E /P fwd,r
cacls c:\opt\fwd\app\* /E /P fwd,r
cacls c:\opt\fwd\server /E /P fwd,c
cacls c:\opt\fwd\server\directory.xml /E /P fwd,c
cacls c:\opt\fwd\server\server.xml /E /P fwd,r
cacls c:\opt\fwd\server\key.store /E /P fwd,r
cacls server\server.cmd /E /P fwd,r

Automatically Starting the Application Server at System Startup¶

Linux Windows

Create the following file /etc/systemd/system/fwd.service with 0644 permissions.

[Unit]
Description=FWD Application Server
After=network.target

[Service]
User=fwd
WorkingDirectory=/opt/fwd/deploy/server/
ExecStart=/opt/fwd/deploy/server/server.sh

[Install]
WantedBy=multi-user.target

If you have an embedded web client application server, create the following file /etc/systemd/system/fwd_embedded_web.service with 0644 permissions.

[Unit]
Description=FWD Embedded Web Client Application
After=network.target

[Service]
User=fwd
WorkingDirectory=/opt/fwd/embedded/run/
ExecStart=/opt/fwd/embedded/run/embedded_server_cfg_launch.sh

[Install]
WantedBy=multi-user.target

If you use a different user than fwd, make sure to change the value for User= to match. If you have a different install directory, make that match.

At this point you can then start and stop the FWD server and the embedded web client application using sudo systemctl start fwd, sudo systemctl stop fwd, sudo systemctl start fwd_embedded_web and sudo systemctl stop fwd_embedded_web. The two servers will also start and stop when the server starts and stops. Finally, please note that both .sh scripts that are executed are written to redirect both STDOUT and STDERR to log files. The redirection is not done using systemd.

To enable the service to run: systemctl enable fwd.service

For now to make the application server to automatically start when system boot(meaning running servers as Windows service) the third party tool NSSM has to be used. It can be downloaded from here.

To use it the downloaded archive must be unpacked at some place. There are two versions of the nssm.exe file inside package, for 32-bit and 64-bit systems. Choose one that match the OS ad copy nssm.exe to the directory on the Path.

When the nssm.exe is on the Path it is possible to install the service:

1. Ensure the user to run the servers exists on the configured workstation and has a password defined.
2. Open the command line console executed with administrator permission.
3. Install the required services:

nssm.exe install FwdApplicationServer c:\opt\fwd\deploy\server\server.cmd

for application server or

nssm.exe install FwdEmbeddedServer c:\opt\fwd\embedded\run\embedded_server_cfg_launch.cmd

The names of the services(FwdApplicationServer and FwdEmbeddedServer) can be arbitrary, the point is they must be different. Each service must have unique reference name to post configure, stop or start.
4. Ensure the service has been created successfully. Start GUI to verify settings:

nssm.exe edit FwdApplicationServer

nssm.exe edit FwdEmbeddedServer

Check to enable autostart mode. When all is done - press Install service button to complete the service edit.
5. Elevate the service descriptor rights by adding the entry for all authenticated users:

D:(A;;CCLCSWLOCRRCGAFA;;;AU)...

This is not replacement string, it is required first to get the current value by command:

sc sdshow FwdApplicationServer

sc sdshow FwdEmbeddedServer

Store the output somewhere and add the new entry to existed value, then replace by

sc sdset FwdApplicationServer newValue

sc sdset FwdEmbeddedServer newValue

Additional information for usage nssm.exe can be found on the project documentation page: http://nssm.cc/usage/.

The service can be stopped/started by regular Windows command:

sc stop FwdApplicationServer
sc start FwdApplicationServer

sc stop FwdEmbeddedServer
sc start FwdEmbeddedServer

Firewall¶

Any firewall support must be configured to allow the following:

outbound TCP socket connection (with subsequent 2-way communication) to the Database Server host and port needed for the database access
inbound TCP socket connections (with subsequent 2-way communication) on at least 1-3 ports (a secure socket for FWD client access, an optional insecure socket for FWD client access and a HTTPS server socket used by web or embedded clients and for administrative purposes)

The actual ports being used is a matter of configuration when starting the application server (and the database server).

TODO: how to determine the application server ports in use?

TODO: how to determine the database server ports (this is best put in the database chapters BUT we need to reference it here)?

First Time Java Usage - Windows only¶

Not depending on what process is running, server or client if the java.exe application is executing for the first time and the firewall Windows component is active it will ask the user to confirm the java.exe permissions to access network features where the client/server pair will run. The shape of the picture, dialog can vary from one Windows version to another but the action to do is the same - allow java.exe to communicate over required networks.

The sample picture for Windows 7 system:

In this example it is required to press Allow access button to continue working. This is only one time action per system configuration process.

File System Structure¶

Based on this chapter, the following is the proposed relative file structure of a deployed FWD Application Server. All of these paths are relative to the application install directory (/opt/fwd/ for linux and c:\opt\fwd for Windows OS).

Although in recent Windows versions it is possible to use the / as file separator, this does not work in Windows XP. In Windows XP only the backslash (\) character is allowed, in both 32-bit and 64-bit. The forward slash (/) is supported (but not required) from Windows 7 and later. Because of this quirk, all pathing has been documented using backslashes, since these work in all Windows versions.

For next steps, see the Quick Start page or for details on how to use and setup the clients, see the Client Installation page.

Linux File/Path	Windows File/Path	Description
`lib/p2j.jar`	`lib\p2j.jar`	The core FWD jar file which includes all the FWD conversion and runtime tools.
`lib/*.jar`	`lib\*.jar`	All the other jar files upon which FWD application server depends.
`app/`	`app\`	Location for your application jar files (both converted and other application-specific (including 3rd party jars that are not used by FWD).
`server/server.sh`	`server\server.cmd`	Server startup script.
`server/directory.xml`	`server\directory.xml`	Primary configuration file for the FWD server.
`server/server.xml`	`server\server.xml`	Bootstrap configuration file which holds the minimum configuration values needed to initialize the server and its networking. It tells the server how to connect to the directory. All other configuration data is stored in the FWD Directory.
`server/key.store`	`server\key.store`	The keystore is a password protected storage file for the server's private key, which is encrypted and decrypted using the given password. This allows a slightly better level of security than without the encryption. However it is essential that both the keystore and the password be kept in a secure location.
`embedded/run/embedded_server_cfg_launch.sh`	`embedded\run\embedded_server_cfg_launch.cmd`	Embedded web client application server startup script.

java_allow_network_access_win7.jpg (130 KB) Constantin Asofiei, 03/07/2017 09:59 AM

Project

General

Profile

FWD

Wiki

Application Server Installation¶

System Requirements¶

Hardware¶

Software¶

Networking¶

Network Path to Clients¶

Network Path to the Database Server¶

Choosing the Appropriate JVM¶

Installation Process¶

Install the Java Virtual Machine¶

Create the Server's User Account¶

Install FWD Application Server¶

Database JDBC Driver(s)¶

Necessary Jar Files¶

Text Collator¶

Converted Application¶

Server Configuration Files¶

Server Startup Script¶

Set File System Permissions¶

Automatically Starting the Application Server at System Startup¶

Firewall¶

First Time Java Usage - Windows only¶

File System Structure¶