Installation Process

This guide describes how to perform the following operations:

• A first/clean install of FintechOS v18.1.9

• An upgrade from FintechOS v16.6.0 and higher to FintechOS v18.1.9

To follow along, we recommend you have at least the below IT professional skills:

• Windows Server administration - beginner level

• Network administration - the level required for your network

• IIS administration - beginner level

• SQL Server administration - beginner level

• Raw XML file editing - medium level

This document is available in 3 formats, all with exactly the same content. Use the format most suitable to your need, as follows:

• HTML (the .html file) if you want to read this guide on a screen. This guide looks best in this format.

• PDF (the .pdf file) if you want to print this guide.

• AsciiDoc (the .adoc file) only if you want to compare this guide with one of its previous AsciiDoc versions in order to see exactly what changed.

Essential terms

FintechOS (a.k.a. FTOS) release [kit]

A FTOS release is a FTOS variant/build recognized by the FintechOS organization.

A FTOS release kit is a set of files containing all items necessary to install or upgrade to the release associated with the kit.

FTOS installation [component]

A FTOS installation is a collection of installed components, including configurations, setup to work together with a sufficient level of independence from other [FTOS] installations.

Example 1: FTOS Installation Component Examples

• One or more FTOS SQL Server databases

• One or more FTOS IIS web applications

• One or more FTOS Windows services

• One or more Windows/Active Directory accounts created to be used by other FTOS installation component(s) (e.g., a FTOS Windows service)

• One or more firewall/router configurations required by other FTOS installation component(s) (e.g., a route setup to let a FTOS IIS web application access a FTOS SQL Server database)

FTOS installation components are chosen with a level of granularity that ensures successful upgrade/uninstall without disturbing other [FTOS] installations which exist side-by-side (e.g., a database is a FTOS installation component, not the whole SQL Server instance; a web application or Windows service are FTOS installation components, not the whole IIS web site or machine; etc.)

FTOS installation components might be shared with other [FTOS] installations (e.g., you might account certain firewall/routing/SQL Server server-level/IIS server-level configurations as belonging to multiple [FTOS] installations).

FTOS environment

A FTOS environment is a stable definition and context for a series of FTOS installations. A FTOS installation has a single associated FTOS environment (that is, a FTOS installation is installed in a FTOS environment).

The FTOS environment is defined and its context is created before any FTOS installation is installed in it, according to environment’s definition. The environment continues to exist even at times when, temporarily, no associated installation exists.

Servicing operation

Any major operation executed by following this guide, such as: first/clean install or upgrade.

Local path

A local path specified in Windows local path syntax, pointing to a file or directory. (such as: C:\Program Files (x86), C:\Windows\winhlp32.exe)

Windows Network share

A file or directory made accessible (a.k.a. shared) over the local Microsoft Windows Network.

UNC path

A network path specified in UNC syntax, pointing to a Windows Network share. (such as: \\APPSRV02\SharedDocs, \\FILESRV2\Kit\install.exe)

How to use this guide

The guide is structured in chapters, each with sections and sub-sections. Each chapter is dedicated to one major FTOS installation component and details how to perform servicing operations on said component.

Each chapter provides instructions as if its component is the only one that needs to be installed/upgraded in the FTOS environment. This was necessary to provide you with an easy to follow overall document structure but it means you need to slightly adjust instructions when applying a servicing operation to a FTOS environment as a whole. See the tips below for help on how to do that.

Even though considerable effort has been spent to provide you with a well designed document structure and instructions that are as ready to use as possible, this guide is not something to be followed 100% mechanically. Instead, you must use it as a basis for developing your Operations runbooks for FTOS and when doing so you must apply your professional skills (and common sense) to adjust the provided instructions [4: Your FTOS Operations runbooks should contain much more than just slightly adjusted instructions from this guide. Runbooks must contain step by step ready to use instructions for your FTOS environment(s) (with real machine names/IPs, directory/file paths, etc.) including instructions related to the IT infrastructure surrounding the FTOS environment (e.g. pre-upgrade backup, pre-upgrade suspend and post-upgrade resume monitoring of the FTOS environment, disaster recovery instructions in case a change runs into a major failure, pre-upgrade suspend and post-upgrade resume access to the FTOS environment via firewall rules, etc.] in order to obtain runbooks that can be followed 100% mechanically in your particular context (or you can automate runbooks through scripts or DevOps automation server jobs (e.g. Ansible Tower, RunDeck, Jenkins, etc.)).

About doc-vars

Many instructions in this guide require you to customize them for your particular FTOS environment and then execute the customized result (e.g. customize a command line provided by FTOS by filling in an actual path to an installation directory of your choice or the name/IP of a machine of your choice).

To provide you with the most ready to use instructions, this guide uses document variables (a.k.a. doc-vars), which are a mechanism to express concise references to something that was previously associated with the referenced variables.

Doc-vars definition and scope

Doc-vars are always defined before they are used and their definition has a scope. With the exception of doc-vars defined in Global doc-vars definitions which apply to the whole guide, all other doc-vars are defined in special sub-sections named "Doc-var definitions" and by default apply only to the parent section and all its sub-sections.

Example 2: Doc-vars scope

To find the definition of a doc-var reference, you must go upwards through the parent sections looking in each "Doc-var definitions" sub-section, finishing with the special Global doc-vars definitions section.

Doc-vars textual values, simple vs. complex nature and meaning vs. placeholder references

Doc-vars always have associated a meaning provided in their definition. In their definition you can find two additional optional associations:

• A textual value that you have to determine/choose and then replace in all the instructions where the doc-var is referenced as a placeholder for the specified value.

• A collection of sub-doc-vars

Doc-vars that have a sub-doc-vars collection are called complex doc-vars. Unless otherwise specified in their definition, they do not have a directly associated textual value.

Doc-vars that do not have a sub-doc-vars collection are called simple doc-vars. Unless otherwise specified in their definition, they have an associated textual value.

Doc-var references are mentions of their names written with a special style that makes it obvious in context that a doc-var is referenced, which doc-var is referenced and how the reference is to be interpreted.

Let’s assume we have two doc-vars defined like this:

ComponentX - Complex doc-var. Represents component X installation.

ComponentX_InstallDir - Simple doc-var. Represents parent doc-var’s installation directory.

The simplest type of doc-var reference is a meaning reference, which points to the meaning of the doc-var from its definition. If the doc-var has an associated textual value, it can be ignored for this kind of reference.

A meaning reference can appear anywhere and it is styled like: ComponentX.

Example 3: A more extended meaning reference example

The other kind of reference is a placeholder reference, which points to the textual value associated with the doc-var and demands you to replace the reference with the textual value. A placeholder reference naturally also points to the meaning of the doc-var, helping you to better understand the context where it appears.

A placeholder reference is usually embedded in text that you must otherwise use verbatim (such text has its own style in a monospaced font) and it is styled like: ComponentX_InstallDir

Example 4. A more extended placeholder reference example

Execute in cmd.exe:

MD "ComponentX_InstallDir"
xcopy.exe /I /S . "ComponentX_InstallDir"
CD /D "ComponentX_InstallDir"

Assuming the textual value of ComponentX_InstallDir is C:\CompX, the previous instructions must be interpreted as:

MD "C:\CompX"
xcopy.exe /I /S . "C:\CompX"
CD /D "C:\CompX"

Doc-var names

Names for doc-vars that are not sub-doc-vars (i.e. doc-vars that do not have a parent doc-var) are made out of only alphanumerical characters (e.g. ComponentX).

Names for doc-vars that are sub-doc-vars are composed from parent doc-var name, followed by an underscore, followed by their own name made out of only alphanumerical characters (e.g. ComponentX_InstallDir).

Global doc-vars definitions

ReleaseKit

Complex doc-var. Represents the FTOS release kit associated with this guide. You must either be told where to find it or you already know if you are now reading the guide copy found in the FTOS release kit.

ReleaseKit_Dir

Simple doc-var. The local/UNC absolute path of ReleaseKit.

Example: C:\kits\Fintech OS\releases\FTOS-CORE-RLS-v18.1.0.0-b123-GOLD

ReleaseKit_Name

Simple doc-var. ReleaseKit_Dir directory name without path.

Example: FTOS-CORE-RLS-v18.1.0.0-b123-GOLD

ReleaseKit_VersionNo

Simple doc-var. ReleaseKit version number. Determine its value from ReleaseKit_Name by taking everything after FTOS-CORE-RLS-v until the 1st -.

Example: If ReleaseKit_Name is FTOS-CORE-RLS-v18.1.0.0-b123-GOLD then ReleaseKit_VersionNo is 18.1.0.0

TargetInstallation

Simple doc-var. Represents the FTOS installation you will service (install/upgrade) by following instructions from this guide.

TargetEnvironment

Simple doc-var. Represents the FTOS environment for TargetInstallation.

MainDb

Simple doc-var. Name you choose for the main FTOS database used by TargetEnvironment.

MainDb_OldVersionNo

Simple doc-var. MainDb version number as found before install/upgrade. Determine its value as follows:

If you’re installing MainDb based on a new/blank database:

• Then: Leave MainDb_OldVersionNo undefined because its value is not needed

• Else: Determine PortalWebApp_OldVersionNo's value

• If PortalWebApp_OldVersionNo >= 17.1.5:

  • Then: Leave MainDb_OldVersionNo undefined because its value is not needed

  • Else: If PortalWebApp_OldVersionNo >= 17.1.0:

    • Then: Set MainDb_OldVersionNo to 17.1.0

    • Else: If PortalWebApp_OldVersionNo is 16.6.0, 16.7.0, or 17.0.0

      • Then: Set MainDb_OldVersionNo to PortalWebApp_OldVersionNo

      • Else: Stop! You can't use this guide to directly upgrade MainDb. See Installation Process.

MainDb_CompatibilityLevel

Simple doc-var. SQL Server compatibility level of MainDb. Determine its value as the result of the following T-SQL ran against MainDb:

SELECT compatibility_level FROM sys.databases WHERE name = 'MainDb'

MainDbServer

Simple doc-var. Full name of the SQL Server instance you choose for hosting MainDb, as returned by the following T-SQL when ran against it:

SELECT @@SERVERNAME

MainDbServer_MaxCompatibilityLevel

Simple doc-var. Maximum SQL Server compatibility level [5: For the latest information on the supported SQL Server compatibility levels, see https://docs.microsoft.com/en-us/sql/t-sql/statements/alter-database-transact-sql-compatibility-level#arguments] supported by MainDbServer. Determine its value as follows:

• Determine MainDbServer Database Engine version as returned by the following T-SQL when ran against MainDbServer:

SELECT SERVERPROPERTY('ProductVersion')

• Use just the Major-part from the previously determined Database Engine version with the following table to determine MainDbServer_MaxCompatibilityLevel:

PortalWebApp

Complex doc-var. Represents the FTOS Portal Web Application installation component.

PortalWebApp_Machine

Simple doc-var. The name of the Windows machine you choose to host PortalWebApp on.

PortalWebApp_InstallDir

Simple doc-var. The local absolute path on PortalWebApp_Machine of a not yet existent directory where you choose to install the PortalWebApp files in.

PortalWebApp_OldVersionNo

Simple doc-var. PortalWebApp version number as found before the install/upgrade. Determine its value as follows:

• If PortalWebApp is installed (i.e. you’re performing an upgrade):

  • Then: On PortalWebApp_Machine open Windows Explorer, navigate to PortalWebApp_InstallDir\bin, right click on EBS.Core.Common.dll, click on Properties menu entry and go to Details tab. Set PortalWebApp_OldVersionNo to the value of the File Version field.

  • Else: Set PortalWebApp_OldVersionNo to 0.0.0.0

DesignerWebApp_IisAppName

Simple doc-var. Name you choose for DesignerWebApp's IIS application.

DesignerWebApp_IisAppPoolName

Simple doc-var. Name of the IIS application pool you choose to run DesignerWebApp_IisAppName in. It can be a not yet existent pool as there are instructions on how to create it.

DesignerWebApp_IisWebSiteName

Simple doc-var. Name of the IIS web site you choose to host DesignerWebApp_IisAppName in.

DesignerWebApp_UploadEbsDir

Simple doc-var. A local/UNC absolute path usable by DesignerWebApp_IisAppName to access content from PortalWebApp_UploadEbsDir.

• If DesignerWebApp_Machine is the same as PortalWebApp_Machine:

  • Then: Set DesignerWebApp_UploadEbsDir to PortalWebApp_UploadEbsDir

  • Else: Set DesignerWebApp_UploadEbsDir to an UNC absolute path that maps to the same directory as PortalWebApp_UploadEbsDir

DesignerWebApp_LoginUrl

Simple doc-var. Login URL for DesignerWebApp_IisAppName. Determine its value based on the following format http://DesignerWebApp_Machine/DesignerWebApp_IisAppName/Account/LogOn which assumes the DesignerWebApp_IisWebSiteName works on port 80 without SSL. If the assumption is wrong, adjust the format accordingly.

DesignerWebApp_DbCred

Complex doc-var. The SQL Server credential you choose for DesignerWebApp_IisAppName to use when connecting to MainDb for normal operation.

DesignerWebApp_DbCred_Type

Simple doc-var. Determine its value as follows:

• If DesignerWebApp_DbCred is a SQL Server built in authentication credential:

  • Then: Value is SqlBuiltinAuth

  • Else (i.e. it is a Windows integrated authentication credential): Value is WindowsAuth

DesignerWebApp_DbCred_User

Simple doc-var. If DesignerWebApp_DbCred_Type = SqlBuiltinAuth then set DesignerWebApp_DbCred_User to DesignerWebApp_DbCred's user name. Otherwise leave DesignerWebApp_DbCred_User undefined.

DesignerWebApp_DbCred_Password

Simple doc-var. If DesignerWebApp_DbCred_User is defined then set DesignerWebApp_DbCred_Password to DesignerWebApp_DbCred password. Otherwise leave DesignerWebApp_DbCred_Password undefined.

JobServer

Complex doc-var. Represents a FTOS JobServer installation component. As this component can be installed in multiple instances and configurations, JobServer as defined here does not represent any of them in particular. The doc-var will be reassigned a more practical meaning in later instructions. This component has been introduced starting with FTOS v18.1.0.

DebuggingServer

Complex doc-var. Represents the FTOS DebuggingServer installation component.

DebuggingServer_Machine

Simple doc-var. The name of the Windows machine you choose to host DebuggingServer.

DebuggingServer_InstallDir

Simple doc-var. The local absolute path on DebuggingServer_Machine of a not yet existent directory where you choose to install the DebuggingServer files.

DebuggingUi

Complex doc-var. Represents the FTOS DebuggingUi installation component.

DebuggingUi_Machine

Simple doc-var. The name of the Windows machine you choose to install DebuggingUi.

DebuggingUi_InstallDir

Simple doc-var. The local absolute path on DebuggingUi_Machine of a not yet existent directory where you choose to install the DebuggingUi files.

General considerations

1. On any Windows Server machine you must operate with a Windows / Active Directory account that is in the local Administrators group, working in elevated mode (i.e. running as Administrator).

2. The Windows / Active Directory account that you use must have full access rights on ReleaseKit_Dir (some instructions produce logs which by default are written in the ReleaseKit_Dir).

3. On any SQL Server instance you must operate with a SQL Server account that is in the sysadmin SQL Server role.

4. About instructions where you have to execute BasicDbUpgrader.exe

• You can execute this tool from any machine with connectivity to MainDb as long as the machine has .NET Framework >= 4.5 and SQLCMD.EXE installed. SQLCMD is auto-installed with SQL Server Management Studio but it can also be installed by itself.

• BasicDbUpgrader.exe instructions will work exactly as provided if MainDbServer uses dynamic ports and you can connect via Windows integrated authentication. If you need to connect to a specific port or with SQL Server built in authentication then you will need to slightly adjust the given instructions. Run BasicDbUpgrader.exe without any arguments to see help on how to do that (see -s, -u and -p parameters).

• The account you use with BasicDbUpgrader.exe to apply servicing operations (e.g. to apply upgrade/migration scripts) on MainDb, must be in the sysadmin SQL Server role.

5. You must edit text files (including compare and merge editing; including XML and cmd.exe batch file editing) with an editor [6: Unless you have better options, for general text file editing we recommend the freely available https://notepad-plus-plus.org while for compare-and-merge text file editing we recommend the freely available http://winmerge.org] that supports UTF8 with and without BOM and does not change file encoding on save.

6. If you have trouble when editing XML that requires XML encoding, use a specialized XML editor [7: Unless you have better options, we recommend the freely available https://github.com/Microsoft/XmlNotepad/releases].

7. You must notice if any instructions are terminated by an error signaled through common patterns (e.g. error popup window / message box, obvious terminating error message printed in a console window) and, unless specifically instructed otherwise in context or by FTOS Support or it is clear for you how to fix the problem (e.g. out of space), stop following the normal instructions and instead abandon the servicing operation and revert TargetEnvironment to a previous good state.

8. Once you successfully went through a servicing operation where you defined/changed doc-vars you must save these values with your Operations documentation. You must retrieve the saved doc-var values before executing a servicing operation that requires them (e.g. upgrade).

9. Where this guide mentions something as applicable for a certain chapter, section or sub-section, you must consider it applicable for all its deeper sub-sections, unless otherwise specified.

MainDb

Prerequisites

MainDbServer must be SQL Server 2012 or newer:

• With the following installed features:

  • Database Engine Services

  • Client Tools Connectivity

• With SQL_Latin1_General_CP1_CI_AS as server level collation, as returned by the following TSQL:

SELECT SERVERPROPERTY('collation');

First/clean install

You should execute instructions from this section on the machine hosting MainDbServer. You can execute them from any machine that can execute T-SQL against MainDbServer but, if you need to, it will be more difficult to restore MainDb from a backup file.

Choose to install MainDb in one of the following two ways:

• Based on a main FTOS database from another FTOS environment (or an older version of MainDb)

  • This choice is common when TargetEnvironment is a clone of another environment (e.g. TargetEnvironment is an UAT environment and it is cloned from a PROD environment)

• Based on a new/blank database

  • This choice is common when TargetEnvironment is built from scratch using just resources from ReleaseKit

Based on a main FTOS database from another FTOS environment

1. Create a SQL Server backup file for the main FTOS database from the other environment.

2. Copy/move the backup file to a location that can be accessed by MainDbServer

3. Create MainDb on MainDbServer by restoring from the backup file

4. If MainDb_CompatibilityLevel < MainDbServer_MaxCompatibilityLevel, Then: Execute the following T-SQL against MainDb:

ALTER DATABASE MainDb SET COMPATIBILITY_LEVEL =
MainDbServer_MaxCompatibilityLevel

5. Grant full access on MainDb for DesignerWebApp_DbCred and PortalWebApp_DbCred

Based on a new/blank database

1. Create MainDb as a new SQL Server database on MainDbServer

2. If MainDb_CompatibilityLevel < MainDbServer_MaxCompatibilityLevel, Then: Execute the following T-SQL against MainDb:

ALTER DATABASE MainDb SET COMPATIBILITY_LEVEL =
MainDbServer_MaxCompatibilityLevel

3. Execute in cmd.exe: "ReleaseKit\SQL\BasicDbUpgrader.exe" -s "MainDbServer" -d "MainDb" -i

4. Follow all steps from MainDb \ Upgrade

5. Grant full access on MainDb for DesignerWebApp_DbCred and PortalWebApp_DbCred

Upgrade

You must execute instructions from this section on a machine that can connect and execute T-SQL against MainDbServer.

1. Execute in cmd.exe: "ReleaseKit\SQL\BasicDbUpgrader.exe" -s "MainDbServer" -d "MainDb"

• If the command was terminated by an error like Db is not initialized for use with BasicDbUpgrader and MainDb_OldVersionNo is between 16.6.0 and 17.1.5, Then execute in cmd.exe: "ReleaseKit\SQL\BasicDbUpgrader.exe" -s "MainDbServer" -d "MainDb" -i -v "MainDb_OldVersionNo"

2. Execute in cmd.exe: "ReleaseKit\SQL\BasicDbUpgrader.exe" -s "MainDbServer" -d "MainDb" -g

• This command will upgrade MainDb and it will take a few minutes to complete, depending mostly on how old MainDb_OldVersionNo is vs. ReleaseKit_VersionNo

PortalWebApp

Prerequisites

On PortalWebApp_Machine:

• Windows Server 2008 R2 SP1 or newer

• Required Server Roles: Web Server (IIS)

• Required Features:

  • .NET Framework 3.5 Features \ .NET Framework 3.5 (includes .NET 2.0 and 3.0)

  • .NET Framework 4.5 Features \ .NET Framework 4.5

  • .NET Framework 4.5 Features \ ASP.NET 4.5

  • .NET Framework 4.5 Features \ WCF Services \ HTTP Activation

  • .NET Framework 4.5 Features \ WCF Services \ TCP Port Sharing

  • Windows PowerShell \ Windows PowerShell 4.0

  • Windows Process Activation Service \ Process Model

  • Windows Process Activation Service \ Configuration APIs

• Required Web Server Role (IIS) \ Role Services:

  • Web Server \ Common HTTP Features \ Default Document

  • Web Server \ Common HTTP Features \ Directory Browsing

  • Web Server \ Common HTTP Features \ HTTP Errors

  • Web Server \ Common HTTP Features \ Static Content

  • Web Server \ Common HTTP Features \ HTTP Redirection

  • Web Server \ Health and Diagnostics \ HTTP Logging

  • Web Server \ Performance \ Static Content Compression

  • Web Server \ Performance \ Dynamic Content Compression

  • Web Server \ Security \ Request Filtering

  • Web Server \ Security \ Basic Authentication

  • Web Server \ Security \ URL Authorization

  • Web Server \ Security \ Windows Authentication

  • Web Server \ Application Development \ .NET Extensibility 4.5

  • Web Server \ Application Development \ Application Initialization

  • Web Server \ Application Development \ ASP.NET 4.5

  • Web Server \ Application Development \ ISAPI Extensions

  • Web Server \ Application Development \ ISAPI Filters

  • Web Server \ Application Development \ Server Side Includes

  • Web Server \ Application Development \ WebSocket Protocol

  • Web Server \ Management Tools \ IIS Management Scripts and Tools

• .NET Framework 4.6.2 or newer

• Windows PowerShell 5.1 or newer

First/clean install

You must execute instructions from this section on PortalWebApp_Machine.

1. Create a new batch file named PortalWebAppInstaller.Install.bat in a directory of your choice and add in a single command line as follows:

• If PortalWebApp_DbCred_Type = SqlBuiltinAuth

  • Then: Use this command line:

powershell.exe -File "ReleaseKit\PortalWebApp\PortalWebAppInstaller.ps1" -p_MainCommand Install -p_InstallDir PortalWebApp_InstallDir -p_IisWebSite PortalWebApp_IisWebSiteName -p_IisApp PortalWebApp_IisAppName -p_IisAppPool PortalWebApp_IisAppPoolName -p_DbConnServer MainDbServer -p_DbConnSqlAuthUser PortalWebApp_DbCred_User -p_DbConnSqlAuthPass PortalWebApp_DbCred_Password -p_DbConnDb MainDb -p_UploadEBSDir PortalWebApp_UploadEbsDir

• Else: Use this command line:

powershell.exe -File "ReleaseKit\PortalWebApp\PortalWebAppInstaller.ps1" -p_MainCommand Install -p_InstallDir PortalWebApp_InstallDir -p_IisWebSite PortalWebApp_IisWebSiteName -p_IisApp PortalWebApp_IisAppName -p_IisAppPool PortalWebApp_IisAppPoolName -p_DbConnServer MainDbServer -p_DbConnDb MainDb -p_UploadEBSDir PortalWebApp_UploadEbsDir

2. Execute in cmd.exe: PortalWebAppInstaller.Install.bat

3. If PortalWebApp_UploadEbsDir is an UNC path, then:

• Modify Windows network share access rights on PortalWebApp_UploadEbsDir and grant full rights for the Windows account used by PortalWebApp_IisAppPoolName to access it.

• Modify NTFS access rights on the directory behind PortalWebApp_UploadEbsDir Windows network share and grant full access for the Windows account used by PortalWebApp_IisAppPoolName to access it.

4. Open in a web browser PortalWebApp_LoginUrl and check the page appears as expected.

Upgrade

You must execute instructions from this section on PortalWebApp_Machine.

1. Create a new batch file named PortalWebAppInstaller.Upgrade.bat in a directory of your choice and add in the following single command line: powershell.exe -File " ReleaseKit\PortalWebApp\PortalWebAppInstaller.ps1" -p_MainCommand Upgrade -p_InstallDir PortalWebApp_InstallDir

2. Execute in cmd.exe: PortalWebAppInstaller.Upgrade.bat

3. Open in a web browser PortalWebApp_LoginUrl and check the page appears as expected.

DesignerWebApp

Prerequisites

On DesignerWebApp_Machine: Same as on PortalWebApp_Machine (See PortalWebApp \ Prerequisites)

First/clean install

You must execute instructions from this section on DesignerWebApp_Machine.

1. Create a new batch file named DesignerWebAppInstaller.Install.bat in a directory of your choice and add in a single command line as follows:

• If DesignerWebApp_DbCred_Type = SqlBuiltinAuth, then use this command line:

powershell.exe -File "ReleaseKit\DesignerWebApp\DesignerWebAppInstaller.ps1" -p_MainCommand Install -p_InstallDir DesignerWebApp_InstallDir -p_IisWebSite DesignerWebApp_IisWebSiteName -p_IisApp DesignerWebApp_IisAppName -p_IisAppPool DesignerWebApp_IisAppPoolName -p_DbConnServer MainDbServer -p_DbConnSqlAuthUser DesignerWebApp_DbCred_User -p_DbConnSqlAuthPass DesignerWebApp_DbCred_Password -p_DbConnDb MainDb -p_UploadEBSDir DesignerWebApp_UploadEbsDir

• Else, use this command line:

powershell.exe -File " ReleaseKit\DesignerWebApp\DesignerWebAppInstaller.ps1" -p_MainCommand Install -p_InstallDir DesignerWebApp_InstallDir -p_IisWebSite DesignerWebApp_IisWebSiteName -p_IisApp DesignerWebApp_IisAppName -p_IisAppPool DesignerWebApp_IisAppPoolName -p_DbConnServer MainDbServer -p_DbConnDb MainDb -p_UploadEBSDir DesignerWebApp_UploadEbsDir

2. Execute in cmd.exe: DesignerWebAppInstaller.Install.bat

3. If DesignerWebApp_UploadEbsDir is an UNC path, then:

• Modify Windows network share access rights on DesignerWebApp_UploadEbsDir and grant full rights for the Windows account used by DesignerWebApp_IisAppPoolName to access it.

• Modify NTFS access rights on the directory behind DesignerWebApp_UploadEbsDir Windows network share and grant full rights for the Windows account used by DesignerWebApp_IisAppPoolName to access it.

4. Open in a web browser DesignerWebApp_LoginUrl and check the page appears as expected.

Upgrade

You must execute instructions from this section on DesignerWebApp_Machine.

1. Create a new batch file named DesignerWebAppInstaller.Upgrade.bat in a directory of your choice and add in the following single command line: powershell.exe -File " ReleaseKit\DesignerWebApp\DesignerWebAppInstaller.ps1" -p_MainCommand Upgrade -p_InstallDir DesignerWebApp_InstallDir

2. Execute in cmd.exe: DesignerWebAppInstaller.Upgrade.bat

3. Open in a web browser DesignerWebApp_LoginUrl and check the page appears as expected.

JobServer

Any FTOS JobServer instances come with a set of standard jobs configured and enabled by default. You can disable standard jobs and install additional jobs via plugins (e.g. MessageBus (OCS) plugin, MessageComposer plugin).

If JobServer_JobConfig is:

• StandardJobCfg then:

  • Go to section JobServer \ Standard job configuration

• MessageBusJobCfg then:

  • Go to section JobServer \ MessageBus (OCS) job configuration

• MessageComposerJobCfg then:

  • Go to section JobServer \ MessageComposer job configuration

• MessageBusMessageComposerJobCfg then:

  • Go to section JobServer \ MessageBus (OCS) + MessageComposer job configuration

Doc-var definitions

JobServer

Complex doc-var. Represents the FTOS JobServer installation component instance that you’re currently servicing.

JobServer_Id

Simple doc-var. Alphanumerical id you choose for JobServer. It must be unique across all JobServer instances in TargetEnvironment.

Examples: 1, Standard1, MessageBusMessageComposer2

JobServer_Machine

Simple doc-var. Name of the Windows machine you choose to install JobServer on.

JobServer_InstallDir

Simple doc-var. The local absolute path on JobServer_Machine of a not yet existent directory where you choose to install the JobServer files.

JobServer_WinSvcName

Simple doc-var. Name of the Windows service that runs JobServer. Set JobServer_WinSvcName to FtosJobServer-JobServer_Id.

JobServer_JobConfig

Simple doc-var. Determine its value depending on the job configuration you choose for JobServer:

JobServer_UploadEbsDir

Simple doc-var. A local/UNC absolute path usable by JobServer_WinSvcName to access content from PortalWebApp_UploadEbsDir.

If JobServer_JobConfig is MessageBusJobCfg or MessageBusMessageComposerJobCfg, then:

• If JobServer_Machine is the same as PortalWebApp_Machine

  • Then: Set JobServer_UploadEbsDir to PortalWebApp_UploadEbsDir

  • Else: Set JobServer_UploadEbsDir to an UNC absolute path that maps to the same directory as PortalWebApp_UploadEbsDir

• Else: Leave JobServer_UploadEbsDir undefined because its value is not needed

JobServer_DbCred

Complex doc-var. The SQL Server credential you choose for JobServer to use when connecting to MainDb for normal operation.

Prerequisites

On JobServer_Machine:

• .NET Framework 4.6.1 or newer

• Windows PowerShell 5.1 or newer

Standard job configuration

First/clean install

You must execute instructions from this section on JobServer_Machine.

1. Create directory JobServer_InstallDir

2. Copy all files from ReleaseKit_Dir\JobServer to JobServer_InstallDir

3. Edit XML file JobServer_InstallDir\connections.config as follows:

• In XML node /connectionStrings/add[@name='EbsSqlServer'] set XML attribute connectionString to a SQL Server connection string [8: For SQL Server connection string syntax see https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/connectionstring-syntax] pointing to MainDb, using JobServer_DbCred.

• Snippet from connection.config showing where you must edit:

<add name="EbsSqlServer" connectionString="Data Source=...;Initial Catalog=...;
User ID=...;Password=...; Persist Security Info= true;"
providerName="System.Data.SqlClient" />

4. Execute in cmd.exe: JobServer_InstallDir\FTOS.JobServer.Service.Install.bat JobServer_WinSvcName

Upgrade

You must execute instructions from this section on JobServer_Machine.

1. Execute in cmd.exe: sc.exe stop JobServer_WinSvcName

2. Copy with overwrite all files from ReleaseKit_Dir\JobServer to JobServer_InstallDir except for the following files:

• connections.config

• FTOS.JobServer.Service.exe.config

• schedule.config

• services.config

• serviceSettings.config

3. For each of the files excepted at the previous step, analyze the differences between version from ReleaseKit_Dir and that from JobServer_InstallDir using a text file compare tool and merge changes into the version from JobServer_InstallDir without breaking existing customizations

4. Execute in cmd.exe: sc.exe start JobServer_WinSvcName

MessageBus (OCS) job configuration

First/clean install

You must execute instructions from this section on JobServer_Machine.

1. Follow all steps from JobServer \ Standard job configuration \ First/clean install

2. Execute in cmd.exe: sc.exe stop JobServer_WinSvcName

3. Copy with overwrite all files from ReleaseKit_Dir\JobServer.Plugins\MessageBus (OCS) to JobServer_InstallDir

4. Edit XML file JobServer_InstallDir\connections.config as follows:

• In XML node /connectionStrings/add[@name='FtosConnection'] set XML attribute connectionString to a SQL Server connection string [8: For SQL Server connection string syntax see https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/connectionstring-syntax] pointing to MainDb, using JobServer_DbCre

• Snippet from connections.config showing where you must edit:

<add name="FtosConnection" connectionString="Data Source=...;Initial
Catalog=...; User ID=...;Password=...;MultipleActiveResultSets=True;"
providerName="System.Data.SqlClient" />

5. Edit XML file JobServer_InstallDir\serviceSettings.config as follows:

• In XML node /appSettings/add[@name='AttachmentPath'] set XML attribute value to JobServer_UploadEbsDir

• Snippet from serviceSettings.config showing where you must edit:

<add key="AttachmentPath" value="...\EBS.Core.Web.MVC\UploadEBS"/>

6. If JobServer_UploadEbsDir is a local absolute path:

• Then: Modify NTFS access rights on JobServer_UploadEbsDir and grant full rights for the Windows account used to run JobServer_WinSvcName.  By default this account is LocalSystem.

• Else (i.e. it is an UNC path):

  • Modify Windows network share access rights on JobServer_UploadEbsDir and grant full rights for the Windows account used by JobServer_WinSvcName to access it. By default this account is JobServer_Machine's own Windows account (i.e. a Windows / Active Directory account that has the same name as JobServer_Machine Windows machine name).

  • Modify NTFS access rights on the directory behind JobServer_UploadEbsDir Windows network share and grant full rights for the Windows account used by JobServer_WinSvcName to access it.

7. Execute in cmd.exe: sc.exe start JobServer_WinSvcName

Upgrade

You must execute instructions from this section on JobServer_Machine.

1. Follow all steps from JobServer \ Standard job configuration \ Upgrade

2. Execute in cmd.exe: sc.exe stop JobServer_WinSvcName

• Copy with overwrite all files from ReleaseKit_Dir\JobServer.Plugins\MessageBus (OCS) to JobServer_InstallDir except for the following files:

  • connections.config

  • schedule.config

  • services.config

  • serviceSettings.config

3. For each of the files excepted at the previous step, analyze the differences between version from ReleaseKit_Dir and that from JobServer_InstallDir using a text file compare tool and merge changes into the version from JobServer_InstallDir without breaking existing customizations.

4. Execute in cmd.exe: sc.exe start JobServer_WinSvcName

MessageComposer job configuration

First/clean install

You must execute instructions from this section on JobServer_Machine.

1. Follow all steps from JobServer \ Standard job configuration \ First/clean install

2. Execute in cmd.exe: sc.exe stop JobServer_WinSvcName

3. Copy with overwrite all files from ReleaseKit_Dir\JobServer.Plugins\MessageComposer to JobServer_InstallDir

4. Edit XML file JobServer_InstallDir\connections.config as follows:

• In XML node /connectionStrings/add[@name='FtosConnection'] set XML attribute connectionString to a SQL Server connection string [8: For SQL Server connection string syntax see https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/connectionstring-syntax] pointing to MainDb, using JobServer_DbCred.

• Snippet from connections.config showing where you must edit:

<add name="FtosConnection" connectionString="Data Source=...;Initial
Catalog=...; User ID=...;Password=...;MultipleActiveResultSets=True;"
providerName="System.Data.SqlClient" />

5. Execute in cmd.exe: sc.exe start JobServer_WinSvcName

Upgrade

You must execute instructions from this section on JobServer_Machine.

1. Follow all steps from JobServer \ Standard job configuration \ Upgrade

2. Execute in cmd.exe: sc.exe stop JobServer_WinSvcName

3. Copy with overwrite all files from ReleaseKit_Dir\JobServer.Plugins\MessageComposer to JobServer_InstallDir, except for the following files:

• connections.config

• schedule.config

• services.config

• serviceSettings.config

4. For each of the files excepted at the previous step, analyze the differences between version from ReleaseKit_Dir and that from JobServer_InstallDir using a text file compare tool and merge changes into the version from JobServer_InstallDir without breaking existing customizations.

5. Execute in cmd.exe: sc.exe start JobServer_WinSvcName

MessageBus (OCS) + MessageComposer job configuration

First/clean install

You must execute instructions from this section on JobServer_Machine.

1. Follow all steps from JobServer \ MessageBus (OCS) job configuration \ First/clean install

2. Follow all steps from JobServer \ MessageComposer job configuration \ Upgrade starting at step 2

Upgrade

1. Follow all steps from JobServer \ MessageBus (OCS) job configuration \ Upgrade

2. Follow all steps from JobServer \ MessageComposer job configuration \ Upgrade starting at step 2

DebuggingServer

First/clean install

You must execute instructions from this section on DebuggingServer_Machine, unless otherwise specified.

1. Create directory DebuggingServer_InstallDir

2. Copy all files from ReleaseKit_Dir\DebuggingServer to DebuggingServer_InstallDir

3. Execute in cmd.exe: powershell.exe -File "DebuggingServer_InstallDir\setup-as-service.ps1"

4. On PortalWebApp_Machine, edit XML file PortalWebApp_InstallDir\web.config and add a new child XML node named add under /configuration/appSettings:

• Add two XML attributes to the new node:

  • 1st XML attribute named key with value feature.development-debugging-server

  • 2nd XML attribute named value with value http://DebuggingServer_Machine:8080

• Snippet from web.config showing how you must edit:

<appSettings>
  <add key="feature.development-debugging-server" value="..." />
  ...
</appSettings>

DebuggingUi

First/clean install

You must execute instructions from this section on DebuggingUi_Machine.

1. Create directory DebuggingUi_InstallDir

2. Copy all files from ReleaseKit_Dir\DebuggingUi to DebuggingUi_InstallDir

3. Execute in cmd.exe: DebuggingUi_InstallDir\FTOS.Debugger.exe

4. In the newly opened Fintech-OS Debugger application click on main menu entry Server \ Connect to debug server… and type in the URL http://DebuggingServer_Machine:8080

• Alternatively, if you always use the same DebuggingServer URL, edit XML file DebuggingUi_InstallDir\FTOS.Debugger.exe.config and set the value of the XML attribute /configuration/appSettings/add[@key='feature.development-debugging-server']/@value to http://DebuggingServer_Machine:8080

• Snippet from FTOS.Debugger.exe.config showing how you must edit:

<add key="feature.development-debugging-server" value="..." />