7 0 Saa Inst Admin Guide Sol

Connectivity
Alliance Access 7.0
Installation and Administration Guide

This installation guide explains how to install and administer Alliance Access on Oracle Solaris and how to prepare the system prior to installation. This document is for system administrators and anyone that installs Alliance Access. Knowledge of Oracle Solaris is a prerequisite for readers of this document.
30 September 2011
Solaris
Alliance Access 7.0 - Solaris
Table of Contents
. reface .............................................................................................................................................................................7 P
Part A Installation .............................................................................................................................................9

1 2 Installation Features Overview ............................................................................................................... 11 Preparation ...................................................................................................................................................... 13
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 Getting Started ......................................................................................................................................... 13 Prepare the System ................................................................................................................................ 15 Tracking What Happens During Installation ....................................................................................... 19 Create the Temporary Installation Directory ....................................................................................... 19 Prepare for Non-root Installation, Upgrade, Backup, or Removal ................................................... 20 Create the sagsnlg and alliance Group ............................................................................................... 21 Prepare the Licence File ........................................................................................................................ 21 Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal) ............. 22 Protect the Passwords in the Response File ...................................................................................... 23 Prepare for a Hosted Database Installation ........................................................................................ 24 Prepare a Backup File for Upgrade ...................................................................................................... 29
Installation ........................................................................................................................................................ 32
3.1 3.2 3.3 3.4 Before You Install .................................................................................................................................... 32 Interactive Installation ............................................................................................................................. 33 Silent Installation ..................................................................................................................................... 43 Next Steps ................................................................................................................................................ 47
Upgrade ............................................................................................................................................................. 59
4.1 4.2 4.3 4.4 Before You Upgrade ............................................................................................................................... 59 Interactive Upgrade ................................................................................................................................. 62 Silent Upgrade ......................................................................................................................................... 70 Next Steps ................................................................................................................................................ 74
Relicensing ...................................................................................................................................................... 77
5.1 5.2 5.3 5.4 Before You Relicense ............................................................................................................................. 77 Interactive Relicensing ........................................................................................................................... 78 Silent Relicensing .................................................................................................................................... 81 Next Steps ................................................................................................................................................ 81
Removal ............................................................................................................................................................ 83
6.1 6.2 6.3 Before You Remove ............................................................................................................................... 83 Interactive Removal ................................................................................................................................ 83 Silent Removal ......................................................................................................................................... 84
Patches .............................................................................................................................................................. 85
7.1 7.2 Installation ................................................................................................................................................ 85 Removal .................................................................................................................................................... 86
Table of Contents
Additional Information ................................................................................................................................ 87

8.1 8.2 8.3 8.4 8.5 Non-root Installation or Upgrade ........................................................................................................... 87 Silent Mode .............................................................................................................................................. 87 Licence Files for Alliance Access ......................................................................................................... 93 Checking Your System Configuration .................................................................................................. 93 The Software Integrity Report ............................................................................................................... 96
Part B Configuring for SWIFTNet ......................................................................................................97

9 10 Introduction ..................................................................................................................................................... 99 Check Connectivity .................................................................................................................................... 100
10.1 Configure SWIFT DNS Servers .......................................................................................................... 100 10.2 Confirm Connectivity ............................................................................................................................. 100
11
Defining Alliance Access in Alliance Gateway .............................................................................. 101

11.1 11.2 11.3 11.4 Guidelines for Names ........................................................................................................................... 101 FIN Messaging ....................................................................................................................................... 101 InterAct and FileAct Messaging .......................................................................................................... 103 Data Encryption/Gateway Authentication between Alliance Access and Alliance Gateway .................................................................................................................................................. 105
12
Configuring Alliance Access for FIN Messaging .......................................................................... 106

12.1 12.2 12.3 12.4 Defining a SWIFTNet Connection ...................................................................................................... 106 Assigning a SWIFTNet Connection to a Logical Terminal ............................................................. 107 Sending and Receiving a Test MT Message .................................................................................... 107 Access to the SWIFTNet FIN Test Service (Vendors only) ............................................................ 108
13
Configuring Alliance Access for InterAct and FileAct Messaging ....................................... 109
13.1 13.2 13.3 13.4 Defining a SWIFTNet Connection ...................................................................................................... 109 Installing Application Service Profiles ................................................................................................ 109 Configuring SWIFTNet Emission and Reception Profiles ............................................................... 110 Sending and Receiving an InterAct or a FileAct Message ............................................................. 110
Part C System Administration ...........................................................................................................113

14 Introduction to System Administration ............................................................................................. 115
14.1 Overview of the System Administration Application ........................................................................ 115 14.2 System Management Procedures ...................................................................................................... 119 14.3 The Alliance Release Tree .................................................................................................................. 120
15
General System Maintenance ................................................................................................................ 123

15.1 System Management Commands ...................................................................................................... 123 15.2 Essential System Maintenance ........................................................................................................... 125
16
Managing UNIX Accounts ....................................................................................................................... 128

16.1 Alliance Administrator Account ........................................................................................................... 128 16.2 Security Considerations ....................................................................................................................... 128 16.3 The alliance_init File ............................................................................................................................. 129
30 September 2011
16.4 Workstation IP Address Checking ...................................................................................................... 129 16.5 The Instance Registration File ............................................................................................................ 129
17
Managing the Alliance Access Servers ............................................................................................ 131

17.1 17.2 17.3 17.4 Starting the Alliance Access Servers ................................................................................................. 131 Stopping the Alliance Access Servers ............................................................................................... 134 Running Selected Program Scripts following Server Start and Stop ............................................ 138 Monitoring Processes ........................................................................................................................... 138
18
Query the Database for Message, Events, and Operator Details .......................................... 141
18.1 Query the Database to Extract Messages ........................................................................................ 141 18.2 Query the Database to Extract Events .............................................................................................. 142 18.3 Query the Database to Operator Details ........................................................................................... 142
19
Backing Up Data .......................................................................................................................................... 144

19.1 19.2 19.3 19.4 19.5 19.6 19.7 Database Backup .................................................................................................................................. 144 Archive Backup ...................................................................................................................................... 145 Temporary Storage Directory for Backup .......................................................................................... 145 Performing a Manual Backup of Archives ......................................................................................... 146 Performing a Manual Backup of the Database ................................................................................. 148 Scheduling Automatic Backups .......................................................................................................... 150 Following a Backup ............................................................................................................................... 150
20
Restoring Data .............................................................................................................................................. 151

20.1 Restoring an Archive Backup .............................................................................................................. 151 20.2 Restoring the Alliance Access Database .......................................................................................... 153
21
Managing Disk Space ................................................................................................................................ 158

21.1 21.2 21.3 21.4 21.5 Monitoring Available Disk Space ........................................................................................................ 158 Modifying Disk Space Parameters ..................................................................................................... 158 System Resources ................................................................................................................................ 159 How To Recover Disk Space .............................................................................................................. 159 Backing Up the Instance Registration File ........................................................................................ 159
22
Managing the Database ............................................................................................................................ 160

22.1 22.2 22.3 22.4 22.5 22.6 Getting Information about the Alliance Access Database .............................................................. 160 Checking the Alliance Access Database ........................................................................................... 160 Configuring the Embedded Database ................................................................................................ 161 Backing Up the Alliance Access Database ....................................................................................... 162 Moving the Database to a New Host ................................................................................................. 163 The saa_bankquery Tool ..................................................................................................................... 163
23
Database Recovery .................................................................................................................................... 165

23.1 23.2 23.3 23.4 23.5 About Database Recovery ................................................................................................................... 165 Database Configuration for Enhanced Resiliency ........................................................................... 167 Database Recovery Process ............................................................................................................... 169 Database Recovery Backups .............................................................................................................. 171 Repairing Messages ............................................................................................................................. 173
Table of Contents
23.6 The saa_dbrecovery Command ......................................................................................................... 175
24
Handling System Failures ....................................................................................................................... 181

24.1 24.2 24.3 24.4 Process Failure ...................................................................................................................................... 181 Power Failure ......................................................................................................................................... 182 Disk Failure ............................................................................................................................................ 182 Recovery on a Different Host Using a Cold Backup ........................................................................ 183
25
Replication of Configuration Data ....................................................................................................... 189

25.1 25.2 25.3 25.4 25.5 25.6 25.7 25.8 25.9 Configuration Replication ..................................................................................................................... 189 Handling the Export and Import of Sensitive Data ........................................................................... 191 Entities Eligible for Export and Import ................................................................................................ 192 Status of Entities Before and After Import ......................................................................................... 196 Parameter File for Configuration Replication .................................................................................... 198 Fields Eligible for Export and Filtering ............................................................................................... 202 Export Configuration Data ................................................................................................................... 212 Import Configuration Data .................................................................................................................... 213 Report File for Configuration Replication .......................................................................................... 215
26
Integration of Operational Data with Third-Party Applications .............................................. 217

26.1 26.2 26.3 26.4 Overview of Operational Integration ................................................................................................... 217 Permissions for Launching Operational Integration Tools .............................................................. 217 Operational Monitoring ......................................................................................................................... 218 Operational Management .................................................................................................................... 226
27
Using Command Line Tools ................................................................................................................... 230

27.1 27.2 27.3 27.4 27.5 27.6 27.7 saa_configconnection ........................................................................................................................... 230 saa_system ............................................................................................................................................ 231 saa_configbootstrap ............................................................................................................................. 237 saa_bootstrap ........................................................................................................................................ 239 Alliance CIFA Export ............................................................................................................................. 240 TCP/IP Service Files ............................................................................................................................. 241 The Reset Message Partners (reset_mp) Script .............................................................................. 241
28
TCP Configuration for the Alliance Access Server ..................................................................... 243

28.1 Port Configuration ................................................................................................................................. 243 28.2 apply_alliance_ports Tool .................................................................................................................... 244
29
General Troubleshooting ........................................................................................................................ 246

29.1 The Alliance Configuration Report ..................................................................................................... 246 29.2 The JOURNAL_query Facility ............................................................................................................. 248
Part D Appendices .......................................................................................................................................251

. ppendix A Setup Recommendations ...........................................................................................................253 A
A.1 A.2 Alliance Access for Service Bureaux ................................................................................................. 253 Alliance Access as Standalone Message Entry and Repair System ............................................ 255
. ppendix B Command Line Tool Syntax Reference ...............................................................................273 A

30 September 2011 5
B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8 B.9 B.10 B.11 B.12 B.13 B.14 B.15 B.16 B.17 B.18 B.19 B.20 B.21 B.22 B.23 B.24 B.25 B.26 B.27 B.28 B.29
checkhost ............................................................................................................................................... 273 getmesg .................................................................................................................................................. 274 launch MPA EXPORT_TEMPLATES ................................................................................................ 275 launch MPA unres_mesg ..................................................................................................................... 277 messageTool ......................................................................................................................................... 278 reset_mp ................................................................................................................................................. 278 saa_bankquery ...................................................................................................................................... 279 saa_bootstrap ........................................................................................................................................ 279 saa_configbootstrap ............................................................................................................................. 280 saa_configconnection ........................................................................................................................... 280 saa_dbconfig .......................................................................................................................................... 281 saa_dbinfo .............................................................................................................................................. 282 saa_dbpwdutil ........................................................................................................................................ 282 saa_dbrecovery ..................................................................................................................................... 283 saa_dbrestore ........................................................................................................................................ 285 saa_export .............................................................................................................................................. 287 saa_import .............................................................................................................................................. 288 saa_import_rmqa .................................................................................................................................. 289 saa_manage .......................................................................................................................................... 290 saa_manageasp .................................................................................................................................... 292 saa_monitor ........................................................................................................................................... 293 saa_msgrepair ....................................................................................................................................... 295 saa_query ............................................................................................................................................... 295 saa_rtfilegetrequest .............................................................................................................................. 299 saa_supportinfo ..................................................................................................................................... 301 saa_system ............................................................................................................................................ 303 sa_split .................................................................................................................................................... 306 swrpc_keytool ........................................................................................................................................ 307 systeminfo .............................................................................................................................................. 308
. egal Notices .............................................................................................................................................................310 L
Preface
Preface
Purpose This document describes how to install, configure, and administer Alliance Access on Solaris. The document includes an introduction to dual-configuration support and system administration. In general, the information provided in this guide is designed for users connecting to SWIFT and the FIN application. Where appropriate, information is also provided for users connecting to other networks. Audience This document is for anyone who installs Alliance Access. Knowledge of how to use Solaris is a prerequisite for the readers of this document.
30 September 2011
Part A - Installation
Part A
Installation
30 September 2011
10
Installation Features Overview
Installation Features Overview

Introduction This section describes the new installation-related features that are available for Alliance Access. Hosted database or embedded database In an embedded database environment, the product software uses the database supplied with the product. In a hosted database environment, you install Alliance Access within an existing database. For information about the configuration of hosted database environments, see "Prepare for a Hosted Database Installation" on page 24. Silent mode You can perform the installation, upgrade, patch, relicensing, and removal operations in silent mode. The main difference between interactive (GUI-based) operations and operations performed in silent mode is the way input data is provided. In a GUI-based procedure a user provides input through GUI-windows. An operation launched in silent mode does not require interactive user input, instead a response file and a licence file provide this input. The use of response files and licence files reduces the time required to perform and repeat the operation, especially if you have a large number of Alliance Access instances. Furthermore, the use of a response file allows for segregation of duties: operations managers can prepare the response files in advance, and the operation itself can be scripted or carried out by other people of the organisation. SWIFT provides templates of response files with default values, or alternatively, you can run an interactive installation to generate a response file and a licence file. For more information about using the silent mode, see "Silent Mode" on page 87. Options for software licensing Licence data can be provided either directly on screen, or from a file.
When during an interactive software installation, relicensing, or upgrade Where in the licensing windows How Enter licence data on screen. Provide licence data from a licence file. from a command line Provide licence data in a licence file.
during silent installation, relicensing, or upgrade
For more information about the licensing options, see "Relicensing" on page 77. Secure Channel Secure Channel improves the way Alliance software licence data is distributed. Previously, the Alliance Left Security Officer (LSO) and Right Security Officer (RSO) received the licence data for the Alliance products on paper. With Secure Channel, licence data is no longer distributed on paper by post. They can now be securely viewed online. To access Secure Channel, you must be registered on www.swift.com and have the appropriate access rights defined in your user profile. For more information, see Secure Channel on www.swift.com.
30 September 2011
11
Recording the installation The interactive installation features the option to record the input information provided during the installation into a response file. A command-line based silent installation procedure can use this response file to provide the same installation information in subsequent installations. This reduces the risk of human error from manual intervention. For more information about recording the installation, see "Response Files" on page 88. Recording the licence information The interactive installation features the option to record the licence information (except licence keys which are recorded in the response file) provided during the installation into a licence file. Use this file to provide the same licence information in subsequent licensing or relicensing tasks. For more information about recording the licence information, see "Response Files" on page 88. Performing actions as a non-root user It is possible to install, patch, remove, or upgrade the Alliance Access software with a non-root user account, such as, all_adm. The non-root user account becomes the Alliance administrator, and the owner of the instance. Before you can take an action (such as, installation) with a non-root user account, the root user must prepare the system for the action that the non-root user will perform. To complete the installation, the root user must perform some post-installation tasks. For more information, see "Non-root Installation or Upgrade" on page 87.
12
Preparation
2
2.1
Preparation
Getting Started
Release Letter A Release Letter for Alliance Access 7.0, provides essential information about the Alliance Access software that you are about to install or upgrade. For example, it provides additional checks, instructions, or tips that you need to know before you install, upgrade, or relicense the software. Installation media The Release Letter lists the channels through which the Alliance Access software is distributed. In this guide, "release media" refers to any media that provides the software, for example, a DVD, or a file downloaded from www.swift.com. The release media provides an installation program (called an installer) which allows you to install or upgrade Alliance Access easily. You can launch the installation program directly from a DVD or from a hard disk. You can install or upgrade Alliance Access from the following locations: DVD: local remote DVD drive, that is, a drive on a remote Solaris machine Directory on hard disk: local disk remote disk, that is, a disk on a remote Solaris machine To get started 1. 2. 3. Read the Alliance Access Release Letter, if you have not already done so. Determine which task you need to perform, and prepare for that task. See "Preparation checklist" on page 14. After you perform the generic preparation tasks, review the prerequisites and checklists in the sections, "Installation" on page 32 and "Upgrade " on page 59, and complete any additional preparation tasks described there. Perform the task required: "Installation" on page 32 "Upgrade " on page 59 "Relicensing" on page 77 "Removal" on page 83 "Patches" on page 85
4.
30 September 2011
13
5. 6.
Review the Post-Installation or Post-Upgrade sections in the Release Letter, as appropriate, and complete any additional tasks that are specified there. Complete the Next Steps in the relevant sections, which describe the configuration tasks that are required to make your system operational. Review also the Additional Configuration section in the Release Letter, and complete any additional tasks that are specified there.
Preparation checklist The columns in the table are not mutually exclusive. Therefore, you must perform the preparation tasks that are indicated in the relevant columns:
Install with embedded database Upgrade from prepared backup Launch operation as non-root
Install with hosted database
Upgrade - standard
Preparation Task Read the release Letter "Prepare the System" on page 15 "Create the Temporary Installation Directory" on page 19 "Prepare for Non-root Installation, Upgrade, Backup, or Removal" on page 20 "Create the sagsnlg and alliance Group" on page 21 "Prepare the Licence File" on page 21 "Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal)" on page 22 "Protect the Passwords in the Response File" on page 23 "Prepare for a Hosted Database Installation" on page 24 "Prepare a Backup File for Upgrade" on page 29
14
Use silent mode
Relicense
Remove
Patch
Preparation
Related information "Silent Mode" on page 87 "Non-root Installation or Upgrade" on page 87
2.2
Prepare the System

Introduction Review each of the topics in this section to identify the actions that you need to take to prepare your system for an installation or upgrade of Alliance Access. System requirements For details of the required operating systems and Service Pack levels, see the Release Letter. The installation program checks for the minimum requirements. Before installing Alliance Access, you can also use the checkhost tool to verify that the system meets the minimum requirements. This tool is provided on the release media. If any problems are detected, then you must resolve them before starting the installation. For instructions on how to use this tool, see "Checking Your System Configuration" on page 93.
2.2.1
Define the Alliance File System

It is important to consider carefully the size and location of the file system in which Alliance Access is installed, before you start the installation process. Otherwise, if changes have to be made later, then lengthy reorganisation of disk resources will be required.
Introduction
File system location and permissions The default directory that is proposed for the installation is /Alliance/Access. Important If you create or select a different directory during the installation, you must ensure that the user who runs the installation (by default, all_adm) has full read and write access to this directory. For more information about setting permissions on the installation directory, see "Prepare for Non-root Installation, Upgrade, Backup, or Removal" on page 20.
Alliance Access can be installed on a UNIX File System (UFS), if the minimum system requirements are met. This file system must have read-write permission. Your Solaris system administrator must decide exactly where to install Alliance Access. Disk space Before purchasing Alliance Access, SWIFT advised your organisation of the minimum amount of disk space required for the expected level of operations. This figure must be taken as a minimum requirement. The exact amount of space needed for operational data depends on the traffic processed, number of operators, the frequency with which archives are backed up and removed, and so on. Clearly, there are advantages in allocating as much space as possible to the file system in which Solaris is installed. For more information about disk space requirements, see the Release Letter. By default, the software and the database are installed on the same file system. To increase performance, the database can be split over several disks. In this case, the configuration of the database is done using dedicated tools (saa_dbinfo, saa_dbconfig), after installation.
30 September 2011 15
Mounting local file systems If the Alliance Access file system is mounted locally, then it is important that no "mount options" are used, particularly nosuid. If nosuid is used, then problems can occur when an Alliance Administrator logs on.
2.2.2
Requirements for the Host Name

The host name of the machine on which Alliance Access is installed must meet the following requirements: maximum of 31 characters can only contain the characters 'a-z', 'A-Z', '.', and '-', and the numbers 0 through 9 Otherwise, if you use an embedded database, then the database will not start.
Alliance Access host machine
Hosted database The host name of the machine where the hosted database will be installed on Oracle has the following requirements: maximum of 31 characters can only contain the characters 'a-z', 'A-Z', '.', and '-', and the numbers 0 through 9 Tip The characters are not case-sensitive.
2.2.3
Automatic Time Synchronisation

When automatic time synchronisation is performed, the time is checked periodically on a number of machines and compared with a reference time. This is generally done using the Network Time Protocol (NTP). When necessary, the system time is changed. On UNIX, NTP is not enabled by default. Therefore, if you want to use NTP on UNIX, make sure that the slewing mode is implemented. Automatic time synchronisation must be switched off while the Alliance Access servers are running because Alliance Access makes extensive use of date and time in its processing. A manual synchronisation can be done when the servers are stopped (for instance, using a post stop server script). Note Problems can occur due to timestamp conflicts in the Alliance Access database, when the system time is changed while the Alliance Access servers are running.
Overview
16
Preparation
Synchronisation modes Two synchronisation modes exist: stepping mode: for large time differences between the system time and the reference time, the system will step or jump to the correct time. This can be done forward or backward. If the Alliance Access servers are running during this time change, then a system freeze can occur. slewing mode: for small time differences between the system time and the reference time, the system will slew the time. The NTP daemon will increase or decrease the speed of the CPU to match the reference time. By doing so, there is no jump in the system's time; it always moves forward. The implementation of the slewing mode can be considered as acceptable as it does not deviate from the fact that time only goes forward. However, we have already experienced problems on systems where slewing mode was not working as expected due to incorrect functioning of the complete time server system. In those cases we did see in the logfiles that the time moved backwards resulting in Alliance Access restarts.
2.2.4
System Setup
Use this checklist to configure the basic hardware and operating system.
Introduction
System setup checklist

Action Install basic system hardware Install DVD drive Install Oracle Solaris with supported packages and components (see "Prerequisites for the Installation" on page 32) Configure disk partitions and paging space (see "Prerequisites for the Installation" on page 32) Define file systems and logical volumes Install and configure LANs and LAN connections For interactive operations: X-terminals and associated ports are configured and available Assign a <host name> Allocate TCP/IP addresses Solaris System Administrator Solaris System Administrator Solaris manuals Solaris manuals Responsible Hardware Vendor Hardware Vendor Solaris System Administrator Documentation Oracle Solaris manuals Oracle Solaris manuals Solaris manuals Alliance Access Release Letter Solaris manuals
Solaris System Administrator
Solaris System Administrator Solaris System Administrator Solaris System Administrator
Solaris manuals Solaris manuals Solaris manuals
2.2.5
Required Information
Perform the basic setup of the system, as listed in "System Setup" on page 17. Then, use this checklist to ensure that you have all the required information at your disposal before installing or upgrading Alliance Access.
Purpose
30 September 2011
17
Checklist Check the following items:

Required information Release Letter Licensing details (as notified by SWIFT to Security Officers) Part 1 of the Initialisation Password Part 2 of the Initialisation Password Details of the required software installation directory For interactive operations: Identity of the display terminal used for installation Identity of your DVD drive Solaris System Administrator Solaris manuals Responsible Solaris System Administrator Security officers Left security officer Right security officer Solaris System Administrator Solaris System Administrator Reference Release media SWIFT licensing agreement SWIFT licensing agreement SWIFT licensing agreement Solaris manuals
2.2.6
Software Installation and Licensing

Use this checklist when installing and licensing Alliance Access on your system and for your destinations.
Checklist
Software installation and licensing checklist

Action Log on to the "root" or Alliance Administrator account Start installation process from DVD or directory Perform licensing procedures Follow system configuration dialogues and check for errors Wait for files to be copied Check for successful completion Log out of the "root" or Alliance Administrator account Store release DVD in a safe place Responsible Alliance Administrator Alliance Administrator Alliance Administrator and Security Officers Alliance Administrator Alliance Administrator Alliance Administrator Alliance Administrator Alliance Administrator Documentation Solaris manuals "Installation" on page 32
18
Preparation
2.3
Tracking What Happens During Installation

Overview The installation process consists of various steps. Some steps are automatic whereas others require that you enter particular values or make choices from a range of options. In general, if you complete a particular step successfully, the next window appears automatically. Having installed Alliance Access software, and performed any additional hardware-related configuration activities, initial configuration activities must also be performed within Alliance Access, as described in "Post-Installation Checklist" on page 47. Following the installation, additional configuration activities may have to be performed, depending on the Alliance options used by your installation. When Alliance Access software is installed and fully operational, your Alliance Access administrator can reconfigure parts of your system and perform various administrative tasks to maintain your system daily (for example, back up and restore the Alliance Access database). Installation log The steps that are completed successfully are recorded in the installation.log. In addition, the events that occur during the installation are recorded in the installation.log, and in the installation_systemcheck_yymmdd_hhmmss.html file. These files are found in the Alliance Access installation directory, or else, in the temporary installation directory. For more information about the temporary directory, see "Create the Temporary Installation Directory" on page 19. The log is stored in the temporary directory until you successfully provide the path and name of the installation directory during the installation. After you provide the installation directory successfully, then the log is stored there. If an error occurs during installation If a problem occurs during the installation process, then an error message appears, describing the nature of the error, as well as giving the full text of the actual error message reported by your system. If the nature of the error is serious (for example, there is a problem with your release media), then you are prompted to abort the installation. Generally, you must not attempt to continue the installation if a problem occurs. However, if an error is easily resolved (for example, you entered the licensing details incorrectly), then you are asked to repeat the last action. Once corrected, the installation proceeds normally. In all cases, make a note of the error message before you stop and restart the installation procedure. If in doubt, then contact your System Administrator for advice. If a problem cannot be resolved, then contact Support for further assistance.
2.4
Create the Temporary Installation Directory

Description You must ensure that a temporary directory is available before launching product installation or upgrade, or patch installation. This is so that information relating to the installation/upgrade can be logged somewhere before the actual installation directory is known by the system.
30 September 2011
19
This temporary directory is specified in either of the following ways: When launching the installation or upgrade command, by appending the -tempdir option to the command, followed by a directory path (for example, ./saa-install -tempdir <directory path>). Define a directory path in the "TMPDIR" environment variable. Let UNIX use the /var/tmp or /tmp default temporary directory.
2.5
Prepare for Non-root Installation, Upgrade, Backup, or Removal

Introduction The user that installs the Alliance Access software becomes the owner of the Alliance Access instance. To prepare for a backup, installation, upgrade, or removal operation of Alliance Access with an account that does not have root privileges, the UNIX root account must perform specific tasks before and after the operation. The non-root user account must be the same operating system account that owns the SWIFTNet Link instance. You can ignore this section if you intend to perform these actions with the root user account. Preparation tasks To prepare for a non-root user to install, back up, upgrade, or remove Alliance Access, do the following: 1. 2. 3. Log on with the root user account. Create the sagsnlg and alliance groups. Add the non-root user account to the sagsnlg and alliance groups, if not already done. For more information, see "Create the sagsnlg and alliance Group" on page 21. This non-root user will become the owner of the installation. 4. If you are installing, then create the installation directory with the correct ownership and protections (750). The default directory path is: /Alliance/Access Important The user account that will run the installation must have full access to this directory for example, all_adm.
5.
If you are upgrading Alliance Access or Alliance RMA from release 6.3, then change the permissions of the central registry location. Type:
/usr/bin/chmod 644 /var/opt/swift/*.swift
Before you upgrade 6.3 to 7.0 on a UNIX cluster with a non-root user, ensure that the version file (/saa.<date>. swift for Access, /sar.<date>. swift for RMA) in /var/opt/swift/ is readable for the non-root user. 6. a. Create a directory named root under your installation directory (either created in step 4 or, for an upgrade, the directory created during the previous installation) with sufficient permissions (700). The root directory must be owned by the SWIFTNet Link owner.
20
Preparation
b. Grant access to the root directory to the owner of the installation. Type:
/usr/bin/chown <alliance access owner account>:sagsnlg <install_dir>/ root
c. Copy the oradism executable from the Alliance Access DVD to the root directory that you created. The oradism executable is located in the same directory as the software installer. Oracle uses the oradism tool to lock and unlock shared memory. d. Change the ownership of the oradism executable to root:sagsnlg. Type:
/usr/bin/chown root:sagsnlg <install_dir>/root/oradism
where <install_dir> must be replaced with the path to the installation directory. Important The user account that will run the installation must have read access to this directory (for example, all_adm).
e. Change the permissions of the oradism executable. Type:

/usr/bin/chmod 4755 <install_dir>/root/oradism
where <install_dir> must be replaced with the path to the installation directory.
2.6
Create the sagsnlg and alliance Group

Introduction Before installing Alliance Access, create the sagsnlg and alliance groups by completing the steps in the following procedure. Procedure 1. Edit the /etc/group file to find out a group ID that is not yet in use. Each line of the /etc/ group file looks like:
sagsnlg::<group_ID>: alliance::<group_ID>:
2. 3.
Select two free group IDs depending on your company policy. The group ID is the value in the third column. Create the groups sagsnlg with the selected group IDs by executing the commands:
groupadd -g <group_ID> sagsnlg groupadd -g <group_ID> alliance
2.7
Prepare the Licence File

Applicability This procedure explains how to prepare the licence file. Once prepared, the file can be used as an alternative to entering the data interactively. This procedure is not applicable if the licence file has been downloaded from Secure Channel. For more information about Secure Channel, see "Secure Channel" on page 11.
30 September 2011
21
Procedure 1. 2. 3. Insert the Alliance Access product DVD. On the DVD, in the folder for Alliance Access, navigate to the SunOS/installer directory. Copy the silent.properties.lic.saa file from the Alliance Access product DVD to a directory of your choice. Note The directory you choose must also contain the appropriate response file (before launching the installation or upgrade).
4. 5.
Edit the file to incorporate the information obtained in your licensing agreement. Save the file, using the same file name as the response file followed by extension .lic. If you intend to perform a non-root installation or upgrade, then save the file so that it can be read by the user account that performs the non-root installation or upgrade.
2.8
Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal)
Purpose A response file provides all the user input required to complete a procedure in silent mode. You can prepare the response file in either of the following ways: Record the input provided to a GUI-based procedure, using the -record option. For more information, see "Record input parameters" on page 88. Modify the sample response file provided on the Alliance Access product DVD, as described in this section. Modify a previously created response file. Modify the response file provided on DVD 1. 2. 3. Insert the Alliance Access product DVD. On the DVD, in the folder for Alliance Access, navigate to the SunOS/installer directory. Copy the appropriate response file from the Alliance Access product DVD to a directory of your choice: silent.properties.install.saa.embedded, if you are installing the supplied database silent.properties.install.saa.hosted, if you are installing into your own database silent.properties.relicensing, if you are relicensing silent.properties.uninstall, if you are removing Alliance Access. Note The directory you choose must also contain the appropriate licence file (before launching the installation or upgrade).
22
Preparation
4.
Edit the file to incorporate the required information. The file contains information about which parameters are required. For more information, see "Response File Parameters" on page 89.
5.
Obfuscate or encrypt the system, Left and Right initialisation passwords or any other data by using the obfuscation tool provided on the Alliance Access product DVD. For more information, see "Protect the Passwords in the Response File" on page 23.
6.
Save the file. If you intend to perform a non-root installation or upgrade, then save the file so that it can be read by the user account that performs the non-root installation or upgrade.
2.9
Protect the Passwords in the Response File

Principle Silent installation or upgrade operations require that the system account password and Left and Right Initialisation passwords are present in the response file. In the response file, the passwords or any other data can be specified in clear text, obfuscated, or encrypted (which is the recommended option). A tool is provided on the Alliance Access product DVD to obfuscate or encrypt passwords or any other data. Run the obfuscation tool 1. 2. On the Alliance Access product DVD, navigate to the SunOS/installer directory. Run the obfuscator tool, which creates a digest that hides the password. To encrypyt a password with a key that you provide, run the obfuscator tool with the -key option. If you use the -key option, you will be prompted to enter the key to be used. The same key must be provided later to run the installation routine. The key to be used must meet certain criteria: The length of the key must be in the range of 8 - 20 characters. The key must contain at least one uppercase character, one lowercase character, and one numeral. The number of occurrences of the same character must not exceed half the length of the key. 3. You are prompted to enter the data (password) to be obfuscated or encrypted. The result is displayed. The digest value starts with ----. 4. Copy the resultant data displayed to the appropriate parameter in your response file.
30 September 2011
23
2.10
Prepare for a Hosted Database Installation

With release 7.0, Alliance Access introduces a new installation model where the Alliance Access database schema is created in an existing Oracle instance instead of in an Oracle instance created by the Alliance Access installer. Note You can only use the hosted database option when installing Alliance Access. You cannot upgrade an existing version of Alliance Access to use this option.
Introduction
Before launching this type of Alliance Access installation, the database administrator (DBA) on the customer Oracle instance must check that the prerequisites have been met. This section provides the detail of these database prerequisites. In this section, the default tablespace names (SAA_DATA, ...) and user names (SAAOWNER, ...) are used. However, these are configurable during the installation.
2.10.1 Important Information

In the context of an Alliance Access database installed in an Oracle instance provided by the customer, it is assumed that the customer is responsible for the management of the database. The following actions fall under the customer's responsibility: During the installation of Alliance Access, two database directory objects (SAA_ARCH_BACKUP_DIR and SAA_DB_BACKUP_DIR) are created. These objects are required for the generation and restoration of Alliance Access backups of configuration data and of archives. If several Alliance Access databases are installed on the same Oracle instance, then these database directory objects must be different per Alliance Access database. Changing the names of these objects is possible through the Alliance Access configuration screens. Creating other objects (such as tables or indexes) in the Alliance Access database schema(s) should not be done. These objects may be deleted by Alliance Access (during installation or at run time), or they may prevent the Alliance Access software from working properly. Installing multiple Alliance Access instances using the same Oracle instance requires that tablespaces, users and directory objects are different between the different Alliance Access instances. Monitoring the disk space usage of the tablespaces is performed regularly to avoid a crash of Alliance Access because of unavailable disk space. Oracle and its storage infrastructure are configured for protection against media failures, for example, by disk mirroring and/or RMAN backups and/or Data Guard. Before starting the Alliance Access servers, the Oracle instance and listener must be started. This is also required for certain off-line Alliance Access tools, for example saa_system dbbackup. Before stopping the Oracle instance and the listener, the Alliance Access servers must be stopped. Network connectivity between the Alliance Access host and the Oracle host is reliable.
24
Preparation
After removing Alliance Access, the tablespaces, schemas, and directories listed in this document can be removed from the Oracle instance. The Alliance Access backup/restore functionality comprises the backup of archives of messages and events, and backup of Alliance Access configuration data. This functionality requires a shared file system that is readable and writable from the Oracle system and the Alliance Access system with their owner credentials (for example, an NFS mount). The shared directory can be set using Alliance Access configuration screens. For the Oracle system, the following mount options are required:
rw,bg,hard,rsize=32768,wsize=32768,vers=3,[forcedirectio or llock],nointr,proto=tcp,suid
There are no specific mount option requirements for the Alliance Access system. User accounts, group memberships, and permissions must be configured to enable the following: for the backup, Alliance Access creates the backup directory. Oracle writes one or more datapump files and a log file. Alliance Access reads the datapump file(s) and writes an information file. for the restore, Alliance Access reads the information file and the datapump files from the backup directory. Oracle reads one or more datapump files, and writes a log file.
2.10.2 Prerequisites For a Hosted Database

System requirements You must have licence option 13:HOSTED DATABASE. The software version of the Oracle instance wherein the Alliance Access database will be created must meet the following Oracle version requirements: Type of Oracle: Standard/Enterprise Version of Oracle: see the Release Letter The following Oracle configuration parameters must be set as follows: processes = 250 sessions = 500 sga_target = 1200M pga_aggregate_target = 300M database character set = US7ASCII Depending on the Oracle version, the sga_target and pga_aggregate_target values can also be set through the memory_target parameter, by setting: memory_target = 1500M.
30 September 2011
25
2.10.3 Database User Accounts

Accounts required Before launching the Alliance Access software installer to install Alliance Access within an Oracle instance provided by the customer, the customer must have performed the following prerequisites: The following three Oracle database users (and their associated passwords) are created and available for use. These are logical names that will be mapped to physical names at installation time: SAAOWNER A database schema owner user: this Oracle user will be used to create the database schema (tables, views, indexes, stored procedures, functions, scheduled jobs, ...) of Alliance Access. SAATEMP A database temporary schema owner user: this Oracle user will be used to manage temporary data when required by Alliance Access (for example, during restore of message backups). SAAUSER A database run time user: this Oracle user will be used by Alliance Access to connect to the installed Alliance Access database whenever Alliance Access requires access to the database. Note Each of these users must also be granted the necessary privileges.
Attribute Account status Value and Comment Once the installation of Alliance Access is successful, the account status can be set to LOCKed (this is optional). The SAAOWNER must be identified by a password when connecting to the Alliance Access database. This setting is mandatory. SAA_DATA is the default tablespace where SAAOWNER will create database objects. This setting is optional. Must have the same attributes as SAAOWNER. Account status Authentication method UNLOCKed. The SAAUSER must be identified by a password when connecting to the Alliance Access database. This setting is mandatory.
User Account SAAOWNER
Authentication method
Default tablespace
SAATEMP SAAUSER
26
Preparation
User Account
Attribute Default tablespace
Value and Comment SAA_DATA is the default tablespace where SAAUSER will create database objects. This setting is optional.
2.10.4 Tablespaces
Tablespaces required The necessary tablespaces and associated datafiles must be created. These are: SAA_DATA: contains the Alliance Access configuration data. SAA_FILE: contains the payloads associated to FileAct messages. SAA_TEMP: contains temporary data (for example, the restored 6.x archives for which CRC is to be re-calculated before import in the SAA_MESG). SAA_MESG: contains the messages managed by Alliance Access. SAA_JRNL: contains the Alliance Access events.
2.10.5 System and Object Privileges

The three database user accounts required by Alliance Access must have database system and object privileges as described in the following tables. SAAOWNER and SAATEMP system privileges
System privilege CREATE ANY DIRECTORY CREATE JOB CREATE PROCEDURE CREATE SEQUENCE CREATE SESSION CREATE SYNONYM CREATE TABLE Comment Used to create directories during backup and restore of data. Used to create jobs during the Alliance Access database configuration. Used to create stored procedures, functions and packages during the Alliance Access database configuration. Used to create sequences during the Alliance Access database configuration. Used to connect to Oracle during the Alliance Access database configuration. Used for synonym creation. Used to create tables during the Alliance Access database configuration. Also used at run time by stored procedures to create daily tables, search tables. Used to create triggers during the Alliance Access database configuration. Also used at run time by stored procedures to create triggers for daily tables. Usage scope Run time. Installation or patch. Installation or patch. Installation or patch. Installation or patch. Installation or patch. Installation or patch. Run time. Installation or patch. Run time.
CREATE TRIGGER
30 September 2011
27
System privilege CREATE VIEW UNLIMITED TABLESPACE
Comment Used to create views during the Alliance Access database configuration. Used for backup and restore operations.
Usage scope Installation or patch. Run time.
SAAOWNER and SAATEMP object privileges

Object privilege EXECUTE on DBMS_LOB EXECUTE on DBMS_LOCK EXECUTE on DBMS_FLASHBACK SELECT on DBA_LOBS SELECT on DBA_SEGMENTS SELECT on DBA_FREE_SPACE SELECT on DBA_DATA_FILES SELECT on DBA_TABLESPACE S SELECT on DBA_INDEXES SELECT on V_ $DATABASE SELECT on DBA_DATAPUMP_J OBS Comment Perform certain operations on LOBs. Used for concurrency control of certain database objects. Used during backup. Used for table and tablespace size calculations during the backup/restore operations. Used for table and tablespace size calculations during the backup/restore operations. Used for table and tablespace size calculations during the backup/restore operations. Used for table and tablespace size calculations during the backup/restore operations. Used for table and tablespace size calculations during the backup/restore operations. Used for table and tablespace size calculations during the backup/restore operations. Used to determine OS in stored procedures. Used for backup and restore operations. Usage scope Run time. Run time. Run time. Run time. Run time. Run time. Run time. Run time.
Run time. Run time. Run time.
SAAUSER system privileges

Object privilege ALTER SESSION CREATE SESSION CREATE SYNONYM CREATE ANY DIRECTORY Comment Used to set session tracing, current_schema. Used to connect to Oracle. Used for synonym creation. Used to create directories during backup and restore of data. Usage scope Run time. Run time. Installation or patch. Run time.
28
Preparation
2.11
Prepare a Backup File for Upgrade

You can use backed up configuration data from a compatible earlier release of Alliance Access or Alliance RMA for subsequent use on an Alliance Access 7.0 host machine. This feature can only be used between two systems of the same operating system (only from Oracle Solaris to Oracle Solaris). Note The backup file does not include: the usrdata directory and content therein. The data contained in this directory is still available on the host where the backup was generated, even if the Alliance Access software is uninstalled. The data can safely be copied manually to the new host. operational data (messages, events, audit cards).
Introduction
Compliance Report file A report file, check_db.info, is generated during the preparation of the backup file and stored in the $ALLIANCE/mig directory. This report can be looked at to identify any pre-requisites related to routing rules, routing keywords or message partners that would not be met. This means that even if the preparation task is not performed, you can find out what needs to be updated or removed in advance. Compatibility Regardless of installed patches, the backup files of the following releases of Alliance Access are compatible with Alliance Access 7.0: Alliance Access 6.0 Alliance Access 6.3 You can also upgrade to Alliance Access 7.0 from the following releases of Alliance RMA: Alliance RMA 6.0 Alliance RMA 6.3
2.11.1 Before You Create a Backup File for Upgrade

Overview Before you create a backup file to prepare for an installation from backup, ensure that you perform the following actions: 1. 2. 3. From the SWIFT Interface application, Quit and Logout all logical terminals and switch them all to Manual mode. For details, see the Daily Operations Guide. From the SWIFT Support application, ensure that all logical terminals in use are assigned the latest Message Syntax Table. For details, see the System Management Guide. From the Application Interface application, select all the message partners and disable them.
29
30 September 2011
4.
Export RMA authorisations. For details, see "Exporting Authorisations Manually" in the Relationship Management Application User Guide. Note During the upgrade, RMA authorisations are automatically migrated to the new release. This step is only to provide you with a backup in case of problems with RMA migration during the upgrade process.
5.
Ensure that all message templates have the latest message syntax table assigned and export them all. For details, see "Exporting Templates" in the Daily Operations Guide. Note During the upgrade, templates are automatically migrated to the new release. This step is only to provide you with a backup in case of problems with template migration during the upgrade. If, after the upgrade, message templates cannot be opened or modified because they are assigned to an earlier message syntax table, then you can export the message templates and assign the latest message syntax table to them during the import.
6.
Follow the instructions about preparing for upgrade in the Release Letter.
2.11.2 Create a Backup File for Upgrade

Prerequisites 1. Ensure that Alliance Access or Alliance RMA is not running. 2. Verify that the server for which a backup will be taken is not running, and that the System Administration window is not open. 3. If you are running Alliance Access 6.3.x or Alliance RMA 6.3.x, and database recovery is activated, then deactivate it before starting the upgrade. For more information, see "Deactivate the Database Recovery Mode" on page 177. Procedure 1. 2. 3. 4. Log on with sufficient privileges. Stop Alliance Access or Alliance RMA on the host machine. Insert the Alliance Access product DVD. Prepare your system: a. Open a Korn shell. b. Mount the DVD. c. If you are working remotely, then export the display to your local machine:
export DISPLAY=<IPaddressComputer>:0.0
where <IPaddressComputer> must be replaced by the IP address for the computer where the installation windows will be displayed. 5. Navigate to the folder that contains the Alliance Access installation program. SunOS/installer 6.
30
Double-click the saa-install file.

Preparation
7.
The installation program inspects your system and the Welcome to the Alliance Access Installer window appears. This window might appear in the background, so you may have to close or minimise other windows to find it. If the installation program detects a compatible previous release of Alliance Access or Alliance RMA on your host system, then the Prepare Backup File for Upgrade option is the only one available.
8.
Click
Next
The Backup File Location window appears. 9. If you do not agree with the proposed location where the backup file must be created, then either type the full physical path or click Browse to provide the location. You cannot provide a symbolic link as a valid path. If the directory specified already contains a backup file, then a warning message appears asking you to provide a suitable directory. 10. Click
Next
A message appears that prompts you to close any open Alliance applications (for example, the Alliance Command Prompt) before you proceed with the backup. Click 11. Click
OK Next
in the Warning box when all Alliance applications are closed. to start the backup.
A message appears to remind you that messages, events, and audit cards will remain present in the database, and that the backup file does not include these. Completed messages, events, and audit cards must be archived and backed up before they can be restored to the other system. Click 12. Click
OK
to continue. to complete the backup operation.
Finish
The following files are created as a result:

File created backup file Details A file named SAA6<x>to7.zip (for Access) or SAR6<x>to7.zip (for RMA) where <x> is replaced with 0 or 3, as corresponds to the release that was backed up. Contains details about the backup procedure. This file is present in the installation directory of Alliance Access or Alliance RMA.
installation.log
30 September 2011
31
Installation
Overview This section describes how to install Alliance Access 7.0.
3.1
3.1.1
Before You Install

Prerequisites for the Installation
Before installing Alliance Access, ensure that: the Sun server hardware has been installed and tested. your system has been prepared according to the instructions in the section "Preparation" on page 13. for an interactive installation: both Alliance Access Security Officers (or their deputies) are present X-terminals have been installed and tested for a silent installation, you have prepared the following files: a licence file. See "Prepare the Licence File" on page 21. a response file. See "Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal)" on page 22. the Alliance Access Administrator account has been created on the system. Additional information Before you begin the installation, you also need the following: access to the root or Alliance Access Administrator account of your system (this may require the presence of your local Solaris system administrator, or the issuing of a temporary password for the root account). details of the directories in which you want to store the Alliance Release Tree (that is, Software). If, during installation, problems occur and you cannot solve them easily, abort the installation and perform the following: Remove the product DVD and store it in a safe place. Log off. Seek advice about the problem. Restart the complete installation process.
Checklist
32
Installation
3.1.2
Mounting the DVD Drive

Insert the Alliance Access product DVD.
Procedure
3.2
3.2.1
Interactive Installation
Launching the Interactive Installation From DVD
Before starting an installation, ensure that the machine is reserved for your use for the duration of the installation. To launch the installation program: 1. Log on as root (or Alliance Access owner account). Note: it is assumed that the root (or Alliance Access owner account) account will use the Korn shell. See the entry for root (or Alliance Access owner account) in the /etc/passwd file. The entry should end with the following shell invocation:
..:/bin/ksh
Overview
2.
If you are working remotely, then export the display to your local machine by typing:
where <IPaddressComputer> must be replaced by the IP address for the computer where the installation windows will be displayed. 3. Ensure that the SunOS directory where the Alliance Access software will be installed has been created by the Solaris system administrator. Ask your system administrator for the name of this directory. During the installation, you are prompted to supply this directory as part of the release tree path name. If the disk space requirements for the temporary files for the install program cannot be satisfied, then you can use the installer option -tempdir <TMPDIR> to specify an alternate temporary directory. If you are using the standard /tmp directory, then remove all sh* files from the directory by typing:
rm /tmp/sh*
4.
5.
6.
Check that the volume manager vold is running by typing:

ps -eaf | grep vold
If vold is running, then a line similar to the following appears:

root 342 1 80 Oct 16 ? 0:01 /usr/sbin/vold
If it does not appear, then start the volume manager by typing:

/etc/init.d/volmgt start
7. 8.
Insert the Alliance Access release DVD. Navigate to the following directory in the folder for Alliance Access: /SunOS/installer
30 September 2011
33
9.
Start the installation process by typing:

./saa-install
To record the installation details for future use, run the saa-install command with the record option. See "Record input parameters" on page 88 for more information. 10. To proceed with the installation, follow the steps in "Install Alliance Access Interactively" on page 35. During installation, you specify the UNIX account name used by the Alliance administrator for this installed instance of Alliance Access. Throughout the installation, the install program periodically accesses the install drive to copy, install, and license the various components of Alliance Access. It is therefore important that you leave the Alliance Access release DVD in its respective drive until the installation is complete. To launch the program from a remote DVD drive 1. 2. 3. 4. 5. Mount the DVD on the remote system. Share/export this file system on the remote machine as an NFS resource. Mount this file system on the local machine Access the DVD from the local machine using the local name. Navigate to the following directory in the folder for Alliance Access: /SunOS/installer 6. Type the command:
./saa-install
To record the installation details for future use, run the saa-install command with the record option. See "Record input parameters" on page 88 for more information.
3.2.2
Launching the Interactive Installation From a Directory

The following procedure describes how to start the installation from a directory.
Introduction
To launch the installation program: 1. If the disk space requirements for the temporary files for the install program cannot be satisfied, then you can use the installer option -tempdir <TMPDIR> to specify an alternate temporary directory. Check that the volume manager vold is running, by typing:
ps -eaf | grep vold
2.

If this line does not appear, then start the volume manager by typing:
3.
Insert the Alliance Access release DVD.
34
Installation
4.
Copy the DVD contents to an install directory on hard disk by typing:

mkdir <install directory> cd <install directory> cp -r /cdrom/<mount point>/* .
5.
Navigate to the following directory in the created install directory: /SunOS/installer
6.
Type the following command: ./saa-install To record the installation details for future use, run the saa-install command with the record option. See "Record input parameters" on page 88 for more information.
7.
To proceed with an interactive installation, follow the steps in "Install Alliance Access Interactively" on page 35.
During installation, you specify the UNIX account name used by the Alliance administrator for this installed instance of Alliance Access. Throughout the installation, the install program periodically accesses the install directory to copy, install, and license the various components of Alliance Access. To launch the installation program a remote directory: 1. 2. 3. 4. Copy the DVD contents to a directory on the remote machine. Share/export this file system on the remote machine as an NFS resource. Mount the directory on the local machine. Access the directory from the local machine using the local name <mount_point> . For example:
cd /<mountpoint>/SunOS/installer
5.
Type the following command: ./saa-install To record the installation details for future use, run the saa-install command with the record option. See "Record input parameters" on page 88 for more information.
3.2.3
Install Alliance Access Interactively

Events that occur during installation are recorded in the installation.log file, found in the Alliance Access installation path or in the default temp directory if the installation directory has not yet been entered. In case of installation failure, please check this file for the reasons of the failure.
Installation event log
30 September 2011
35
To install Alliance Access interactively: 1. When the installation program starts, it unpacks the files required. Once all the files are unpacked, the Welcome window is displayed:
Note 2.
The options available vary according to your current installation (if any).
Select Install Alliance Access 7.0, and continue with step 3. If you are installing from a backup file, then select Install Alliance Access 7.0 from Prepared Backup File. For more information, see "Prepare a Backup File for Upgrade" on page 29.
3.
Click
Next
The End-user Licence window appears. 4. Accept the terms, and click
Next
If you are installing from a backup file, then the Backup File Location window appears. Browse for the location of your backup file. If you are installing for the first time, then the Installation Location window appears.
36
Installation
5.
Specify the directory name and path, in which to install Alliance Access. You can either accept the default path, or click
Browse
to select another path.
If you select another path, then note the following conventions: Do not use spaces in the path name. Do not specify a symbolic link. You must type the full physical path. Use a directory that is dedicated to this product. Warning Do not create a new directory using the
Browse
> new-directory option.
To create new directory at this point, type the path and name of the new directory in Directory Name field. For more information about setting permissions on the installation directory, see "Prepare for Non-root Installation, Upgrade, Backup, or Removal" on page 20. 6. In the Owner field, specify the user that will own the installation files. The owner cannot be root because the installed files are restricted to owner account. 7. In the Database field, select whether you want to install Alliance Access with the Oracle database provided (Embedded) or on your own Oracle database (Hosted). If you select Hosted, the following fields must be completed: Host Enter the host name or IP address of the machine where the Oracle instance to be used is installed. For more information about the host name requirements, see "Requirements for the Host Name " on page 16. Port Enter the port number to be used by Alliance Access to connect to the Oracle instance. Service Enter the service ID identifying the Oracle instance.
Tip 8. 9. Click
Next
If the database is Embedded the hostname must meet the same criteria. .
The checkhost command is run to validate whether your system meets the minimum operating system requirements. The test results are saved in the software installation directory, in the file: installation_systemcheck_yymmdd_hhmmss.html where yymmdd and hhmmss are the date and time of the installation. If your system meets all the requirements, then the Packages Configuration window appears.
This window is used to license the packages and features that your institution has purchased from SWIFT. The pre-selected packages are part of the base licence and cannot be deselected. Note If your system does not meet all the requirements, then the System Configuration Test Results window displays information about the problems that were detected. The Result column specifies the severity of a reported problem: Problems reported as Warning do not prevent you from continuing the installation, but you may encounter unexpected results. Problems reported as Blocking prevent you from continuing the installation. Fix the problem and start the installation again. 10. Decide how you want to provide licence-related data. Manually: proceed to step 11. From a licence file: click Load from File and browse to the location of the licence file. Then click Next and proceed to step 16.
38 Installation and Administration Guide
Installation
11. Select the licensed components, using the items listed in the Packages section of your licensing agreement. Then click Next . Note You may want to license additional component packages or 'disable' selected component packages after the installation is finished. To do this, you can relicense Alliance Access using a new licensing agreement. You do not have to reinstall. For more information, see "Relicensing" on page 77.
12. The Servers Configuration window appears.
13. Select the licensed components, using the items listed in the Servers section of your licensing agreement. Then click Next . The Licensed Destinations Configuration window appears. 14. In this window, type: the 8-character live destination(s) listed in the Licensed Destinations section of your licensing agreement. the 8-character training destinations. The eighth character is a 0 (zero), to denote test and training. Although the test and training destination does not appear on your licensing agreement, you must enter it if you want to use it. Each destination must be on a separate line. Once you have typed all your destinations, click Next . The Message Types Configuration window appears. 15. In this window, type the message types listed in the Message Types section of your licensing agreement. Each message type must be on a separate line. Once you have typed all your message types, click Next . The Initialisation Password Configuration window appears.
30 September 2011
39
16. Enter the initialisation passwords as follows: The Security Officer who received the INITIALISATION PASSWORD provided in Part 1 of 2 of the licensing agreement must type this password in the First initialisation password field. The Security Officer who received the INITIALISATION PASSWORD provided in Part 2 of 2 of the licensing agreement must type this password in the Second initialisation password field. Note Do not confuse the Initialisation Passwords with the Master Passwords. The Master Passwords are used by the two Security Officers when they first sign on to Alliance Access.
Next
17. Click
.
OK
If the password verification fails, then an error message appears. Click correct input.
and enter the
40
Installation
18. The Instance Configuration window appears.
Field Host Name
Description The host name of the Alliance Access system. For more information about the host name requirements, see "Requirements for the Host Name " on page 16. The IP address of the Alliance Access system. The name of the Alliance Access instance on the Alliance Access system. The instance name can be up to 15 alphanumerical characters, and must start with an alphabetical character. It can contain the "_" character. If several instances are installed, each one must have a unique instance name. A description of the instance. It can contain alphanumeric characters and spaces, and must not exceed 30 characters.
IP Address Instance Name
Instance Comment
19. If necessary, change the default values in the IP Address, Instance Name, and Instance Comment fields. 20. Click
Next
If you have selected the embedded database option, the Installation Summary window appears. Go to step 24. If you have selected the hosted database option, the Database User Names and Passwords window appears. Go to step 21. 21. Enter the names and passwords of the Oracle database users required (as set up during the preparation phase as described in "Database User Accounts" on page 26). Schema Owner and password: this is the user that will be used by the Alliance Access software installer to create and configure the Alliance Access database schema. User Name and password: this is the user that will be used by Alliance Access to connect to the installed Alliance Access database.
Temp Schema Owner and password: this is the user that will be used by the Alliance Access software when temporary data are to be managed (for example during restore of backups). Click Note
Next
. These user names and passwords cannot exceed 30 characters and must comply with the Oracle user name and password specifications.
22. Enter the names of the tablespaces that Alliance Access should use (as set up during the preparation phase as described in "Tablespaces" on page 27). In the Data Tablespace field, enter the name of the tablespace containing the Alliance Access configuration data (SAA_DATA). In the File Tablespace field, enter the name of the tablespace containing the Alliance Access FileAct payloads (SAA_FILE). In the Event Tablespace field, enter the name of the tablespace containing the Alliance Access events (SAA_JRNL). In the Message Tablespace field, enter the name of the tablespace containing the Alliance Access messages (SAA_MESG). In the Temporary Tablespace field, enter the name of the tablespace used by Alliance Access when required to manage temporary data (SAA_TEMP). 23. Click
Next
The Installation Summary window appears. 24. Check that the details displayed are correct, and if so, click Install . Once you click is not possible to abort the software installation. If the details are not correct, click to return to the previous screen(s) and make your corrections.
Install , it Previous
The software installation begins. You can monitor the progress of the installation through various windows, for instance while Alliance Access copies files. At the end of the software installation, the Installation Complete window appears, confirming a successful installation. The window displays information about the port configuration. For more information about port configuration, see "TCP Configuration for the Alliance Access Server" on page 243. The window also reminds you to perform SWIFTNet configuration activities. 25. Click
Finish
to complete the installation.
42
Installation
Note
Once the installation has completed successfully, if you have installed from DVD, remove the DVD as follows: 1. Check if the volume manager vold is running by typing: ps -eaf | grep vold If vold is running, then a line similar to the following appears: root 342 1 80 Oct 16 ? 0:01 /usr/sbin/vold If vold is not running, restart it by typing: /etc/init.d/volmgt start 2. To remove the DVD, type: cd ~ eject If this command returns the error Device is busy, this means that there is some process still using the DVD software. This is probably the System Administration application itself. Quit the System Administration window and run the following in the controlling x-term: cd / Try again to eject the DVD.
26. Perform the post-installation steps described in the Release Letter. Then follow the instructions in "Post-Installation Checklist" on page 47. 27. Following initial software installation, when the servers are first started, one alarm message, per live destination, is displayed, similar to:
********************* ALARM ******************** SUBSET DEFINITION: 'XXXX': INITIALISED TO SYSTEM DEFAULT
Such alarms, which are also logged in the Event Journal as 'severe' events, result from the fact that the licensed destinations do not yet have delivery subsets defined for them in Alliance Access. These alarms are normal.
3.3
3.3.1
Silent Installation
Install Alliance Access Silently From DVD
Before starting an installation, ensure that the machine is reserved for your use for the duration of the installation. To install Alliance Access silently from DVD 1. Log on as root (or Alliance Access owner account). Note: it is assumed that the root account (or Alliance Access owner account) will use the Korn shell. See the entry for root (or Alliance Access owner account) in the /etc/passwd file. The entry should end with the following shell invocation:
..:/bin/ksh
Overview
30 September 2011
43
2.
where <IPaddressComputer> must be replaced by the IP address for the computer where the installation windows will be displayed. 3. Ensure that the SunOS directory where the Alliance Access software will be installed has been created by the Solaris system administrator. Ask your system administrator for the name of this directory. During the installation, you are prompted to supply this directory as part of the release tree path name. If the disk space requirements for the temporary files for the install program cannot be satisfied, then you can use the installer option -tempdir <TMPDIR> to specify an alternate temporary directory. If you are using the standard /tmp directory, then remove all sh* files from the directory by typing:
rm /tmp/sh*
4.
5.
6.
Check that the volume manager vold is running by typing:

ps -eaf | grep vold

If it does not appear, then start the volume manager by typing:

7. 8.
9.
Start the installation process by typing: ./saa-install -silent <response file> [-key <value>] Where: <response file> identifies the path to and name of the properties file to be used. For example:
/tmp/alliance/silent.properties.install.saa.embedded
Note
The licence file must also be present in the same directory.
-key <value> specifies the key to be used if the password(s) in the response file have been encrypted. Important Throughout the installation, the install program periodically accesses the install drive to copy, install, and license the various components of Alliance Access. It is therefore important that you leave the Alliance Access release DVD in its respective drive until the installation is complete.
10. Perform the post-installation steps described in the Release Letter. Then follow the instructions in "Next Steps" on page 47.
44
Installation
Installing from a remote DVD drive 1. 2. 3. 4. 5. Mount the DVD on the remote system. Share/export this file system on the remote machine as an NFS resource. Mount this file system on the local machine Access the DVD from the local machine using the local name. Navigate to the following directory in the folder for Alliance Access: /SunOS/installer 6. Type: ./saa-install -silent <response file> [-key <value>] Where: <response file> identifies the path to and name of the properties file to be used. For example:
-key <value> specifies the key to be used if the password(s) in the response file have been encrypted. 7. Perform the post-installation steps described in the Release Letter. Then follow the instructions in "Next Steps" on page 47.
Viewing the silent installation progress or result The installation log file is updated during a silent installation. You can view the log to see the progress of the silent installation, or the result if the silent installation operation has ended.
3.3.2
Install Alliance Access Silently From a Directory

The following procedure describes how to start the installation from a directory.
Introduction
To start the installation process: 1. If the disk space requirements for the temporary files for the install program cannot be satisfied, then you can use the installer option -tempdir <TMPDIR> to specify an alternate temporary directory. Check that the volume manager vold is running, by typing:
ps -eaf | grep vold
2.

If this line does not appear, then start the volume manager by typing:
3. 4.
Insert the Alliance Access release DVD. Copy the DVD contents to an install directory on hard disk by typing:
mkdir <install directory>
30 September 2011
45
cd <install directory> cp -r /cdrom/<mount point>/* .
5.
6.
Type: ./saa-install -silent <response file> [-key <value>] Where: <response file> identifies the path to and name of the properties file to be used. For example:
-key <value> specifies the key to be used if the password(s) in the response file have been encrypted. Important Throughout the installation, the install program periodically accesses the install directory to copy, install, and license the various components of Alliance Access.
7.
Perform the post-installation steps described in the Release Letter. Then follow the instructions in "Next Steps" on page 47.
To install from a remote directory: 1. 2. 3. 4. Copy the DVD contents to a directory on the remote machine. Share/export this file system on the remote machine as an NFS resource. Mount the directory on the local machine. Access the directory from the local machine using the local name <mount_point> . For example:
5.
Type: ./saa-install -silent <response file> [-key <value>] Where: <response file> identifies the path to and name of the properties file to be used. For example:
-key <value> specifies the key to be used if the password(s) in the response file have been encrypted. 6. Perform the post-installation steps described in the Release Letter. Then follow the instructions in "Next Steps" on page 47.
Viewing the silent installation progress or result The installation log file is updated during a silent installation. You can view the log to see the progress of the silent installation, or the result if the silent installation operation has ended.
Installation
3.4
Next Steps
How to use this section After installing Alliance Access, you must perform a number of software tasks before it is ready for daily use. To complete these tasks, you must have other SWIFT documentation available. The best way to proceed is to read carefully what you have to do for each task. If you are not sure what is required of you, then go to the other SWIFT documentation that is referred to in the task. Also, remember that there is an online Help system installed with Alliance Access. If, after careful reading of all the documentation, you are still not sure how to proceed, then contact Support. You must have the following documentation available: System Management Guide FIN Initial Services Forms
3.4.1
Post-Installation Checklist
If operators will use one-time passwords, or if you want to use LDAP repositories to authenticate users, then make sure that an authentication server has been provided and deployed. For more information about one-time passwords and authentication servers, see the Security Guide and the System Management Guide.
Authentication of users
Post-installation checklist Use the following checklist to configure the installed software for live users:
Action If you are going to use Alliance Web Platform, install it and load the packages for Alliance Access Log on to Alliance Access using the administrator account. Enter a new password when prompted. This must be done from the console to avoid any $DISPLAY problems. Start the Alliance Access servers Wait for servers to be ready. Do not quit the System Administration application. From Alliance Workstation, sign on as left security officer using Part 1 of the Master Password. Update left security officer password. From Alliance Workstation, sign on as right security officer using Part 2 of the Master Password. Update right security officer password. Do not sign off Create customised operator profiles (or use the defaults provided). Create new operator(s) (with "Supervisor" or "SuperKey" privileges). Assign SWIFTNet Support application permissions to other operators if needed.
30 September 2011
Responsible Alliance Administrator Alliance Administrator
Documentation Web Platform documentation Security Guide Installation and Administration Guide Installation and Administration Guide Installation and Administration Guide Security Guide System Management Guide Security Guide System Management Guide
Alliance Administrator Alliance Administrator Left security officer
Right security officer
Right security officer Right security officer
Security Guide System Management Guide
47
Action Approve new operator(s). Display RIGHT part of system password(s) for new operator(s). Sign on to Alliance Access as left security officer using updated password. Approve operator(s). Display LEFT part of system password(s) for new operator(s). Sign on to Alliance Access as an operator, using the system password received from left security officer/ right security officer. Update operator password when prompted. Create units (if required). Assign units to operators (if required). Set up your security parameters. In the System Management application, define and select the SWIFT destination for alarm generated messages (MT 999). Not required for standalone Alliance Access: In the System Management application, start the SNIS, used for InterAct and FileAct (including RMA (Relationship Management application)) Sign off. Restart Alliance Access in Housekeeping mode. When servers are ready, sign on using updated password. Install and activate Value Added Service Parameter Files (if required). Install the Alliance Bank File from the Correspondent Information File application (if required). Install any MX Standards which are to be used (if required).
Responsible Right security officer Right security officer Left security officer Left security officer Left security officer New operator (with "Supervisor" or "SuperKey" privileges) New operator New operator Left security officer / Right security officer Alliance Administrator New operator
Documentation System Management Guide System Management Guide System Management Guide System Management Guide System Management Guide System Management Guide
System Management Guide System Management Guide System Management Guide Security Guide System Management Guide
New operator
System Management Guide
New operator New operator New operator New operator New operator New operator
Daily Operations Guide System Management Guide Daily Operations Guide System Management Guide System Management Guide "Installing MX Standards" on page 50 System Management Guide System Management Guide
To prepare your Destinations, install the Message Syntax Tables (MSTVs) from the SWIFT Support application. Still in Housekeeping mode, define the LTs (Logical Terminals) and assign each to an MST. Restart Alliance Access in Operational mode Create an internal correspondent for your Test & Training destination. Open the Correspondent Information File application and in the Search Criteria window, click Cancel .
New operator
New operator New operator New operator
System Management Guide System Management Guide Daily Operations Guide
48
Installation
Action From the Correspondent menu, select New, and in the Institution field, enter your BIC-11 Test & Training code, for example ALIBBEB0XXX. Add the details fields, if required. Click the Other tab and change the Correspondent Definition to Internal. Click the Integrated Application tab. In the Preferred Networks list, transfer "SWIFT" from Available to Selected. From the Correspondent menu, select Add. Set up the RPC and SSL Security between Alliance Access and Alliance Workstation (if required). Not required for stand-alone Alliance Access: Define a SWIFTNet connection and assign a logical terminal to it, and then send and receive a test message. To test the connection, you need the details of the Alliance Gateway instances that you plan to use. Define new message partners (if required)
Responsible New operator
Documentation Daily Operations Guide
New operator
Daily Operations Guide
Alliance Administrator
See "RPC and SSL Security for Alliance Workstation" on page 53. Part B, "Configuring for SWIFTNet" on page 97
New operator
System Management Guide System Management Guide
Not required for stand-alone Alliance Access: New operator In the System Management application, start SNIS, used for InterAct and FileAct activities (including RMA (Relationship Management application)) Not required for stand-alone Alliance Access: Check SWIFT communications Update delivery subsets if they are different from the defaults (System, Urgent, Normal): generate MT 035 in Message Creation application Login/Select (I/O without delivery subsets selected) the logical terminal used to send the MT 035 wait for MT 055 response (handled automatically by Alliance Access). Subsets are updated. perform QUIT for this logical terminal Redefine delivery subsets, if the defaults are insufficient: redefine the subsets by using the SWIFT Interface application Login with this logical terminal to send the message If you have installed from a backup file and the Database Recovery option is licensed, you must manually activate database recovery by using the saa_dbrecovery tool. Not required for stand-alone Alliance Access: Alliance Administrator Any operator Any operator
Any operator
Daily Operations Guide
"Activate the Database Recovery Mode" on page 176 Part B, "Configuring for SWIFTNet" on page 97
Alliance Administrator
30 September 2011
49
Action If you plan to test the connection with SWIFT, then ensure that the SWIFTNet connection with the Alliance Gateway is operational. Install and configure printers (if required)
Responsible
Documentation
Solaris System Administrator
Oracle Solaris manuals System Management Guide
3.4.2
Additional Tasks after a Non-root Installation

After the installation of Alliance Access by a UNIX account without root privileges, the following tasks must be performed with the UNIX root account: 1. 2. Log on as root. Navigate to the installation directory and run the script called saa_rootpostinstall.ksh. For example: <Install_directory>/install/saa_rootpostinstall.ksh The script: runs the RPCConfiguration.ksh script which delivers the new version of the files in the /usr/swa directory. adds the new Alliance Access instance in /usr/swa/insts. runs the apply_alliance_ports script which configures the Alliance ports in /etc/ services. runs the MPConnConfig.tcl script which configures the MPConn ports in /etc/services (ports required for the CAS message partners). copies the installation registry entry (a file generated in the installation directory during installation) of the product to the central registry location on the system (/var/opt/swift). starts the Alliance Access Name Service of the Alliance Access instance with the highest release number.
Procedure
3.4.3
Installing MX Standards
To allow MX keyword extraction on Alliance Access from messages exchanged over SWIFTNet service or services to which you subscribed, the corresponding MX standard(s) must be installed on Alliance Access and on the Messenger package of Alliance Web Platform. You can download the appropriate message standards deployment package(s) and accompanying cover letter(s) from the Download Centre on www.swift.com > Support > Download Centre. Note Using the Messenger 6.3 package to install a message standards deployment package on Alliance Access 7.0 is not supported. Support for System Messages related to SWIFTNet 7.0 requires the installation of the SWIFTNet 7.0 System Messages Deployment Package.
Description
50
Installation
3.4.4
Configuring RMA for Test and Training

This procedure provides additional instructions for configuring RMA for FIN Test and Training. For FIN Test and Training destinations, a licensed live BIC8 that is used to sign all authorisation messages for FIN Test and Training. You must configure a licensed BIC as the destination for all FIN Test and Training authorisation messages. That BIC is referred to as the Signing BIC for Test and Training.
Purpose
RMA service for FIN Test and Training The authorisations for the pilot service and FIN Test and Training are exchanged over swift.rma!p. To configure RMA for test and training: 1. Define the Signing BIC for Test and Training, as the signing destination of all FIN Test and Training authorisation messages. The Signing BIC for Test and Training must be the BIC8 for which you will create the emission and reception profile. For more information, see "Defining the Signing BIC for Test and Training Authorisations" on page 52. 2. For FIN Test and Training destinations, define a SWIFTNet Emission profile and a Reception profile for each Signing BIC for Test and Training. For more information, see "Configuring SWIFTNet Emission and Reception Profiles" on page 110. 3. If necessary, change the operator profiles and assign them to the users that will operate and administer the RMA. You can use or adapt the default operator profiles, RMA_Admin and RMA_Oper, or create profiles for your own use. For more information about the default operator permissions, see the System Management Guide. For details about default operator profiles, and for instructions on modifying or assigning a profile to a user, see "Managing Alliance Access Security" in the System Management Guide. 4. If you do not want to confirm the authorisations that your correspondent revokes or rejects, then set the Needs Status Confirmation security parameter. For more information, see "Security Parameters" in the System Management Guide. Note The confirmation is for information purposes only. The revocation and rejection of the authorisation always takes effect regardless of whether the action is confirmed or not.
3.4.5
Configuring RMA for the SWIFTNet Integration Testbed

This procedure provides additional instructions for configuring RMA for the SWIFTNet Integration Testbed. Perform these instructions on the Alliance Access server, and on each Alliance workstation.
Purpose
30 September 2011
51
Important
Only SWIFT, and its partners and vendors that have a BIC starting with PT, must perform this procedure.
When to use Perform this procedure after the Alliance Access software has been installed. RMA services When RMA is configured for the SWIFTNet Integration Testbed, authorisations are exchanged over the pilot service, swift.rma!x. To configure RMA for the SWIFTNet Integration Testbed: 1. In the home directory of the Alliance administrator (all_adm), enter the following command:
vi .swa.$ALLIANCE_INSTANCE.rc
2.
Add the following line to the swa.$ALLIANCE_INSTANCE.rc file:

export RMA_SERVICE_NAME=swift.rma!x
3.
Save the changes to the file, and quit the vi editor.
To apply the changes to the variable, you must close and re-open the System Administration window.
3.4.6
Defining the Signing BIC for Test and Training Authorisations

FIN Test and Training authorisations are exchanged as InterAct messages over the swift.rma!p service over SWIFTNet, and are signed by an Authoriser DN. Therefore, you must define a licensed live BIC, the Signing BIC for Test and Training, as the signing BIC8 destination of all FIN Test and Training authorisation messages. This procedure provides instructions for setting the value of the Signing BIC for Test and Training, which must be a BIC8 for which an emission profile and a reception profile is defined for the service swift.rma!p.
Purpose
Users and permissions You can define the Signing BIC for Test and Training when the Def Signing BIC T&T function is assigned to you in the Relationship Mgmt application. To define the Own Signing BIC: 1. 2. Launch the Relationship Management application. From the File menu, select Signing BIC for T&T. The Define Signing BIC for T&T RMA window appears.
52
Installation
3. 4.
Select a BIC8 to use for signing Test and Training authorisations. Click
OK
3.4.7
RPC and SSL Security for Alliance Workstation

Security between the Alliance Access servers and an Alliance Workstation is defined by the RPC Authentication configuration parameter. After a new installation, the default setting is Process Authentication. Security officers can change this setting from the Security Definition application. If you upgrade to release 7.0, then the upgrade process migrates your current setting for the parameter. Secure Socket Layer (SSL) is also available for the encryption of the data for the communication between the Alliance Access server and an Alliance Workstation. This can be as follows: If Off or Process Authentication is selected, then Alliance Access does not use SSL for communication with the Alliance Workstation. If Data Integrity or Data Confidentiality is selected, then Alliance Access initialises its process communication with SSL enabled. If SSL is enabled, then the Alliance Workstation can also use Server authentication. Communication with Alliance Web Platform is always initialised with SSL enabled and Alliance Access server authentication is required. The following security options are available for process communication with the Alliance Workstation: SSL SSL and Server Authentication No SSL If SSL is used, then the ssl.p12 file contains the self-signed certificate and private key. For Alliance Access, this file is stored in the $ALLIANCE_DB directory. A self-signed certificate is generated and imported during installation or migration. The default certificate is contained in the cacert.crt file in the $ALLIANCE_DB directory. This default certificate expires after 730 days. The DN of the default certificate has the value cn=saa_<instance name>. It is contained in the .cert_dn file also located in the $ALLIANCE_DB directory. Each installed Alliance Access system has its own self-signed certificate after the installation of the software. If your disaster backup system requires the same certificate as your live system, then you must regenerate a certificate on the live system and import this certificate on the disaster backup system. If Server Authentication is used, then it is the responsibility of the Alliance Administrator to maintain the CA Certificate and Private Key. The CA Certificate can be generated or a request created using the swrpc_keytool tool. The CA Certificate must then be imported into Alliance Access using the saa_configconnection tool. For details, see "saa_configconnection" on page 230.
Introduction
30 September 2011
53
3.4.7.1 Certificate Generation for Server Authentication (swrpc_keytool)

Overview If Server Authentication is used, then it is the responsibility of the Alliance Administrator to generate a CA Certificate and Private Key. A self-signed Certificate or CA Certificate request is created using the swrpc_keytool tool. This tool is located in $ALLIANCE/ BSS/bin/$ARCH and is run from the command line. To generate a self-signed certificate or certificate request: 1. 2. 3. Log on as Alliance Administrator (all_adm). Open an X-term from the OS Configuration menu in the System Administration window. Move to the directory containing swrpc_keytool: cd $ALLIANCE/BSS/bin/$ARCH 4. Run swrpc_keytool from the command prompt: ./swrpc_keytool 5. Follow the instructions displayed to generate either a "self-signed certificate" or a certificate request.
a
Do you want: 1: a self-signed certificate
If you select 1, then a self-signed certificate is generated, which is signed with its corresponding private key. In this case the CA certificate and the certificate itself are identical. The subject and issuer of a self-signed certificate are the same. If you select 2 to generate a certificate request, then a PKCS10 file (Request for Certificate), is generated. You must present this file to a CA (Certificate Authority) to receive a certificate. In this case, the subject and issuer of the certificate are different. The subject is the DN you entered in the certificate request, and the issuer is the DN of the CA. To use server authentication in this case, you must receive both the certificate and the CA certificate. Enter the path and file name for the private key. If you enter only the file name by default, then the file is created in the current directory. The key is password-protected. Select a password that complies with your institution's password policy and the following rules. The password must have: min. 8 and max. 30 alphanumeric characters at least 1 uppercase, 1 lowercase, and 1 number Repeating consecutive characters may not exceed half the password: and may not be equal to the protected file name.
2: a certificate request [default, 1]:
File name for the new key:
Enter a password of your choice:
Re-enter the password for verification:
Re-enter the password for verification: The new key is now generated. If you selected option 2 in step a, then skip to step g. Enter the file name for your certificate. If the file exists, then you are prompted to overwrite the file. If the file does not exist, then skip to step i.
File name for the certificate:
54
Installation
f g
Overwrite existing file? [default, n]: File name for the certificate request:
Enter yes (y) to overwrite an existing file: skip to step i, or enter no (n) to return to step e. Enter the file name for your certificate request. If the file exists then you are prompted to overwrite it. If not, skip to step i. Enter yes (y) to overwrite an existing file: skip to step i, or enter no (n) to return to step g. This DN can contain the following attributes: C or country<para> ST for state or province</para> L or location name</para> O for organisation name OU for organisational unit CN for common name EMAIL for the e-mail address Example: CN=SAA1,OU=department1,O=institution1. Enter the DN. A check is then performed on the DN. For a certificate request, this is the last step and now the tool terminates.
h i
Overwrite existing file? [default, n]: Enter the distinguished name (DN) to be included in the certificate: This DN is needed if you want to configure authentication.
Number of days your certificate is valid [default, 30]:
Enter the number of days the certificate can be used. By default it is 30, the maximum value is 3565.
The self-signed Certificate or CA Certificate request is now generated.
3.4.7.2 Importing Certificates

Description The new Certificate and Private Key must then be imported into Alliance Access using the saa_configconnection tool. For details, see "saa_configconnection" on page 230. Warning Applying this procedure requires the new certificate to be distributed to the Alliance workstations configured to use Server Authentication and to Alliance Web Platform. A restart of the Alliance Access server after running the saa_configconnection tool activates the changes on the server. Clients using Server Authentication (for example, Alliance Workstation or Alliance Web Platform) must use the old certificate until the server restart and the new certificate after the server restart.
30 September 2011
55
3.4.7.3 Certificate Expiry Management

Description Before an Alliance Access certificate expires, the user must generate a replacement certificate. The generation of a new certificate on Alliance Access must be done using swrpc_keytool. If there are less than 30 days remaining before the expiry of a certificate, then an event is generated in the Alliance Access Event Journal. This event is generated at startup of the Alliance Access servers, and also at midnight every day, until the new certificate is imported using the saa_configconnection tool. For details, see "saa_configconnection" on page 230.
3.4.8
The Alliance Developers Toolkit

To enable third parties to develop their own proprietary applications, SWIFT provides a suite of software known collectively as the Alliance Developers Toolkit. The objective of the Alliance Developers Toolkit is to make the Alliance Access base service facilities available to developers of third-party products. Using the Alliance Developers Toolkit, these developers can go on to build their new products at reduced cost and thus increase the number of Alliance Access products available to customers. This is done by: taking advantage of the Alliance Developers Toolkit facilities provided by Alliance Access to develop new components re-using and interacting with existing Alliance Access components (for example, Application Interface (AI), SWIFT Interface (SIA)).
Introduction
Contents The Alliance Developers Toolkit contains: documented APIs to access the services offered by these facilities. These APIs guarantee independence with respect to Alliance Access internal applications. a procedure to install components and configure these facilities so that they fit the application's needs, without interfering with existing installed applications. A de-installation procedure to restore the situation before application installation. Security The Alliance Developers Toolkit reinforces the internal security mechanisms of Alliance Access by: minimising the risk of running "break-in" applications that can tamper with the system restricting the access of new components (through the use of application profiles like operator profiles) to the set of services which they officially claim to require.
56
Installation
3.4.8.1 Delivery Packages

Description The Alliance Developers Toolkit is delivered as two packages to be installed on top of a version of Alliance Access supporting the Alliance Developers Toolkit. This is a runtime package installed at customer sites to support components developed with the Alliance Developers Toolkit, plus a development package used to develop new components with the Alliance Developers Toolkit outside of the Alliance development environment. The runtime package consists of: a (set of) shared libraries that implement C bindings for the Alliance Developers Toolkit APIs a component installation/uninstallation procedure The development package consists of: header files containing 'C' code prototypes of the functions provided in the Alliance Developers Toolkit, with the required type definitions, return statuses, and so on. a tracing package for debugging purposes a tool to create an installation medium (adk_mk_medium) example application(s) and example makefiles.
3.4.8.2 Alliance Developers Toolkit Documentation

Description In-depth documentation on creating an installation medium and the installation of Alliance Developers Toolkit components is supplied with the Alliance Developers Toolkit development license.
3.4.9
Install Alliance Developers Toolkit Third Party Software Applications

The installation of a third-party component is organised into two domains: software installation service registration The software installation utilities handle all operations involved with the component (for example, downloading or upgrading, patching, and so on), while the registration procedure introduces the component to Alliance. This identification is required to allow the component to use the Alliance services. The following table shows each installation utility:
Domain Software Utility Install a component Upgrade a component Description Initial installation of the software of a new component Upgrading the software of an existing component to a more recent version
Introduction
30 September 2011
57
Domain
Utility Remove a component Add a patch Remove a patch
Description Remove all the software of an existing component Add a patch to an existing component Remove the last installed patch from an existing component Register to SWA services: either for a new component or for an upgrade Unregister the component
Services
Register a component Unregister a component
Note
For more information about how to install components, refer to the documentation of your third-party vendor.
Unit assignment to Alliance Developers Toolkit components When installing Alliance Access with optional package 99:TOOLKIT RUN-TIME licensed, a unit named "_ALL_" is defined and is available in the Component view of the Security Definition application (SDA). This unit is assigned by default to the Alliance Developers Toolkit component. When the _ALL_ unit is assigned to a component, no unit restrictions exist for that Alliance Developers Toolkit component.
58
Upgrade
Upgrade
Overview You can upgrade to Alliance Access 7.0 from the following releases: Alliance Access 6.0 Alliance Access 6.3 If you have an earlier release installed, then you must upgrade to release 6.0, or 6.3 before upgrading to 7.0. If you have Alliance Access 6.2 installed, then you must upgrade to release 6.3 before upgrading to 7.0. You can also upgrade to Alliance Access 7.0 from the following releases of Alliance RMA: Alliance RMA 6.0 Alliance RMA 6.3 Do NOT remove Alliance Access before starting the upgrade process. Use the release media.
4.1
Before You Upgrade

Two ways to upgrade You can upgrade to Alliance Access 7.0 in either of the following ways: on the same host where a previous release of Alliance Access is installed migrate to a new host, using a backup file prepared on an existing host. This feature can only be used between two systems of the same operating system (from Oracle Solaris to Oracle Solaris). Tip If you are migrating to a new host, then follow the instructions in "Prepare a Backup File for Upgrade" on page 29 before you check the prerequisites in this section and launch the upgrade.
Important Ensure that you complete all the upgrade prerequisites. During the upgrade, any prerequisites that have not been fulfilled (and would make the upgrade fail), are reported one by one. For example, if there are still live messages in the database or events from yesterday which have not been archived, then the upgrade will quit. In this case, you must start the servers, archive and back up the messages or events, stop the servers, and then restart the upgrade. Prerequisites The prerequisites for an upgrade are the same as for a standard installation (for details, see "Prerequisites for the Installation" on page 32). However, there are a number of additional requirements: 1. Alliance Access release 6.0 or 6.3 (with latest mandatory patches) must already be installed on your system.
30 September 2011
59
2. You must have the necessary Solaris patches available. For details, see the Release Letter. 3. For a silent upgrade, you must prepare the following files: a licence file. See "Prepare the Licence File" on page 21. a response file. See "Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal)" on page 22. 4. To allow immediate connection of your Alliance Workstations to your Alliance Access 7.0 server, we strongly recommend that you ensure that all workstations are installed with Alliance Workstation release 7.0. You cannot connect previous releases of Alliance Workstation to an Alliance Access 7.0 server. 5. During the upgrade, a copy of your database folder is made in a mig directory in the release tree. Ensure that the drive where the Alliance release tree is currently installed contains enough free space for this database copy. Note After a successful upgrade and after making a backup of your upgraded system, you can delete the mig folder to save disk space.
6. From the SWIFT Interface application, Quit and Logout all logical terminals and switch them all to Manual Mode. For details, see the Daily Operations Guide. 7. From the SWIFT Support application, ensure that the latest Message Syntax Table is assigned to the logical terminals that are in use. For details, see the System Management Guide. 8. From the Application Interface application, select all the message partners and disable them. 9. Export RMA authorisations. For details, see "Exporting Authorisations Manually" in the Relationship Management Application User Guide. Note During the upgrade, RMA authorisations are automatically migrated to the new release. This step is only to provide you with a backup in case of problems with key migration during the upgrade process.
10. Ensure that all message templates have the latest message syntax table assigned and export them all. For details, see "Exporting Templates" in the Daily Operations Guide. Note During the upgrade, templates are automatically migrated to the new release. This step is only to provide you with a backup in case of problems with template migration during the upgrade. If, after the upgrade, message templates cannot be opened or modified because they are assigned to an earlier message syntax table, then you can export the message templates and assign the latest message syntax table to them during the import. 11. Check that no alarms are formatted as MT 999 and generated from event distributions for internal correspondents. If this is the case, such alarms can generate new live messages in Alliance Access causing the upgrade process to fail as no live messages are allowed in Alliance Access when upgrading. These alarms must be removed before upgrading.
60
Upgrade
12. To be able to perform the upgrade, it is mandatory to archive: all messages from the Message File, if you upgrade from release 6.0. You may have to complete some messages manually before you can archive them. all messages from the Message File up to the previous day, if you upgrade from release 6.3. You may have to complete some messages manually before you can archive them. Messages of the current day are migrated. all events up to the previous day from the Event Journal application. Events of the current day are migrated. all Audit Cards. 13. Back up the message archives, journal archives, and any Audit Cards, from the System Administration window. This is mandatory if you want to access your archives on the upgraded system. Note If you upgrade from release 6.3, then you must back up and remove the archives of the previous days.
14. Prepare the migration from strict to relaxed certificate mode. See the Release Letter for detailed instructions. 15. Stop the Alliance Access servers. 16. Before starting the upgrade, it is strongly advised that any existing Alliance Access and associated database files and archives, are backed up. It is also advisable to back up the operating system. In addition, it is recommended that you make a backup of the /usr/swa instances registration data. If the upgrade fails, then you can restore the original software and database, but remember to restore the original /usr/swa directory (including insts) before you attempt to restart the system. Important If you are upgrading from 6.3, then you should also back up the /var/opt/swift directory before starting the upgrade.
17. Make a note of the $ALLIANCE and $ALLIANCE_DB variables. You may need access to this information if the upgrade fails. In such a case, you have to re-export these variables before restoring the previous software and database. Note Ensure that the path to the database is not a symbolic link. You may have to update the /usr/swa/insts file temporarily to point to the real directories.
18. During the upgrade, Alliance Access overwrites the existing user environment file .profile for the Alliance Access administrator account. The existing .profile is saved as .profile.bak suffixed by an incremental number in case it exists. 19. After the upgrade, database recovery is not automatically restarted. If you have activated this option, you must deactivate it before the upgrade starts, and reactivate it once the upgrade has been completed. See "Activate the Database Recovery Mode" on page 176 for details.
30 September 2011
61
Checklist
Task The host satisfies the system requirements. If upgrading to a new host: The software owner system account has been created. The default temp directory has been created. "Create the Temporary Installation Directory" on page 19 "Prepare a Backup File for Upgrade" on page 29 Release Letter Reference "Prepare the System" on page 15
If upgrading to a new host: The backup file from the previous release is available Prepare the migration from strict to relaxed certificate mode.
4.2
4.2.1
Interactive Upgrade
Starting the Upgrade From DVD
To start the upgrade from a remote DVD drive, see "Upgrading From a Remote DVD Drive" on page 63. To start the upgrade from DVD: 1. Log on as root. Note It is assumed that the root account will use the Korn shell. See the entry for root in the /etc/passwd file.
Remote DVD drive
2.
where <IPaddressComputer> must be replaced by the IP address for the computer where the upgrade windows will be displayed. 3. Check that the volume manager vold is running, by typing:
ps -eaf | grep vold

If this line is not displayed, then start the volume manager by typing:
4. 5.
6.
Start the upgrade by typing:

./saa-install
62
Upgrade
To record the upgrade details for future use, run the saa-install command with the record option. See "Record input parameters" on page 88 for more information. 7. To proceed with the upgrade, follow the steps in "Upgrade Alliance Access Interactively" on page 64.
4.2.1.1 Upgrading From a Remote DVD Drive

To upgrade from a remote DVD drive: 1. 2. 3. 4. 5. Insert the DVD on the remote machine. Mount the DVD on the remote machine. Share/export this file system on the remote machine as an NFS resource. Mount the remote directory on the local machine. Access the DVD from the local machine using the local name <mountpoint> for the remote directory. For example:
6.
Start the upgrade by typing the following command: ./saa-install To record the upgrade details for future use, run the saa-install command with the record option. See "Record input parameters" on page 88 for more information.
4.2.2
Starting the Upgrade From Local Directory

To start the upgrade from a remote directory, see "Upgrading From a Remote Directory" on page 64.
Remote directory
To start the upgrade process: 1. 2. Log on as root. It is assumed that the root account will use the Korn shell. See the entry for root in the /etc/passwd file. If you are working remotely, then export the display to your local machine by typing:
ps -eaf | grep vold

30 September 2011
63
4.
Copy the DVD contents to an install directory on hard disk:

mkdir <install directory> cd <install directory> cp -r /cdrom/cdrom0/* . (or cp -r /cdrom/cdromx/* . if there are multiple drives)
5.
Eject the DVD:

eject
6.
7.
8.
To proceed with the upgrade, follow the steps in "Upgrade Alliance Access Interactively" on page 64.
4.2.2.1 Upgrading From a Remote Directory

Introduction To upgrade from a directory on a remote file system, the remote file system must be mounted correctly on the local system. Otherwise, the upgrade fails. To upgrade from a remote directory: 1. 2. 3. Copy the DVD contents to an NFS directory on the remote machine. Mount this file system on the local machine. Access the directory from the local machine using the local name <mountpoint> for the remote directory. For example:
4.
4.2.3
Upgrade Alliance Access Interactively

Events that occur during upgrade are recorded in the installation.log file, found in the Alliance Access installation path. In case of upgrade failure, please check this file for the reasons of the failure.
Installation event log
64
Upgrade
To upgrade Alliance Access: 1. When the upgrade program starts, it unpacks the files required. Once all the files are unpacked, a window similar to the following appears.
2.
If you are upgrading on the same host, select the Upgrade option. If you are upgrading on a new host, select Install Alliance Access 7.0 from Prepared Backup File.
3.
Click
Next
The End-user Licence window appears. 4. Accept the terms, and click
Next
If you selected the Upgrade option, go to step 6. If you selected Install Alliance Access 7.0 from Prepared Backup File, the Backup File Location window appears.
30 September 2011
65
5.
Browse to the location of the backup file that you created in "Prepare a Backup File for Upgrade" on page 29. You cannot use a backup file created with Alliance Access Release 6.x. Click
Next
6.
The Installation Location window appears.
7. 8.
Verify the user account displayed in the Owner field and type the password for this account. This user account is the Alliance Access owner. Click
Next
If you selected the Upgrade option, then a message appears, prompting you to close all the Alliance applications that are currently open before proceeding with the upgrade. 9. Click
Next
The checkhost command is run to validate whether your system meets the minimum operating system requirements. The test results are saved in the software installation directory, in the file: installation_systemcheck_yymmdd_hhmmss.html where yymmdd and hhmmss are the date and time of the upgrade. If you selected the Upgrade option, then a message appears, reminding you to take Alliance Access environment (software, database, and archives) and system backups. If you have taken these backups, then click Next . Otherwise, click Cancel to quit the upgrade process. Take the necessary backups, and then repeat this procedure. The Packages Configuration window appears.
66
Upgrade
This window is used to license the packages and features that your institution has purchased from SWIFT. The pre-selected packages are part of the base licence and include the packages already licensed on your previous installation of Alliance Access. They cannot be deselected. Note If your system does not meet all the requirements, then the System Configuration Test Results window displays information about the problems that were detected. Problems reported as Warning do not prevent you from continuing the upgrade, but you may encounter unexpected results. Problems reported as Blocking prevent you from continuing the upgrade. Fix the problem and start the upgrade again. 10. Decide how you want to provide licence-related data: Manually: proceed to step 11. From a licence file: click Load from File and browse to the location of the licence file. This is the licence file that you prepared in "Prepare the Licence File" on page 21. Then click
Next
and proceed to step 16.
11. Verify that all the items listed in the Packages section of your licensing agreement are selected. Then click Next . Note You may want to license additional component packages or 'disable' selected component packages after the upgrade is finished. To do this, you can relicense Alliance Access using a new licensing agreement. You do not have to reinstall. For more information, see "Relicensing" on page 77.
30 September 2011
67
12. The Servers Configuration window appears.
Verify that all the items listed in the Servers section of your licensing agreement are selected. Then click Next . 13. The Licensed Destinations Configuration window appears, showing the destinations already licensed on your Alliance Access system. 14. If necessary, add or remove destinations according to your licensing agreement. If you have to add new destinations, type: the 8-character live destination(s) listed on your licensing agreement the 8-character training destinations. The eighth character is a ''0'' to denote test and training. Although the test and training destination does not appear on your licensing agreement, you must enter it if you want to use it. Each destination must be on a separate line. Once you have typed all your destinations, click Next . The Message Types Configuration window appears, showing the message types already licensed on your Alliance Access system. 15. If necessary, add or remove message types, as listed on your licensing agreement. Each message type must be on a separate line. Once you have typed all your message types, click Next . The Initialisation Password Configuration window appears.
68
Upgrade
16. Enter the initialisation passwords as follows: The Security Officer who received the INITIALISATION PASSWORD provided in Part 1 of 2 of the licensing agreement must type this password in the First initialisation password field. The Security Officer who received the INITIALISATION PASSWORD provided in Part 2 of 2 of the licensing agreement must type this password in the Second initialisation password field. Note Do not confuse the Initialisation Passwords with the Master Passwords. The Master Passwords are used by the two Security Officers when they first sign on to Alliance Access.
Next
17. Click
.
OK
If the password verification fails, then an error message appears. Click correct input. 18. The Instance Configuration window appears.
Field Host Name IP Address Instance Name Instance Comment Description The host name of the Alliance Access system. The IP address of the Alliance Access system.
and enter the
The name of the Alliance Access instance on the Alliance Access system. The description of the instance.
19. Click
Next
If you upgrade from Alliance Access or Alliance RMA 6.3, then the Temporary location window appears. This window shows the default temporary directory that will be used during the database upgrade, and the estimated disk space required for the upgrade. 20. If there is not enough disk space in the default directory, then select another directory in the Directory Name field. Type the directory name or click Browse to select a directory.
30 September 2011
69
21. Click
Next
The Installation Summary window appears. 22. Check that the details displayed are correct, and if so, click Install . Once you click Install , it is not possible to abort the software upgrade. If the details are not correct, click Previous to return to the previous screen(s) and make your corrections. The software upgrade begins. You can monitor the progress of the upgrade through various windows, for instance while Alliance Access copies files. At the end of the software upgrade, the Installation Complete window appears, confirming a successful upgrade. The window provides information about the port configuration. For more information about port configuration, see "TCP Configuration for the Alliance Access Server" on page 243. 23. Click Note
Finish
to complete the upgrade. Once the upgrade has completed successfully, if you have upgraded from DVD, remove the DVD as follows: 1. Check if the volume manager vold is running by typing: ps -eaf | grep vold If vold is running, then a line similar to the following appears: root 342 1 80 Oct 16 ? 0:01 /usr/sbin/vold If vold is not running, restart it by typing: /etc/init.d/volmgt start 2. To remove the DVD, type: cd ~ eject If this command returns the error Device is busy, this means that there is some process still using the DVD software. This is probably the System Administration application itself. Quit the System Administration window and run the following in the controlling x-term: cd / Try again to eject the DVD.
24. Perform the post-upgrade steps described in the Release Letter. Then follow the instructions in "Post-Upgrade Checklist" on page 74.
4.3
4.3.1
Silent Upgrade
Starting the Upgrade From DVD Drive
Ensure that you completed all the upgrade prerequisites. During the upgrade, any prerequisites that have not been fulfilled (and would make the upgrade fail), are reported one by one.
Introduction
70
Upgrade
For example, the upgrade would be interrupted because there are still live messages in the database. You will have to start the servers, archive and back up the messages, stop the servers and restart the upgrade. Then it could be interrupted because there are still events from yesterday that have not been archived. You would again have to start the servers. Remote DVD drive To start the upgrade from a remote DVD drive, see "Upgrading From a Remote DVD Drive" on page 72. To start the upgrade process from DVD: 1. Log on as root. Note It is assumed that the root account will use the Korn shell. See the entry for root in the /etc/passwd file.
2.
ps -eaf | grep vold

4. 5.
6.
Start the upgrade process by typing the following command: ./saa-install -silent <response file> [-key <value>] Where: <response file> identifies the path to and name of the properties file to be used. For example:
-key <value> specifies the key to be used if the password(s) in the response file have been encrypted. 7. Perform the post-upgrade steps described in the Release Letter. Then follow the instructions in "Next Steps" on page 74.
Viewing the silent upgrade progress or result The installation log file is updated during a silent upgrade. You can view the log to see the progress of the silent upgrade, or the result if the silent upgrade operation has ended.
30 September 2011
71
4.3.1.1 Upgrading From a Remote DVD Drive

To upgrade from a remote DVD drive: 1. 2. 3. 4. 5. Insert the DVD on the remote machine. Mount the DVD on the remote machine. Share/export this file system on the remote machine as an NFS resource. Mount the remote directory on the local machine. Finally, access the DVD from the local machine using the local name <mountpoint> for the remote directory. For example:
6.
4.3.2
Starting the Upgrade From Local Directory

Ensure that you completed all the upgrade prerequisites. During the upgrade, any prerequisites that have not been fulfilled (and would make the upgrade fail) are reported one by one. For example, the upgrade would be interrupted because there are still live messages in the database. You have to start the servers, archive and back up the messages, stop the servers and restart the upgrade. Then it could be interrupted because the latest Message Syntax Table has not been installed. You would again have to start the servers.
Introduction
Remote directory To start the upgrade from a remote directory, see "Upgrading From a Remote Directory" on page 73. To start the upgrade process: 1. Log on as root. It is assumed that the root account will use the Korn shell. See the entry for root in the /etc/passwd file.
72
Upgrade
2.
ps -eaf | grep vold

4.
Copy the DVD contents to an install directory on hard disk:

mkdir <install directory> cd <install directory> cp -r /cdrom/cdrom0/* . (or cp -r /cdrom/cdromx/* . if there are multiple drives)
5.
Eject the DVD:

eject
6.
7.
4.3.2.1 Upgrading From a Remote Directory

Introduction To upgrade from a directory on a remote file system, the remote file system must be mounted correctly on the local system. Otherwise, the upgrade fails.
30 September 2011
73
To upgrade from a remote directory: 1. 2. 3. Copy the DVD contents to an NFS directory on the remote machine. Mount this file system on the local machine. Access the directory from the local machine using the local name <mountpoint> for the remote directory. For example:
4.
4.4
4.4.1
Next Steps
Post-Upgrade Checklist
1. Complete the migration from strict to relaxed certificate mode. This task must be performed on Alliance Gateway by the Alliance Gateway instance owner. See the Release Letter for detailed instructions. Log onto UNIX as Alliance Administrator. Start the Alliance Access servers in Operational mode. Both Security Officers (LSO and RSO) must sign on using the Master Passwords taken from the licensing agreement. Check the event journal for: alarms which may have occurred during the upgrade. any events relating to "OSN gaps". If a logical terminal was in the process of reconnecting (following an interrupted session) when Alliance Access was stopped before the upgrade, then it is possible that messages will be missed at the next login/
Procedure
2. 3. 4. 5.
74
Upgrade
select attempt. In such a case, events relating to OSN gaps are present in the event journal. 6. The previous Alliance Administrator account environment file .profile is saved as .profile.bak. If you want to reinstate it, then log on as system administrator, start an X-term window from Alliance Access and type:
cd~ mv .profile .profile.inst mv .profile.bak .profile exit (saves the new profile) (re-installs the old profile)
7.
Open the Application Interface application and check and enable each required message partner. For details, see "Managing Message Partner Profiles" in the System Management Guide. Alliance Developers Toolkit (ADK) licence only: all ADK applications used with Alliance Access 6.0, 6.2, or 6.3 have to be recompiled, rebuilt and re-installed before they can be used with Alliance Access 7.0. For information, contact your ADK application vendor. All existing operator profiles are migrated from the upgraded version. In addition, all default profiles are created with an "R7.0" prefix. The user can select to use the new profiles or keep the migrated ones. The new applications and/or functions are not added to the migrated profiles.
8.
9.
10. If you have to access your old message archives and journal archives, then restore a backup of the previously backed up archives from the System Management application. As archives are part of the database, this is the only way to access archives from previous releases. 11. Not required for stand-alone Alliance Access: Check Part B, "Configuring for SWIFTNet" on page 97 and follow any procedures that are applicable to your upgraded system (for example MX Messaging). 12. If you deactivated database recovery before the upgrade, then reactivate it now. See "Activate the Database Recovery Mode" on page 176 for details.
4.4.2
Additional Tasks after a Non-root Upgrade

After the upgrade of Alliance Access by a UNIX account without root privileges, the following tasks must be performed with the UNIX root account: 1. 2. Log on as root. Navigate to the installation directory and run the script called saa_rootpostupgrade.ksh. For example: <Install_directory>/install/saa_rootpostupgrade.ksh The script: runs the RPCConfiguration.ksh script which creates the /usr/swa directory, and adds files to it. updates the Alliance Access instances in /usr/swa/insts.
Procedure
30 September 2011
75
runs the apply_alliance_ports script which configures the Alliance ports in /etc/ services. copies the installation registry entry (a file generated in the installation directory during installation) of the product to the central registry location on the system (/var/opt/swift). starts the Alliance Access Name Service of the Alliance Access instance with the highest release number.
76
Relicensing
Relicensing
Introduction This section explains how to add or remove packages and features that your institution can purchase from SWIFT.
5.1
Before You Relicense

Common prerequisites Before relicensing, ensure that: all passwords and licence-related information is available. You can get this information using Secure Channel. For more information about Secure Channel, see "Secure Channel" on page 11. both Alliance Access Security Officers (or their deputies) are present, unless you are loading your licensing options from a file. if you are loading your licensing options from a file, the file is ready. the Alliance Access servers have been stopped. If not, in the System Administration window, double-click the Stop Alliance icon. you check the integrity of your existing Alliance Access software. See "Checking the Alliance Access Software Files" on page 234 and "The Software Integrity Report" on page 96 for details. Prerequisites for silent relicensing Ensure that you have prepared the following files: a licence file. The licence file must have had the Security Officer passwords obfuscated or encrypted. See "Prepare the Licence File" on page 21. a response file. See "Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal)" on page 22. Prerequisites for Destination and Package Removal Before removing destinations or packages, read the following table and perform the tasks if they apply to your Alliance Access installation.
Licensed options Licensed destinations Required task If the new licensing contains fewer destinations, then the unwanted destinations are removed. Before relicensing, ensure that no unwanted destination is referenced by: configuration parameters operator profiles message templates message file search templates
30 September 2011
77
Licensed options
Required task routing rules
Application interface
A message partner with Session Direction 'To' can only be removed when there are no Exit Points assigned to it. If this is the case, first de-assign the Exit Points and then remove the message partner. 14:DATABASE RECOVERY 16:FILE AUTOMATED Deactivate the database recovery mode. No action required. Print message partners are not affected. Note that automated message partners are changed to manual. Remove all message partners that use TCP/ IP. If not removed, then they are disabled.
Packages
18:CAS TCP-IP
5.2
Interactive Relicensing
Overview Use this procedure to add new packages and modify existing packages in interactive mode. Procedure 1. 2. 3. Log on as Alliance Administrator (all_adm). Open an X-term from the OS Configuration menu in the System Administration window. At the command prompt, type: ./saa-relicense To record the relicensing details for future use, run the relicense command with the record option. See "Record input parameters" on page 88 for more information. 4. The installation application unpacks the files in the installer. The Packages Configuration window appears.
78
Relicensing
This window is used to license the packages and features that your institution has purchased from SWIFT. The pre-selected packages are part of the base licence and include the packages already licensed on your Alliance Access system. 5. Decide how you want to provide licence-related data: Manually: proceed to step 6. From a licence file: click Load from File and browse to the location of the licence file. This is the licence file that you prepared in "Prepare the Licence File" on page 21. Then click 6. 7.
Next
and proceed to step 11.
Select the licensed components, using the items listed in the Packages section of your licensing agreement. Then click Next . The Servers Configuration window appears.
8.
Select the licensed components, using the items listed in the Servers section of your licensing agreement. Then click Next . The Licensed Destinations Configuration window appears, showing the destinations already licensed on your Alliance Access system.
9.
In this window, type: the eight characters of any new live destination(s) listed in the Licensed Destinations section of your licensing agreement the 8-character training destinations. The eighth character is a ''0'' to denote test and training. Although the test and training destination does not appear on your licensing agreement, you must enter it if you want to use it. Each destination must be on a separate line. Once you have typed all your destinations, click Next . The Message Types Configuration window appears, showing the message types already licensed on your Alliance Access system.
30 September 2011
79
10. In this window, type any new message types listed in the Message Types section of your licensing agreement. Each message type must be on a separate line. Once you have typed all your message types, click Next . The Initialisation Password Configuration window appears.
11. Enter the initialisation passwords as follows: The Security Officer who received the INITIALISATION PASSWORD provided in Part 1 of 2 of the licensing agreement must type this password in the First initialisation password field. The Security Officer who received the INITIALISATION PASSWORD provided in Part 2 of 2 of the licensing agreement must type this password in the Second initialisation password field. Note Do not confuse the Initialisation Passwords with the Master Passwords. These are used by the two Security Officers when they first sign on to Alliance Access.
Next
12. Click
.
OK
If the password verification fails, then an error message appears. Click correct input. The Installation Summary window appears.
and enter the
13. Check that the details displayed are correct, and if so, click Install . Once you click is not possible to abort the software relicensing. If the details are not correct, click to return to the previous screen(s) and make your corrections. The software relicensing begins.
Install , it Previous
At the end, the Installation Complete window appears, confirming that the relicensing has completed successfully. 14. Click
Finish
15. Proceed to "Next Steps" on page 81.

Relicensing
5.3
Silent Relicensing
Overview Use this procedure to add new packages and modify existing packages in silent mode. Procedure 1. 2. 3. 4. 5. Log on as Alliance Administrator (all_adm). Open an X-term from the OS Configuration menu in the System Administration window. Close the System Administration window. Enter the following command: cd $ALLIANCE/INA/bin/$ARCH Enter the following command: ./saa-relicense -silent <response file> [-key <value>] Where: <response file> identifies the path to and name of the properties file to be used. For example: /tmp/alliance/silent.properties.relicensing -key <value> specifies the key to use if the response file has encrypted passwords. Viewing the silent relicensing progress or result The installation log file is updated during silent relicensing. You can view the log to see the progress of the relicensing, or the result if the relicensing operation has ended.
5.4
Next Steps
Tasks to perform after relicensing
Licensed Options Licensed Destinations Required task After removing destinations: start the Alliance Access servers and check the Event Journal. Errors may be reported if configuration parameters in the System Management application still point to the removed destination(s) (for example, the Sender Logical Terminal for Alarm Messages). If necessary, redefine these configuration parameters to point to valid licensed destinations. open the Correspondent Information application and add a new destination with the "External" definition if required for the removed destination. if you have scheduled the automatic import of authorisations from these destinations, then you must modify the action to remove these destinations. For details, see the Relationship Management Application User Guide.
30 September 2011
81
Licensed Options
Required task remove the emission profiles, reception profiles, input channels, and output channels related to these destinations.
Application interface
If necessary, redefine message partners using licensed protocols and check that the message partners work properly.
Operator profiles After relicensing, review the operator profiles and remove any functions or permissions related to the down-licensed options, and then approve the operators assigned to these profiles.
82
Removal
Removal
Introduction Should it ever be necessary to remove Alliance Access instances and software from your system (for example, due to an error during installation), the Alliance administrator can remove Alliance Access files using the following procedure. Hosted database If you uninstall an instance of Alliance Access that uses a hosted database, then the Alliance Access database is not removed. In this case, the customer must remove the Alliance Access database from the Oracle database instance where it is installed. A hosted database requires the license, 13:HOSTED DATABASE.
6.1
Before You Remove

Removal checklist 1. Make sure that you have archived and backed up the Event Journal and Message File. 2. Store the backup of the Event Journal and Message File archives outside of the Alliance Access server, as the removal process will remove these directories. 3. Verify that Alliance Access is not running. 4. Verify that the System Administration application is not running.
6.2
Interactive Removal
Procedure 1. 2. 3. Log on as root. Open a Korn shell. If you are working remotely, then export the display to your local machine by typing: export DISPLAY=<IPaddressComputer>:0.0 where <IPaddressComputer> must be replaced by the IP address for the computer where the uninstallation windows will be displayed. 4. At the command prompt, use the following change directory command to locate the directory that contains the Alliance Access application: cd <Alliance installation directory> where <Alliance installation directory> is the name of the directory where Alliance Access is installed. 5. Start the removal process by typing: _uninst/uninstall The Uninstaller window appears. 6. Click
Next
to proceed, or
Cancel
to terminate the process.
30 September 2011
83
A warning prompts you to confirm the removal. 7. Click

Yes
to remove the software, or
No
to terminate the process.
After you click Yes , the removal of the software starts. When the process is complete, a window appears to confirm that the software was removed successfully. 8. 9. Click
Finish
Reboot your system.
6.3
Silent Removal
Prerequisites Before removing Alliance Access, ensure that: you have prepared the requisite response file. For complete removal, the response file must contain system.deinstallOption=base. See "Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal)" on page 22. the Alliance Access servers are stopped. Procedure 1. 2. 3. Log on as root. Open a Korn shell. If you are working remotely, then export the display to your local machine by typing: export DISPLAY=<IPaddressComputer>:0.0 where <IPaddressComputer> must be replaced by the IP address for the computer where the uninstallation windows will be displayed. 4. At the command prompt, use the following change directory command to locate the directory that contains the Alliance Access application: cd <Alliance installation directory> where <Alliance installation directory> is the name of the directory where Alliance Access is installed. 5. Start the removal process by typing: _uninst/uninstall -silent <response file> Where <response file> identifies the path to and name of the properties file to be used. 6. Reboot your system.
84
Patches
Patches
Overview Software fixes are applied in the form of patches. This section explains how to install and remove any software patches that are distributed to you. There are two types of patch: "Cumulative patches", which are sent to all Alliance Access users. Each cumulative patch includes the previous cumulative patch and any optional patches issued after the previous cumulative patch. "Optional (emergency) patches", which are sent to selected Alliance Access users and which affect specific deliverables, such as executables and library files. Optional patches do not include any previous patches. Patches can be downloaded from the Download Centre on www.swift.com.
7.1
Installation
Prerequisites Before installing a patch, you must: 1. read the patch release letter carefully. It describes the scope of the patch and the installation instructions. 2. make sure that the Alliance Access servers are not running. 3. back up all data and software. 4. prepare a response file, if you perform a silent installation. For more information, see "Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal)" on page 22. 5. log on as the user who installed Alliance Access, unless specified otherwise in the release letter. For cumulative patches: A cumulative patch can be installed on a base release, on a previous cumulative patch or on a previous optional patch. A cumulative patch contains all cumulative and optional patches since the base release. For optional (emergency) patches: An optional patch can be installed on a base release, on a previous cumulative patch or on a previous optional patch. Optional patches must be installed in the order of increasing level
30 September 2011
85
number. Removing an optional patch restores the previous version of the affected deliverables. For all patches: Installing a patch replaces the product deliverables of this patch with new, patched versions. The previous, replaced versions of the deliverables are stored by the patch installation software to be restored when the patch is removed.
7.2
Removal
Can the patch be removed? Not all patches can be removed. See the patch release letter for specific information about patch removal. Prerequisites Before removing a patch, you must: 1. read the patch release letter carefully. 2. prepare a response file, if you perform a silent removal. The response file must contain system.deinstallOption=delta. For more information, see "Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal)" on page 22. Note that cumulative patches cannot be removed with this method. 3. log on as the user who installed Alliance Access, unless specified otherwise in the release letter.
86
Additional Information
8
8.1
Non-root Installation or Upgrade
Purpose It is possible to install, patch, or upgrade the Alliance Access software with a non-root user account, such as, all_adm. The non-root user account will own the installation, and become the Alliance administrator. A non-root user logs on using the owner account of Alliance Access and launches the installer to begin the installation. Before you can launch the installation with a non-root user account, you must perform specific pre-installation steps. Overview of a non-root installation or upgrade 1. The root user logs on and prepares Alliance Access for the non-root installation. For more information, see "Prepare for Non-root Installation, Upgrade, Backup, or Removal" on page 20. For example, to install Alliance Access on Oracle Solaris, the root user must perform some preliminary tasks to prepare for the installation by a non-root user. 2. 3. A non-root user logs on using the owner account of Alliance Access and launches the installer to begin the installation. Complete any post-installation or post-upgrade tasks. For more information, see "Additional Tasks after a Non-root Installation" on page 50 or "Additional Tasks after a Non-root Upgrade" on page 75.
Checkhost If a non-root user account runs the installation, then some of the checkhost checks may fail because of the privileges associated to the account. Typically, these will be warnings. The checkhost report will include information about any such failures.
8.2
Silent Mode
Difference between silent operations and interactive operations The prime difference between interactive and silent operations is the way input data is provided. In an interactive procedure, this data is provided through a series of windows. In a silent operation, the data is provided in response files and licence files. For more information, see "Response Files" on page 88. Benefits Silent operations have the following benefits: Do not require firewall administrators to open many ports to support the X-Display necessary for a GUI. This makes it easier and more secure to connect to remote servers or servers behind a firewall. Simplify the repetition of an operation over several instances of the same product, by reusing the response files after editing them.
30 September 2011
87
Allow for the segregation of duties: operations managers can prepare the response files in advance, and the operation can be scripted or carried out by other people of the organisation. Silent operations are as secure as interactive operations. Any passwords can be made unreadable in the response file. For more information, see "Protect the Passwords in the Response File" on page 23. Scope The following Alliance Access operations can be performed silently: Installation Upgrade Removal Patch installation Patch removal Relicensing Viewing the silent operation progress and result The installation log file is updated during a silent operation. You can view the log to see the progress of an operation that is in progress, or the results of an operation that has ended.
8.2.1
Response Files
8.2.1.1 Response Files

Purpose A response file provides the input that is required to complete a silent installation, upgrade, relicensing, patch, or removal procedure. If you plan to perform an installation, upgrade, relicensing, or removal in silent mode, then you must first prepare a response file. Create a response file You can prepare a response file in the following ways: record the input during an interactive procedure, using the -record option. See "Record input parameters" on page 88. modify the sample response file that is provided on the release media. See "Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal)" on page 22. modify an existing response file, which you created previously during installation, upgrade, relicensing, or removal. The release media contains sample response files (with extension .properties). Record input parameters If the -record option is provided as an option during installation, upgrade, relicensing, or removal, then the program will: create a response file in the location specified.
The response file has a name that ends with .properties and the Licence File has a name that ends with .properties.lic. The license file is created in the same location as the response file. For more information, see "Prepare the Licence File" on page 21. If a file of the same name already exists, then it is overwritten. record the parameters as they are input and store them as values of the corresponding system parameters, in the newly created response file. The parameters are stored alphabetically in the response file. It will also store the associated Licence File for the Package and Server licences, Destinations, and MTs. For more information, see "Licence Files for Alliance Access" on page 93. When any password is entered (left and right initialisation passwords, system password), they are encrypted or obfuscated before being stored in the response file. The syntax for the -record option is as in the following example:
saa-install -record <response file> [-key <value>]
Where: <response file> identifies the path to and name of the file to be used to record the parameters. -key <value>, if used, indicates that the passwords in the response file will be encrypted with the provided encryption key. If this parameter is omitted, then the passwords will be obfuscated.
8.2.1.2 Response File Parameters

Purpose This section describes the possible parameters and indicates their applicability in installationrelated operations. Parameters table - notational convention The following syntax applies: M = mandatory parameter C = conditional parameter - = not relevant To make passwords non-readable When launching a silent installation or upgrade, the passwords can be made non-readable in the response file. The parameters that end with .encrypted must be used to provide encrypted or obfuscated values only. For more information, see "Protect the Passwords in the Response File" on page 23.
30 September 2011
89
Response file parameters The following table lists the parameters that must be defined in the response file for Alliance Access:
Patch installation M M M
(2)
Parameter name
system.installOption
Description Install type Use base (installation), or delta (upgrade). Uninstall type Use base (full system removal), or delta (patch removal). A keyword that identifies the product. Use saa (upgrade from Alliance Access), or sar (upgrade from Alliance RMA). Licensing agreement. Must have the value: Agree Installation directory(1)
system.deinstallOption
application.key
Mandatory.Accept.LicensingTe rms application.installLocation
M M
M M
(2)
application.owner.name
Operating system account that is the owner of the resulting instance. For example,
all_adm
The operating system account that is used to install the instance. The name can be preceded by the domain name.
application.ipAddress
IP address of the machine where the instance exists Instance name For example: Access Instance comment Left Initial password. You can only use one of the two parameters in a response file. Right Initial password. You can only use one of the two parameters in a response file. Type of database
C C
C -
application.instanceName
application.instanceComment licence.left.password licence.left.password.encryp ted
C C
C C
licence.right.password licence.right.password.encry pted
database.type
90
Patch removal
Relicensing
Installation
Removal
Upgrade
Patch installation Patch installation -
Parameter name
installer.delta.tmpdir
Description Temporary directory for the database upgrade Delete audit cards Use the value: true - delete audit cards
false - cancel the upgrade
M
(3)
upgrade.deleteAuditCards
(1) For example, <system_drive>:/Alliance/Access (upgrade from Alliance Access) or <system_drive>:/ Alliance/RMA (upgrade from Alliance RMA). (2) In this case, the directory location also specifies the location of the Installation Log file. (3) If there is not enough space in the default directory, then the temporary directory for the database upgrade will be used.
Hosted database - additional installation options When Alliance Access is installed onto an external Oracle instance, then the following additional parameters are required in the response file. These parameters relate to the configuration of the Alliance Access database in the external Oracle instance:
Parameter name
oracle.listener.host
Description Host name or IP address of server which hosts the Oracle instance.
oracle.listener.port
Port number used to connect to C the Oracle instance.(1) If not defined, then the default port number is used: 1521 Oracle service ID of the Oracle instance. The tablespace from the database where tables that hold the Alliance Access configuration data will be created. For example: SAA_DATA The tablespace from the database where tables that hold the Alliance Access events will be created. C C
oracle.sid
database.tablespace.data.name
database.tablespace.event.name
30 September 2011
Patch removal
91
Relicensing
Installation
Removal
Patch removal
Relicensing
Installation
Removal
Upgrade
Patch installation -
Parameter name
Description For example: SAA_JRNL
database.tablespace.message.name
The tablespace from the database where tables that hold theAlliance Access messages will be created. For example: SAA_MESG The tablespace from the database where tables that hold the Alliance Access FileAct payloads will be created. For example: SAA_FILE The tablespace from the database where tables will be created to hold the Alliance Access restored data. For example: SAA_TEMP Database temporary schema owner name Password for the temporary database schema owner. You can only use one of the two parameters in a response file. Database schema owner name(1) Password for the database schema owner. You can only use one of the two parameters in a response file. Database user name to be used by the Alliance Access server to connect to the database
(1)
database.tablespace.file.name
database.tablespace.temp.name
database.temporary.schema.name
C C
database.temporary.schema.passwo rd database.temporary.schema.passwo rd.encrypted
database.schema.name
C C
database.schema.password database.schema.password.encrypt ed
database.user.name
database.user.password database.user.password.encrypted
Password for the database user name. You can only use one of the two parameters in a response file.
(1)
(1) You can use the saa_dbpwdutil command to change the value of this parameter.
92
Patch removal
Relicensing
Installation
Removal
8.3
Licence Files for Alliance Access

Input Licence File During an interactive installation, upgrade, or relicensing of Alliance Access, you can choose to use separate Input Licence Files that contain the Package and Server licences, Destinations, and MTs. This saves you from entering the data manually through the GUI screens. The Input Licence Files can be built as a result of a Secure Channel download. For more information about Secure Channel, see "Secure Channel" on page 11. By using the -record option during an interactive installation, upgrade, or relicensing, you can also create a licence properties file for future use. Sample licence properties files are provided on the Alliance Access product DVD. Usage of Input Licence File You can use the Input Licence File with an associated Response File when installing, upgrading, or relicensing Alliance Access software in silent mode. The Input Licence File provides the data about the Package and Server licences, Destinations, and MTs. For more information about Response Files, see "Response Files" on page 88. Name of Input Licence File If the file name of the Response File is filename.prop, then the file name of the associated Input Licence File must be filename.prop.lic. Both files must be in the same directory. For more information about preparing Licence Files, see "Prepare the Licence File" on page 21.
8.4
Checking Your System Configuration

Uses of the checkhost tool You can use the checkhost tool provided on the release media to analyse the configuration of a computer and produce a report from the results. The tool can provide the following output: a full system analysis report a comparative analysis report: this report compares a host machine against a list of minimum requirements provided in a requirements file. The checkhost tool is integrated in the Alliance Access installer as well and provides an onscreen report of possible discrepancies during the installation.
8.4.1
Launching the checkhost Tool

1. 2. 3. 4. Log on with the root account. Open a Korn shell. Insert the Alliance Access release DVD. Change to the SunOS directory.
93
Procedure
30 September 2011
5.
Locate the checkhost tool by typing: #cd <Mount point CD>/SunOS/checkhost
6.
Launch the checkhost tool.
8.4.2
checkhost Syntax and Examples

checkhost.ksh [-req <pathname of requirements file>] [-rootdir <pathname of a directory>] [-out <pathname of the report file>]
Syntax
where: text wrapped in square brackets [....] represents an optional part of the command text wrapped in angle brackets <....> represents values that you must supply. Options
Use
-req -rootdir
To specify the path to a requirements file the path to a drive or file system against which the checkhost tool must perform a disk space validation. a location for the report file. If not used, then the report is produced in the following default location: /tmp/checkhost.log
-out
Syntax examples a full system analysis report in the default output location, without disk space validation: ./checkhost.ksh a comparative analysis report against the Alliance Access base requirements file, with disk space validation: ./checkhost.ksh -req ../installer/access.dat -rootdir /Alliance/ Access
8.4.3
The Full System Analysis Report

When running the checkhost tool without specification of a requirements file, the following report details are produced:
Information Checkhost command invoked CPU type CPU speed Number of CPUs Memory size(1) MB
Overview
Unit
MHz
94
Information OS version Local hostname Free disk space Installed software Installed patches Network adapters IP addresses File systems Paging space OS language Local time zone DNS server Network options(2)
Unit
MB
MB
(1) Memory size: the checkhost tool prints the value as reported by the operating system. This value may seem inaccurate because of discrepancies that arise from the OS defining 1 Megabyte as 1024 Kilobytes and the CPU vendor defining 1 Megabyte as 1000 Kilobytes. (2) Network options: details about the configuration of the network driver, such as, tcp close wait interval, arp cleanup interval, and so on, are reported.
8.4.4
The Comparative Analysis Report

The comparative report indicates whether a given host machine passes the requirements criteria in a requirements file. Performing a comparative analysis before a software installation ensures that the intended host machine meets the requirements.
Overview
Requirements file The access.dat file is found on the release DVD, in the SunOS/installer folder. It contains the base requirements for installing or upgrading to Alliance Access 7.0.
8.4.5
Error Messages and Warnings

The report produced by the checkhost tool may contain the following error messages: Option not available on this platform. Not all properties can be analysed on all platforms. This message indicates that a specific property cannot be analysed. Unable to retrieve data, command timed out. A built-in timeout prevents the system from hanging while the checkhost tool queries the operating system. The checkhost tool displays this message against each report detail for which property information is not received within the timeout period.
Error messages
30 September 2011
95
Patch level warnings and errors When it is run to check minimum requirements, the OS patch level check can generate Warning errors. This means that the patch is either at a higher or lower level than the requirement, or not present. Some errors are reported as Fatal, which means that it is highly recommended to adjust the patch level to the requirements. Failure to do so can cause unexpected Alliance behaviour. Example
Installed patches ----------------Warning: patch too HIGH : patch 'IMNSearch.bld.DBCS' must be installed with level '2.3.1.15' instead of '2.4.0.0'. Warning: patch too HIGH : patch 'IMNSearch.bld.SBCS' must be installed with level '2.3.1.15' instead of '2.4.0.0'.
8.5
The Software Integrity Report

Software integrity verification The integrity of the Alliance Access software is checked by the Integrity Verification Tool (IVT). The installation log file that is produced during the installation, upgrade, and patch operations provides details about the generation of the software integrity report and the result of the software integrity check. The security parameter, Software Check At Startup, controls whether the Integrity Verification Tool is run each time that Alliance Access is started. You can also generate the Software Integrity report at any time, using the saa_system integrity command. as described in "Checking the Alliance Access Software Files" on page 234. Types of Integrity report The Integrity Verification Tool can produce the following types of integrity reports:
Report Type Full Description A report is produced for all the software files of Alliance Access. When to Generate and Check Before software upgrade (from release 7.0 onwards) Before patch installation Before relicensing Partial A report is produced for specific software files (.exe, .dll) of Alliance Access. Before starting the Alliance Access servers.
Related information System Management Guide, Security Parameters
96
Part B - Configuring for SWIFTNet
Part B
Configuring for SWIFTNet
30 September 2011
97
98
Introduction
Introduction
Purpose This section describes the steps to complete before you can send and receive FIN, InterAct, and FileAct messages. Prerequisites Before performing the steps in this section, the following must be completed: Connectivity setup. For details, see "Check Connectivity" on page 100. SWIFTNet Link 7.0 is installed and configured on the system hosting Alliance Gateway. You have installed or upgraded to Alliance Gateway 7.0. You have set up valid certificates for an Authoriser DN. Tasks related to the management of certificates are performed on Alliance Gateway. For more information, see the Alliance Gateway Operations Guide. You have installed or upgraded to Alliance Access 7.0. For details, see Part C, "System Administration" on page 113. Configuration tasks The main tasks are: Checking connectivity Defining Alliance Access in Alliance Gateway Configuring Alliance Access for FIN messaging Configuring Alliance Access for InterAct and FileAct messaging.
30 September 2011
99
10
10.1
Check Connectivity
Configure SWIFT DNS Servers
Before you can use your connection correctly, ensure that you have access to the SWIFT DNS servers. For details of configuring the SWIFT DNS servers, see the SWIFTNet Link Installation Guide. Note To configure the DNS, you do not need the SNLOwner Account. You can use the root account.
Description
10.2
Confirm Connectivity
You must ensure that the host computer can successfully reach the necessary ports on the SWIFT systems. The ports that must be accessible are defined in the SWIFTNet Network Configuration Tables Guide. Before proceeding with the SWIFTNet Link installation, confirm your Network Connectivity by executing the checkip program, as explained in the SWIFTNet Link Installation Guide, "Checking the TCP/IP Network Configuration". This program contacts all necessary ports and checks whether they are open and can be reached. If this connectivity test is not successful, then the next step (SWIFTNet Link installation) will fail.
Description
100
Defining Alliance Access in Alliance Gateway
11

Overview This section explains how to: set up Alliance Access as a message partner in Alliance Gateway, with Relaxed SNL Format selected define Alliance Access as an endpoint on Alliance Gateway. These steps are similar whether you are configuring for FIN, InterAct, or FileAct messaging. Only the message partner and endpoint names differ.
11.1
Guidelines for Names

When Alliance Access connects to an Alliance Gateway system, it must provide a unique message partner name. The Alliance Access message partner name is derived from its instance name. Alliance Access creates the message partner name with the characters fin_ (for FIN messaging), or sni_ (for InterAct and FileAct messaging) followed by a normalised Alliance Access instance name. A normalised Alliance Access instance name is the Alliance Access instance name, reduced to lower case with underscores removed and truncated to 10 characters. The name can have a maximum of 14 characters. For example, if the Alliance Access instance name is SAA_Rel_70, then the message partner name must be fin_saarel70 (for FIN messaging), or sni_saarel70 (for InterAct and FileAct messaging). Note If you have multiple Alliance Access systems connecting to SWIFTNet through Alliance Gateway, then ensure that each system has a unique instance name.
Message partner names
Endpoint names When Alliance Access connects to SWIFTNet, it must provide an Endpoint name. Alliance Access always uses an Endpoint name that is identical to its message partner name.
11.2
FIN Messaging
11.2.1 Setting Up a Message Partner in Alliance Gateway

Overview You must configure your Alliance Access instance as a message partner in Alliance Gateway. This must be completed for each Alliance Access system that connects to this Alliance Gateway system.
30 September 2011
101
Note
If you have performed a fresh installation of Alliance Gateway 7.0 on your system, then a default message partner called fin_relaxed is provided. This message partner has the correct settings for connection between Alliance Access and Alliance Gateway. You can use the settings of this message partner as an example to create your fin_<your_instance_name> message partner. You must select Relaxed SNL Format as default message format for emission and reception.
To set up a message partner for FIN messaging Add a new message partner as described in the Alliance Gateway Operations Guide, "Creating a Client/Server Message Partner", with the following details: 1. For the message partner and SWIFTNet Link Endpoint, enter a Name. Enter a unique message partner name based on the Alliance Access instance name. See "Guidelines for Names" on page 101. In the Type field, select ClientServer. In the Host Adapter field, select Remote API Host Adapter. In the Default Message Format for Emission (from Message Partner) field, select Relaxed SNL Format. In the Supported Message Formats section, select Relaxed SNL Format. Move it from the Available to the Selected column by highlighting it and clicking the transfer icon. In the Additional Processing section, select Remote API Host Adapter and Local Authentication, then define the local authentication keys. Add the Certificates for Relaxed Mode to the message partner details by clicking Save the message partner details. Finally, enable the message partner. See the Alliance Gateway Operations Guide, "Enabling and Disabling a Message Partner".
Add
2. 3. 4. 5. 6. 7. 8. 9.
11.2.2 Defining Alliance Access as an Endpoint on Alliance Gateway

Overview When data arrives from SWIFTNet into Alliance Gateway, it has the Endpoint name embedded in the data. Alliance Gateway must know how to route this data to the correct Alliance Access system. This section explains how to configure Alliance Gateway with this routing information. Note Before you define the Endpoint, you must have defined the message partner to be used by the Endpoint. If you have performed a fresh installation of Alliance Gateway 7.0 on your system, then a default Endpoint called fin_relaxed is provided. You can use the settings of this endpoint as an example to create your fin_<your_instance_name> endpoint.
102
To define an Endpoint Add a new Endpoint as described in the Alliance Gateway Operations Guide, "Adding an Endpoint", with the following details: 1. In the Routing tab: in the Name field, enter the message partner name that you defined in "Setting Up a Message Partner in Alliance Gateway" on page 101. in the SNL Endpoint field, select Equals (=) in the Relation subfield and the message partner name that you defined in "Setting Up a Message Partner in Alliance Gateway" on page 101, in the second subfield. in the Traffic Type field, select All. 2. In the Destination tab: in the Interface field, select Application Interface. in the Application field, select the message partner name that you defined in "Setting Up a Message Partner in Alliance Gateway" on page 103. from the Mode option buttons, select Relaxed. from the Cryptographic protocol option buttons, select Advanced. the Namespace Declarations check box must not be selected. in the Error Code field, select Old. 3. 4. Save this configuration. Finally, enable the Endpoint. See the Alliance Gateway Operations Guide, "Enabling and Disabling an Endpoint".
11.3
InterAct and FileAct Messaging
11.3.1 Setting Up a Message Partner in Alliance Gateway

Overview For InterAct and FileAct messaging, you must also configure Alliance Access as an additional message partner in Alliance Gateway. This must be completed for each Alliance Access system that connects to this Alliance Gateway system. Note The message partner definition for the SWIFTNet Interface component (for InterAct and FileAct messaging) also follows a defined naming convention. The message partner name is also derived from the Alliance Access instance name, but with sni_ as its prefix, that is, sni_<your_instance_name>. You must select Relaxed SNL Format as default message format for emission and reception.
30 September 2011
103
To set up a message partner for InterAct and FileAct messaging Add a new message partner as described in the Alliance Gateway Operations Guide, "Creating a Client/Server Message Partner", with the following details: 1. For the message partner and SWIFTNet Link Endpoint, enter a Name. Enter a unique message partner name based on the Alliance Access instance name. See "Guidelines for Names" on page 101. In the Type field, select ClientServer. In the Host Adapter field, select Remote API Host Adapter. For the Default Message Format for Emission (from Message Partner) field, select Relaxed SNL Format. In the Supported Message Formats section, select Relaxed SNL Format. Move it from the Available to the Selected column by highlighting it and clicking the transfer icon. In the Additional Processing section, select Remote API Host Adapter and Local Authentication, then define the Local Authentication keys. Add the Certificates for Relaxed Mode to the message partner details by clicking Save the message partner details. Finally, enable the message partner. See the Alliance Gateway Operations Guide, "Enabling and Disabling a Message Partner".
Add
2. 3. 4. 5. 6. 7. 8. 9.
11.3.2 Defining Alliance Access as an Endpoint on Alliance Gateway

Overview When data arrives from SWIFTNet into Alliance Gateway, it has the Endpoint name embedded in the data. Alliance Gateway must know how to route this data to the correct Alliance Access. This section explains how to configure Alliance Gateway with this routing information. Note Before you define the Endpoint, you must have defined the message partner to be used by the Endpoint.
To define an Endpoint Add a new Endpoint as described in the Alliance Gateway Operations Guide, "Adding an Endpoint", with the following details: 1. In the Routing tab: in the Name field, enter the message partner name that you defined in "Setting Up a Message Partner in Alliance Gateway" on page 103. in the SNL Endpoint field, select Equals (=) in the Relation subfield and the message partner name that you defined in "Setting Up a Message Partner in Alliance Gateway" on page 103 in the second subfield. in the Traffic Type field, select All.
104
2.
In the Destination tab: in the Interface field, select Application Interface. in the Application field, select the message partner name that you defined in "Defining Alliance Access as an Endpoint on Alliance Gateway" on page 102. from the Mode option buttons, select Relaxed. from the Cryptographic protocol option buttons, select Advanced. the Namespace Declarations check box must not be selected. in the Error Code field, select Old.
3. 4.
Save this configuration. Finally, enable the Endpoint. See the Alliance Gateway Operations Guide, "Enabling and Disabling an Endpoint".
11.4
Data Encryption/Gateway Authentication between Alliance Access and Alliance Gateway

If you have decided to use Data Encryption/Gateway Authentication between Alliance Access and Alliance Gateway, then perform these steps: On Alliance Gateway, create a Private Key and Certificate. See the Alliance Gateway Operations Guide, "Creating a Private Key and Certificates". On Alliance Access, configure the SSL settings on Remote API. See the Alliance Gateway Remote API Operations Guide, "Configuring SSL Settings on RA".
Description
30 September 2011
105
12
Configuring Alliance Access for FIN Messaging

Overview To configure Alliance Access to send and receive FIN messages, you must: define a SWIFTNet connection assign a SWIFTNet connection to a Logical Terminal send and receive a Test MT message set up your access to the SWIFTNet FIN Test service (only if you are a vendor). Configuration through the Alliance Web Platform You can configure Alliance Access for FIN messaging using the Alliance Access Configuration package on the Alliance Web Platform. For more information, see the section about configuration for SWIFNet Messaging Services in the Configuration Guide. To configure the SWIFTNet FIN Test Service (Vendors only), see . Note When a FIN message is sent from Alliance Access over SWIFTNet, it is enveloped in an InterAct message. In addition, relationship management authorisations for the live RMA service are also exchanged as InterAct messages over SWIFTNet. An Authoriser DN signs the InterAct messages that are sent over SWIFTNet. Therefore, the Logical Terminal that sends the message must be mapped to an Authoriser DN, as follows:
Role to assign to Authoriser DN the fin role for the swift.fin service. In other words, such an Authoriser DN is a certified FIN User. Associated Alliance Gateway message partner
fin_<instance>
12.1
Defining a SWIFTNet Connection

You define a SWIFTNet connection from the SWIFTNet Support application. The default SWIFTNet connection is created with the name SAG with pre-defined settings. For detailed information about maintaining SWIFTNet connections, see "Defining and Modifying SWIFTNet Connections" in the System Management Guide.
Overview
106
Configuring Alliance Access for FIN Messaging
Permissions By default, only the security officers, and the R7.0_Supervisor and R7.0_Superkey operator profiles have the SWIFTNet Support application permissions. Assign these permissions to other operators as needed. When assigning permissions, ensure that Connection Handling in the "SNL Handling" function is set to Yes. If you use Local Authentication between Alliance Gateway and Alliance Access, then you can assign the two parts of the Local Authentication Key in the "SNL Handling" function to a single operator, or separately to two operators. By default, the Security Officers (LSO and RSO) only have one part of the Local Authentication Key in the "SNL Handling" function assigned. For more information about assigning permissions, see "Managing Alliance Access Security" in the System Management Guide.
12.2
Assigning a SWIFTNet Connection to a Logical Terminal

For information about assigning a SWIFTNet connection to a Logical Terminal, see "Assigning SWIFTNet Connections to a Logical Terminal" in the System Management Guide.
Overview
12.3
Sending and Receiving a Test MT Message

1. 2. 3. 4. Ensure that the Alliance Access servers are running in Operational mode. Sign on through Alliance Workstation as an operator with message processing entitlements. Open the Message Creation application. Create an MT 999 (free format message) to be sent from your Test and Training Destination (which is assigned to SWIFTNet) addressed back to your Test and Training Destination. Sender and Destination fields in the message must be the same. Your Test and Training Destination is the one that ends in 0. Route the message to the _SI_to_SWIFT queue. With the Test and Training logical terminal, log in to SWIFT and select FIN so that the queued message can be sent and received. For instructions, see the Daily Operations Guide. 7. Check the status of the Test and Training logical terminal. The logical terminal must be selected and have one N (normal) message queued for transmission. For instructions, see the Daily Operations Guide. 8. Search for the MT 999 in the Message File. For instructions, see the Daily Operations Guide.
Procedure
5. 6.
30 September 2011
107
12.4
Access to the SWIFTNet FIN Test Service (Vendors only)

To connect to the SWIFTNet FIN test-infrastructure (FIN Vendor Testbed (VTB) through the SWIFTNet Integration Testbed (ITB)), you must access the swift.fin!x service. A system variable (SERVICE_NAME) must be set with the value swift.fin!x. Important This section applies only to SWIFT, its partners, and vendors (your BIC must start with PT).
Important
Procedure 1. 2. 3. Log on to UNIX as Alliance administrator. Using vi or another text editor, open the file $HOME/.swa.$ALLIANCE_INSTANCE.rc. Add the following line: export SERVICE_NAME=swift.fin!x 4. Close and save the file. The variable is only taken into account after closing and re-opening the System Administration window. Note If the servers are running while setting the variable, then you must do the following: Stop the Alliance Access servers and the bootstrap. Close the System Administration window, and open it again. Start the Alliance Access bootstrap and the servers.
108
Configuring Alliance Access for InterAct and FileAct Messaging
13

Overview To configure Alliance Access to send and receive InterAct and FileAct messages, you must: define a SWIFTNet connection install Application Service Profiles configure SWIFTNet emission and reception profiles send and receive an InterAct or a FileAct message. Configuration through the Alliance Web Platform You can configure Alliance Access for InterAct and FIN messaging using the Alliance Access Configuration package on the Alliance Web Platform. For more information, see the section about configuration for SWIFNet Messaging Services in the Configuration Guide. Note When an InterAct of FileAct message is sent from Alliance Access over SWIFTNet, it is enveloped in an InterAct message. In addition, relationship management authorisations for the live RMA service are also exchanged as InterAct messages over SWIFTNet. An Authoriser DN signs the InterAct messages that are sent over SWIFTNet. Therefore, the emission profile that sends the message must be mapped to an Authoriser DN, as follows:
Role to assign to Authoriser DN the appropriate role for the SWIFTNet Business service Associated Alliance Gateway message partner
sni_<instance>
13.1
Defining a SWIFTNet Connection

You must define a SWIFTNet connection to assign to the SWIFTNet emission and reception profiles. For more information, see "Defining a SWIFTNet Connection" on page 106.
Overview
13.2
Installing Application Service Profiles

You must install the latest Application Service Profiles on Alliance Access to send and receive traffic correctly for InterAct or FileAct services. For more information, see ''Installing Application Service Profiles" in the System Management Guide, or the command, "saa_manageasp" on page 292.
Overview
30 September 2011
109
13.3
Configuring SWIFTNet Emission and Reception Profiles

To exchange messages through SWIFTNet, you must define, enable, and activate SWIFTNet emission and reception profiles for InterAct and FileAct messaging, and also for the RMA service. You perform these tasks from the SWIFTNet Interface application. During the installation or upgrade of Alliance Access, an emission profile and a reception profile is created automatically for each live licensed BIC8 for the live RMA service.
Purpose
Permissions By default, only the R7.0_Supervisor and R7.0_Superkey operator profiles have the permissions to manage emission and reception profiles in the SWIFTNet Interface application. You can assign these permissions to other operators, if necessary. To configure SWIFTNet profiles 1. 2. 3. Configure an emission profile for each licensed BIC8. See "Defining Emission Profiles" in the System Management Guide. Configure a reception profile for each licensed BIC8. See "Defining Reception Profiles" in the System Management Guide. Assign a SWIFTNet connection to each emission profile and reception profile that you created. See "Assigning SWIFTNet Connections to SWIFTNet Profiles" in the System Management Guide. If required, assign an input channel to an emission profile. For more information, see "Set Up Input Channels" in the System Management Guide. Enable and activate each emission and reception profile. See "Enabling and Activating SWIFTNet Profiles" in the System Management Guide. Enabling the profile makes it ready for use, and activating it starts message traffic.
4. 5.
13.4
Note
Sending and Receiving an InterAct or a FileAct Message

This procedure applies both for InterAct and FileAct messages, unless specified otherwise.
Procedure 1. Do either of the following: Create an MX message from Alliance Messenger on Alliance Web Platform. For more information, see the Alliance Messenger Administration and Operations Guide. Create an MX message from your back-office application and send it to your Alliance Access system. 2. Route the message to the _SI_to_SWIFTNet queue.
110
3. 4. 5. 6.
Ensure that the Alliance Access servers are running in Operational mode. Sign on through Alliance Workstation. Open the SWIFTNet Interface application. Ensure that an emission profile for the SWIFTNet business service to be used has been created and set up, as well as a reception profile to receive MX messages from the same SWIFTNet business service. For details, see "Configuring SWIFTNet Emission and Reception Profiles" on page 110. Enable and activate the SWIFTNet emission and reception profiles so that the queued MX message can be processed. For details, see "Configuring SWIFTNet Emission and Reception Profiles" on page 110. Search for the MX message in the Alliance Access Message File application, or from Alliance Messenger on Alliance Web Platform. For more information, see the Alliance Messenger Administration and Operations Guide.
7.
8.
30 September 2011
111
112
Part C - System Administration
Part C
System Administration
30 September 2011
113
114
Introduction to System Administration
14

Overview To ensure that your Alliance Access installation works efficiently, and in a secure manner, various "system administration" tasks must be carried out. Some of these tasks (such as checking that the servers are running) must be performed daily, while others (such as renaming an instance) are performed as and when required. Access to the role of Alliance administrator is gained by logging in with the Alliance Administrator account. The name of this account is specified during the installation or upgrade of Alliance Access, and is mapped to the system variable $ALLIANCE_ADMIN. Alliance Access administration tasks may be performed in the following ways: by using the facilities of the System Management application of Alliance Access to configure various operational parameters of Alliance Access, and to perform backups of the Alliance Access database and archives. by using the Alliance command line tools available in $ALLIANCE/bin (such as saa_system and saa_dbrestore) by using UNIX commands, together with dedicated scripts, to interact directly with the UNIX operating system. It is primarily the role of the Alliance administrator to perform these tasks. Normally, the Alliance administrator does not have access to the operational functions of Alliance Access - that is not defined as an operator able to sign on to Alliance Access. Tasks that must be performed within Alliance Access (typically using the System Management application) are, therefore, assumed to be carried out by a supervisor or senior operator of Alliance Access. This guide defines the tasks that are performed by the Alliance administrator, when logged on to UNIX using the Alliance Administrator account. The use of the System Administration application, therefore, is restricted to those with knowledge of the password for the Alliance Administrator account. This password must be carefully protected, and regularly updated. For some organisations, the Alliance administrator may also fulfil the role of 'supervisor' or 'operator' - that may also have operational responsibilities. If so, that person must also be defined as an Alliance Access operator and use their separate Alliance Access operator nickname and password for access to the operational facilities within Alliance Access. For details about the facilities provided within the System Management application, see the System Management Guide.
14.1
Overview of the System Administration Application

Alliance Access provides a dedicated application which is used exclusively by the Alliance administrator.
Introduction
30 September 2011
115
14.1.1 Selecting an Instance

Overview Whenever you log into Solaris as Alliance Administrator and enter the relevant password, the system checks whether there is more than one instance of Alliance Access installed. If there is, then the Alliance Application Instance Selection window appears.
For a description of this window, see "Alliance Application Instance Selection Window" on page 117. To select an instance: 1. 2. 3. Log into Solaris as Alliance Administrator and enter the relevant password. The Alliance Application Instance Selection window appears. Select an instance by selecting it, and then select Open from the Instance menu. The System Administration application is started automatically and the Alliance System Administration window appears.
For a description of this window, see "Alliance System Administration Window" on page 118.
116
14.1.2 Alliance Application Instance Selection Window

Description The Alliance Application Instance Selection window enables you to select an Alliance Access instance installed on your system. Example
Field descriptions Name The name of the instance given at installation time. Product The product type (for example, INTERFACE). Comment A user-defined comment field provided when the name of the instance is given.
14.1.3 The System Administration Application

Description Access to the UNIX shell is also available from the Xterm command of the OS Configuration menu in the Alliance System Administration window. This facility enables you to enter UNIX commands and run admin scripts, if required. Note When you have logged into Solaris as Alliance Administrator, the Xterm command provides a shell window with administrator permissions. If you have simply switched to the administrator account (using su - <admin account name>) from your own, or another account, then you only have the permissions set for your, or the other, account.
Many of the administrative tasks you are able to perform, may only be carried out when the Alliance Access servers are not running. If you select such a command while the servers are running, then a message appears to remind you to stop the Alliance Access servers. For a list of the commands available using the System Administration application, see "Alliance System Administration Window" on page 118. The detailed use of each command is given later, within the appropriate section (for example, "General System Maintenance").
30 September 2011
117
14.1.4 Alliance System Administration Window

Description The various functions available within the System Administration application are logically grouped on four pull-down menus (File, Instance, OS Configuration and Alliance), which appear at the top of the Alliance System Administration window, as described below. The lower part of the window provides a scrolling text area in which the results of your commands, and confirmations of the actions taken, are reported. As a general rule, when specific actions are completed, a status like the following is reported in the lower part of the window: Completed, Status = 0 the action has completed successfully Completed, Status = 1 the action was NOT completed successfully If Completed, Status = 1 appears, scroll back the text in the window for indications as to the likely cause of the problem. In addition, the Alliance Event Journal may be used to investigate possible problems. The lower part of the window is cleared automatically after every 20 K of characters of status information has accumulated. 20 K is the default value which can be altered by the Alliance administrator using the UNIX environment variable INA_MAX_STATUS_WIN_SIZE. For example, export INA_MAX_STATUS_WIN_SIZE=20000 Example
Menu descriptions File The File menu provides access to commands related to your Alliance software: Report. See "General Troubleshooting" on page 246for information. Print Screen. See "General System Maintenance" on page 123 for information. Clear. See "General System Maintenance" on page 123 for information. Exit. See "General System Maintenance" on page 123 for information.
118
Instance The Instance menu contains commands which you can use to display and manipulate the attributes of all instances installed on the system. Current Instance. See "General System Maintenance" on page 123 for information. List Instances. See "General System Maintenance" on page 123 for information. OS Configuration The OS Configuration menu provides access to the UNIX shell, which enables you to enter UNIX commands and run admin scripts, if required. See "General System Maintenance" on page 123 for information. Alliance The Alliance menu provides access to commands related to using the Alliance servers, managing Alliance data and for troubleshooting: Start Alliance Servers. See "Managing the Alliance Access Servers" on page 131 for information. Stop Alliance Servers. See "Managing the Alliance Access Servers" on page 131 for information. JOURNAL_Query. See "General Troubleshooting" on page 246for information.
14.2
System Management Procedures
14.2.1 Regular Procedures

Overview The following regular system management procedures are used to maintain Alliance Access: starting and stopping the servers, as required checking that the Alliance Access servers are running normally taking regular backups of the Alliance Access database. The Alliance Access servers can be stopped and started from the following applications: System Management application: stop, or stop and restart Alliance Access (servers). System Administration application: stop or start the servers. UNIX command line (for example, using an Xterm): stop the servers using the saa_system stop script. Start the servers using the saa_system start script.
14.2.2 Ad-hoc Procedures

Overview The following procedures must be carried out by the Alliance administrator, as and when required: Manage the configuration of Solaris software for Alliance Access
Check the security of Alliance Access software Recover Alliance Access database in the event of disk problems Reconfigure external connections when necessary Install software upgrades, as required Load and install software patches Kill Alliance Access processes when problems arise Provide general troubleshooting assistance
14.3
The Alliance Release Tree

The Alliance Access software is made of major functional entities called components. These components recognise the client/server architecture of Alliance Access (using remote procedure calls between server and client processes) and consist therefore of the following two types: The Service Component (which refers to the server in the architectural model) is a collection of servers providing services to applications. The Application Component (which refers to the client in the architectural model) is a collection of applications requesting services from servers. The two different types of components are identified by the last character of the component ID: 'S' for Service and 'A' for Application. The service components are:
BSS FSS INS MAS MXS RMS SIS SNIS SNSS SSS TRS WSS XSS Base Service File Support Services Installation Service Messenger Adapter Service Message Exchange Service Relationship Management Service SWIFT Interface Service SWIFTNet Interface Service SWIFTNet Support Service SWIFT Support Service Traffic Reconciliation Services Web Service Services Standards XML Support Services
Alliance Access software components
The application components are:

BSA INA Base Application Installation
120
MPA MXA RMA SIA SNIA SNSA SSA
SWIFT Message Preparation Message Exchange Relationship Management SWIFT Interface SWIFTNet Interface SWIFTNet Support SWIFT Support
All components have the same directory tree structure except for a slight difference between the two component types. The following describes the Alliance release tree for service and application components. The software release directory structure is as follows:
$ALLIANCE Any Service Component: bin/SunOS Root directory for Alliance Access BSS, INS, MAS, MXS, RMS, SIS, SNIS, SNSS, SSS, TRS, XSS Executables Contains Alliance Access executables and command scripts Comment
lib/SunOS data/SunOS nls/SunOS install log Any Application Component: bin/SunOS
Run-time libraries Data, configuration files, parameters files for printing Language-dependent catalogues Installation scripts Error and log files BSA, INA, MPA, MXA, RMA,SIA, SNIA, SNSA, SSA Executables Contains Alliance Access executables and command scripts
lib/SunOS data/SunOS nls/SunOS install
Run-time libraries Data and configuration files Language-dependent catalogues Installation scripts
/usr/swa/insts /usr/tmp/alliance _uninst usrdata data/BIC
Instances registration file Error and log files Uninstallation scripts User data
Not in release tree, but an important directory
Dedicated folder for user data Directory for full BIC data files
30 September 2011
121
$ALLIANCE data/UpdateBIC
Root directory for Alliance Access
Comment Directory for partial BIC data files
Core dumps, resulting from process crashes, are located in the bin/SunOS directory of the relevant application. These files must be copied to the safestore-directory for investigation. The following command displays existing core files:
find / -name core -exec ls -al {} \;
122
General System Maintenance
15

Introduction Alliance Access provides a range of facilities to assist the Alliance administrator with system maintenance activities and with general troubleshooting. All the facilities described in this section are available to the Alliance administrator when logged on as Alliance Administrator and using the System Administration application. Some facilities particularly those which interact with the operating system, or with the Alliance Access database - can only be used when the Alliance Access servers are not running. To access any of the commands described in this section: 1. Log on to the Alliance Administrator account, using the current password. The main window of the System Administration application will appear. 2. If the command you require can only be used when the servers are not running, then first select the Stop Alliance Servers command from the Alliance menu and wait for the servers to stop. 3. Select the required command from the relevant menu. Some commands simply display information in the scrolling text area at the bottom of the main window. For other commands, a window will appear, allowing you to enter relevant data. When you click OK within that window, the selected command is run, using the data entered. Some of the commands available within the System Administration application are the subject of a broader discussion and are described, instead, in the following sections: "Managing the Alliance Access Servers" on page 131 "The "Start Alliance Servers" Command" on page 131 "The "Stop Alliance Servers" Command" on page 136 "General Troubleshooting" on page 246 "The Alliance Configuration Report" on page 246 "The JOURNAL_query Facility" on page 248 All other administrative commands are described in this section. Tip You can use the saa_system integrity command to check the integrity of the Alliance Access software. For more information, see "Checking the Alliance Access Software Files" on page 234.
15.1
System Management Commands

The following commands can be used at any time for system management.
Overview
30 September 2011
123
15.1.1 The Clear Command

Description The Clear command from the File menu allows you to clear the scrolling text area in the lower part of the main window of the System Administration application. Use this command to delete any text currently displayed in the main window. Once cleared, this text cannot be recovered.
15.1.2 The Print Screen Command

Description The Print Screen command from the File menu allows you to print the current window to a file or a printer. When Print Screen is selected, the Print Screen window appears.
To send the output to a file, select File in the Output To field and enter the file name in the Filename field. Click OK to send the output to the file specified. To send the output to a printer, select Printer in the Output To field and then select a destination printer from the Printer field. Click OK to send the output to the printer. If no printers have been defined, then the Printer option is not available.
15.1.3 The Exit Command

Description The Exit command from the File menu allows you to quit the System Administration application. This command automatically logs you (Alliance Administrator) off from the Solaris operating system. Upon quitting, you may be prompted for a reboot of the system if certain changes have been made to the operating system configuration. Note Refer to the Xterm command if the reason you want to quit the System Administration application is to access the UNIX shell.
15.1.4 Current Instance

Description The Current Instance command from the Instance menu allows you to display the name of the Alliance Access instance that you are currently using.
124
15.1.5 List Instances

Description The List Instances command from the Instance menu allows you to display a list of all the Alliance Access instances currently installed on your system.
15.1.6 The Xterm Command

Description The Xterm command from the OS Configuration menu allows you to interact directly with the operating system by entering UNIX commands from within the System Administration application. When you select this command, a new Xterm shell window opens. When the UNIX prompt ($) appears, you may enter UNIX commands to run the dedicated scripts described in this guide, or perform other administrative tasks that require direct interaction with UNIX (for example, check the contents of a directory, determine which processes are currently running, and so on). The response to such commands normally appears in the same window. To cancel and dismiss the Xterm shell, enter the exit command. Note When you have logged into Solaris as Alliance Administrator, the Xterm command will provide an Xterm shell window with administrator permissions. When you switch to the administrator account (using su - <admin account name>) from your own account, or another account, you will only have the permissions set for the original account.
If you want to have administrator permissions, then type the following commands in the Xterm window:
$ id $ su - <admin account name> $ ^D # check your user id # supply a password # EOF character to stop another # SAA application appearing
15.2
Essential System Maintenance

For Alliance Access to function in an efficient and trouble-free manner, the Alliance Administrator is required to perform certain essential tasks.
Introduction
30 September 2011
125
15.2.1 At the Start of the Business Day

Description Before Alliance Access and Alliance Workstation operators can sign on for normal operations, the Alliance Administrator should carry out the tasks that follow.
Task Start the Alliance Access servers Tip From the Alliance menu (in the System Administration application).
15.2.2 During the Business Day

Description The Alliance Administrator should carry out these tasks during the day:
Task If you have to investigate a problem, use the Event Journal application to scrutinise system events and alarms, and to view the audit trail of interactive requests and responses. Use the Message File application to view the contents of messages transferred and their associated transmission history. React to any unknown alarms, for example "Disk Space Too Low". Tip See the System Management Guide
When you see this alarm, the Alliance Access system is about to shut down. Use the Monitoring application or the UNIX command df to check the disk space parameters.
15.2.3 At the End of the Business Day

Description The Systems Administrator is responsible for the tasks that follow at the end of the day.
Task Search the Event Journal for any untreated alarms and for Security Events. Treat as appropriate. Tip See the Daily Operations Guide
Archive and back up (with remove option) See the Daily Operations Guide messages and events to free disk space for the database. These tasks can be automated using the schedule facility. Free space can be checked using the Monitoring application (System Resources - Disk Space).
126
15.2.4 At the End of the Week

Description The Systems Administrator is responsible for the tasks that follow at regular intervals (for example, at the end of each week). Note Only messages and events which are from the previous day can be archived. When you encounter messages which still appear as live (from the previous day) investigate these using the Message File application.
Tip See the Daily Operations Guide
Task If you are not archiving on a daily basis, use the Event Journal application to archive the Event Journal. This can be automated (for example, weekly) using the schedule facility. Use the Message File application to archive the Message File. This can be automated using the schedule facility.
See the Daily Operations Guide
When appropriate, stop the Alliance Access From the Alliance menu of the System servers. This can be automated using the schedule Administration application, the System facility. Management application, or through the UNIX command line with the script saa_system stop. Use the System Management application to: back up and remove the Event Journal archives back up and remove the Message archives back up the Alliance Access database. See the Daily Operations Guide
30 September 2011
127
16
16.1
Managing UNIX Accounts

Alliance Administrator Account
Alliance Access provides and recognises only one UNIX user: a trusted administrator, responsible for system management functions outside of Alliance Access (for example, installation, housekeeping, running servers). This person is referred to as the 'Alliance administrator' who operates using the dedicated UNIX account name given to the Alliance administrator. The administrative functions described in this guide, available through the System Administration application, are used exclusively by the Alliance administrator, when logged on as such. In fact, as soon as the Alliance administrator logs on to UNIX, the Alliance System Administration application is started automatically. The Alliance administrator user is set up during installation.
Overview
16.2
Security Considerations
The security of the Alliance Access software and database is ensured by the file permissions assigned at installation time. This makes sure that: All files in the release tree can only be accessed from the Alliance Administrator account Most of the other executables can only be run from the Alliance Administrator account, with the result that only the Alliance administrator can start the Alliance Access servers. Privileged operators may also stop or restart the system, using dedicated functions within the System Management application. Some executables (such as the saa_monitor or saa_manage tools) can be run by other UNIX accounts, but require specific Alliance Access credentials. The files in the database can only be updated by the Alliance administrator or by the Alliance Access servers at run time. The following table lists the ownership and file permissions used for Alliance Access:
File Type data files executables all_adm all_adm Owner Group alliance, or the default primary group alliance, or the default primary group File Permission rw- --- --rwx r-x r-x
Overview
128
Managing UNIX Accounts
16.3
The alliance_init File

From the definition of the environment variables $ALLIANCE and $ALLIANCE_DB, the installation script creates a file called alliance_init which is stored in the /usr/swa directory. This data file contains parameters which have been properly initialised to run Alliance Access, and is used every time an Alliance Access script is run.
Usage: alliance_init [-a] [-i <instance>] [-x] {-s | -S | -- -e <cmd> | <cmd> [<args>]}
Description
where:
-a -i -x -s -S -e <cmd> <args>
specifies that the user is Alliance administrator specifies the instance name specifies use X mode for instance selection specifies to only set the environment variables outputs to standard output the exports of environment variables specifies an external command, for example ksh is an Alliance Access command, for example start_server are optional arguments to the command.
16.4
Workstation IP Address Checking

The IP addresses of the remote machines that are permitted to connect to your Alliance Access server as Alliance workstations are configured using the saa_configconnection tool. For more information, see "saa_configconnection" on page 230. To enable the change, you have to stop and restart the Alliance Access servers.
Description
16.5
The Instance Registration File

The details of all installed instances of Alliance Access are stored in a system file located at /usr/swa/insts. For each installed instance of Alliance Access, this file contains the values for the: Alliance Access software release tree version release number type of Alliance product (for example, INTERFACE) name of the Alliance Administrator instance name location of the Alliance Access database
Overview
30 September 2011
129
instance comment.
130
Managing the Alliance Access Servers
17

Overview This section describes the management of the Alliance Access servers, using functions which the Alliance administrator must perform using either the commands available from the System Administration application or UNIX command line scripts. Note These command scripts require the correct environment to be set, which is automatically done when logging on as all_adm. However, if you want to carry out administrator functions while logged on as "root", then you must run the script using the following syntax:
. /usr/swa/alliance_init -s [-i <instance_name>]
Tip
At the end of a normal operational day, a supervisor (or senior operator) can use the Stop Alliance command in the System Management application to stop the servers.
17.1
Starting the Alliance Access Servers

This section describes how to start the Alliance Access servers using either: the System Administration application and the Start Alliance Servers command saa_system start housekeeping|operational command
Overview
17.1.1 The "Start Alliance Servers" Command

17.1.1.1 Running the "Start Alliance Servers" Command
Description The Start Alliance Servers command, from the System Administration application, is used (only by the Alliance Administrator) to start the Alliance Access servers (for example, at the start of the day or after system maintenance). Note The Alliance Access servers MUST be running before any client application (such as the Support application) can be started by an Alliance Access user. Therefore, no operator can sign on to Alliance Access until the servers are running.
To start the Alliance Access servers: 1. 2. Log into UNIX as Alliance Administrator. If more than one instance is installed on your system, then the Alliance Application Instance Selection window appears. Select the required instance from the list pane. The main window of the System Administration application appears. Select Start Alliance Servers from the Alliance pull-down menu.
3.
30 September 2011
131
If the servers are not already running, then a shortcut menu appears prompting the administrator to select a start mode for the servers: Operational, to perform operational tasks. Housekeeping, to perform maintenance and security tasks. 4. 5. 6. Select Extended Reporting, if required. For more information, see "Extended Reporting at Server Startup" on page 133. If there is no active routing schema, then the servers cannot be started in Operational mode. In such a case, the Housekeeping mode is invoked. When the servers have started, and after several system messages, the following confirmation message appears: Alliance has started 7. If there are no other tasks to perform, then select Exit from the File pull-down menu. You are logged off from the Alliance Administrator account.
17.1.1.2 Considerations when Using the "Start Alliance Servers" Command

Overview When the Start Alliance Servers command is run, the server processes are started in an order that respects interdependency between them. The script does not return control to the terminal until all server processes have successfully started, until a time-out value is reached, or an error occurs. If there is no active routing schema, then the servers are started in Housekeeping mode. Occasionally, some processes may fail to start and the following error conditions may indicate why the servers failed to start: Time-out value reached before the servers are ready. Some process failed to run. Some process terminated in error. A whole component failed to start. Relevant errors can be found in: the System Administration window the event journal status_file (in $ALLIANCE_DB) logfile.<instance name> (in $TMPDIR or, if $TMPDIR is not defined on the system, in /var/tmp/alliance) errorfile.<instance name> (in $TMPDIR or, if $TMPDIR is not defined on the system, in /var/tmp/alliance) The normal sequence of processes started is as follows: 1. BS_csys 2. BS_topc
3. BS_alarm 4. BS_rmq 5. BS_config 6. BS_search 7. Processes of all the other service components.
17.1.1.3 Extended Reporting at Server Startup

Overview During startup of the Alliance Access servers, all processing actions are recorded in a log file called status_file. This information can also be displayed in the System Administration application window. This optional feature helps you interpret problems which can occur when the system is started. The log file can be transmitted to Support. It is located in $ALLIANCE_DB. Extended Reporting can be turned on or off when starting the servers. The default setting is off. This means that it must be turned on explicitly when starting the servers. To turn Extended Reporting on and off: 1. Select Start Alliance Servers from the Alliance menu in the System Administration application. The Alliance System Administration: Start Servers window appears.
2.
Click Yes from the Extended Reporting menu button. Extended reporting is displayed in the main window.
17.1.1.4 Extended Reporting Output Format

What is displayed by Extended Reporting If Extended Reporting is turned on, then the following items are displayed: If the database is being started or if the Alliance Access bootstrap is running, then this is displayed. For each server that is started, the server name, an indication that the server is starting, and the result ("Ready" or "Failed") is displayed. If a server fails to start, then the event related to this failure is also displayed. Example: Server MXS : Starting... Ready If recovery is invoked, then the following is displayed for any change in the recovery process: which entity, message partner, and so on, is recovering and, where relevant, a counter showing how many records have been recovered, whether any messages are still
30 September 2011
133
being processed, and the keyfield of the record being processed. All this helps to determine which record caused the error. If a rollback, or roll forward is carried out, then this is displayed. If a server does not start because of database corruption, then the exact entity (and if possible the exact record) is displayed. Possible solutions to problems that may arise are displayed. Depending on the situation, a warning is issued for the user to make a backup before trying to solve the problem.
17.1.2 Checking that the Servers are Running

To determine which Alliance Access processes are currently running: 1. 2. 3. Log into UNIX as Alliance Administrator. The main window of the System Administration application is displayed (you may have to select an instance first). Select Xterm from the OS Configuration pull-down menu. When the UNIX prompt ($) is displayed in a new window, type: ps -ef | grep $ALLIANCE | grep -v grep All Alliance Access processes currently running are listed in the Xterm window. Note The technique used to start processes is to spawn them as children of BS_csys. The consequence is that the ps command described above may show more than one BS_csys process running for a period of a few seconds. These duplicate processes change into genuine processes in due course. Where BS_csys is not running, then the Alliance Access servers are not running.
17.2
Stopping the Alliance Access Servers

This section describes how to stop the Alliance Access servers using either: the System Administration application and the Stop Alliance Servers command saa_system stop command In most circumstances, a shutdown of the Alliance Access servers is initiated within the System Management application of Alliance Access, using the Stop Alliance command. The behaviour of Alliance Access after the shutdown request is as described in "Description" on page 136.
Overview
17.2.1 Shutdown of Alliance Access

Description The usual way to shut down the Alliance Access servers is by using the facilities provided within the System Management application. For details, see the System Management Guide. A shutdown of the Alliance Access servers can be initiated automatically by Alliance Access. For example either when a server (that has updated a database) crashes or when the system is running out of disk space.
However, in certain circumstances the Alliance administrator may want to shut down the Alliance Access servers (for example, for urgent system maintenance) with the use of the Stop Alliance Servers command that is available from the System Administration application. In urgent situations, the Alliance administrator may also force the immediate termination of all Alliance Access servers and processes using the saa_system stop force command. For details, see "To stop the server" on page 236. The following table details the various disk space parameters that can be set:
Parameter Frequency Shutdown - MB Description The interval in seconds (in multiples of 60) at which disk space is checked. The absolute minimum free disk space (in MB) that must be available on the disk containing the database. A system shutdown is initiated if the free disk space available for the database falls below this value. The system automatically adds (for recovery purposes) the size of the largest database file stored in the database, plus the size of the database index file, to the value specified. The frequency with which this parameter is checked is set by the Disk Space Frequency parameter. Shut down Alliance Access when available space on the disk of the source tree is less than this value (in KB). A warning is issued when the available space (in MB) on the disk of the database is less than value. In addition, extra space (equal to the current size of the largest database file) is added to this value. A warning is issued when the available space (in KB) on the disk of the source tree is less than this value. A warning is issued when the available space on the /tmp disk is less than this value (in KB). When the threshold is passed, an alarm is sent to all operators who are signed on to warn them that the available disk space is low. Note that if the disk space available to the "/ tmp" directory is less than the value specified here, you will receive warnings about lack of disk space. Default 300 1000
Shutdown - Release Dir
20000
Warning - MB
5000
Warning - Release Dir
50000
Warning - Printer Spool
10000
These parameters are set within the System Management application of Alliance Access. When a warning of disk space being low has been given, further warnings are generated every 10 cycles of disk checking. If the system shuts down due to insufficient disk space, then you may create additional free disk space by removing core files and by backing up message and event archives. The archives can then be removed from the system. Use the following command to remove core files:
30 September 2011
135
find / -name core -exec rm {} \; In addition to the above parameters, a continuous background process also monitors the use of paging space. If the available paging space is found to be dangerously low, then a warning message will pop up that to inform users to quit Alliance Access. If this message appears, then all operators must sign off immediately from Alliance Access and you are advised to shut down the servers. When the servers have been restarted, the normal functions of Alliance Access are sufficient to enable users to sign on again and continue working.
17.2.2 The "Stop Alliance Servers" Command

Overview In most circumstances, a shutdown of the Alliance Access servers is initiated from the System Management application of Alliance Access, using the Stop Alliance command. The Alliance Access servers may also be shut down by the Alliance administrator, as follows: 1. Log into UNIX as Alliance Administrator. After selecting from the instance selection window (if more than one instance is installed on your system), the main window of the System Administration application will appear. Select Stop Alliance Servers from the Alliance pull-down menu. When the servers have stopped, you may perform any system maintenance activities that require the servers to be stopped, or quit the System Administration application.
2. 3.
Description The behaviour of Alliance Access, following a "stop servers" request, is the same regardless of who initiated the shutdown. All operators receive an alarm message, stating that the system is shutting down within a specified period of time. This "grace period" (default is 120 seconds) is that specified by the Shutdown "Delayed" parameter which can be configured within the System Management application. During the grace period, the servers continue to function normally to allow users to complete any work. After the grace period has expired, the servers stop, one after another, in an order that respects inter-dependencies between them. HCI windows progressively start to hang up. Eventually, the BS_csys process is the only running server left, at which time the HCI itself is killed. The normal termination of processes is logged in the Event Journal. Note When the system does not manage to stop all the servers within the time limit specified by the Shutdown "Forced" parameter (default value is 240 seconds), a "forced shutdown" is then initiated. During a forced shutdown, processes are killed by BS_csys in an arbitrary order. This parameter is configurable within the System Management application. Processes terminated in this way are logged in the Event Journal by BS_csys, as if they had crashed.
136
17.2.3 The saa_system stop Script

Description The saa_system stop script can be used to stop the Alliance Access servers. In most circumstances, a shutdown of the Alliance Access servers is initiated within the System Management application of Alliance Access, using the Stop Alliance command. The Alliance Access servers may also be shut down from the UNIX command line, by running the command: saa_system stop The behaviour of Alliance Access after the shutdown request is as described in "Description" on page 136.
17.2.4 The saa_system stop force Script

Overview The Alliance administrator must resort to the use of the saa_system stop force script, when and only when either the system must be stopped urgently or the normal shutdown procedure failed to complete. To kill the Alliance Access servers: 1. Log into UNIX as Alliance Administrator. After you make your selection from the instance selection window (if more than one instance is installed on your system), the main window of the System Administration application appears. Select the Xterm command from the OS Configuration pull-down menu. When the UNIX prompt is displayed in a new window, enter the command: saa_system stop force Description After this command, all Alliance Access server processes are killed in an arbitrary manner. Note Since this command is issued at the UNIX shell level, the kill action is not recorded in the Event Journal.
2. 3.
When the Alliance Access servers are started next, all database files that were open in "write" mode at the time the saa_system stop force script was run are recovered automatically. The kill operation takes about one minute to complete. If the kill is successful, then the UNIX command: ps -ef | grep $ALLIANCE | grep -v grep must not show the BS_csys process.
30 September 2011
137
17.3
Running Selected Program Scripts following Server Start and Stop

You can specify two executables which may be invoked when the Alliance Access servers are either started or stopped. These executables must be present in the script sub-directory of usrdata beneath your installation directory, and must be declared in: saa_starthook saa_stophook Scheduling the automatic starting and stopping of the Alliance Access servers is described in the System Management Guide. Note The post processor scripts must not contain arguments or quotes. The Alliance administrator (typically all_adm) must own the scripts. The scripts cannot be writeable for group or for world (use 0755 for example).
Description
17.4
Monitoring Processes
The Monitoring application (available from the Access Control application) displays dynamic data for all servers, and applications that are currently operating in the Alliance Access environment. Processes are divided into server components, which process and deliver data to applications and application components.
Introduction
17.4.1 Displaying the Processes

To display the processes: 1. 2. Run the Monitoring application. If the Processes window does not appear, then select Processes from the View Mode menu. You can select to display all processes, or only those in an exceptional state (crashed or timed-out).
138
17.4.2 Viewing the Status of a Process

Displaying the processes: Timed-out The application did not receive input within the time-out period and has terminated accordingly. This is an exceptional state. Running The application is available. This is the normal process state. Some processes may go directly into this state without initialising. Crashed The application or server has either crashed or the user has quit or aborted the process. This is an exceptional state. For more information, see "Session Status Pane" in the Daily Operations Guide.
17.4.3 Stopping a Process

Description Periodically, you may be working with a process which, for some reason, must be terminated. Such a process (for example) can be an application within a component whose response time has become unsatisfactory due to a possible system overload. Note Selecting and stopping a component process terminates the entire component regardless of the number of sub-applications that may be running. For example, stopping the Message Preparation component would stop all Message Preparation applications currently running.
To stop a selected process: 1. 2. 3. 4. Select the Monitoring application to display a list of all active processes. Select the process (or processes) that you want to stop. From the Action menu, select Processes. The default "action" for processes is to stop the operation of the selected process. Select Action | Processes | Stop.
17.4.4 Locating and Identifying a Process

Description The Processes list displays a number of fields to identify a particular process in the system. Use these attributes to locate and identify the process that you want to stop. Description Short textual description of the application, or server currently running.
30 September 2011
139
Started By The name of the operator who is currently using the application. The value of this data field is always equal to "SYSTEM" for servers. PID Process IDentification number. Each process that is currently active within the UNIX operating environment is given a unique PID. TID The thread ID of a logical process within a process. Display The variable identifies the host name on which the X server is running and the X terminal window that is used to display the application. This host name is not necessarily the machine on which the host system or client process is running. Status The current operational state of the process.
140
Query the Database for Message, Events, and Operator Details
18

Overview This section describes how to query the Alliance Access database for messages, operator details, and events. Important The functionality for querying the database for messages and events is only available in release 7.0.10 and later releases. The functionality for querying the database for operator details is only available in release 7.0.30, and later releases.
18.1
Query the Database to Extract Messages

You can run a query to extract the content of messages (live or archived) from the database. The query provides the contents of the messages that were created within a specific time period. The messages are provided in an output file in XML format.The XML format is the same format for the Web Services for queries on messages. You can only extract details of messages only from the Alliance Access instance from which the command is run. Note You do not need the Web services licence package to use this command.
Purpose
Prerequisites To query messages, the Alliance Access server must be running in operational mode. Note Your Alliance Access licensing agreement allows only a certain number of operators to use the system concurrently. Running a query to extract messages starts an operator session with Alliance Access, and this session is included in the count of concurrent users of the system.
To query messages in the database 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_query command. For command location, syntax, and results, see "saa_query" on page 295. The contents of all messages that have a creation time or date within the time period are exported from the database to an output file. The progress of the command is displayed on the screen. The following output appears onscreen when Alliance Access finds no more messages that match the time period specified:
INFO Logging to C:\Alliance\Access\log\sa_extract_20110421T123427.output
INFO INFO INFO INFO
Start time : 2011-04-21T00:00:00.000Z End time : 2011-04-21T23:59:59.000Z 103 records exported Extraction successful
18.2
Query the Database to Extract Events

You can run a query to extract the content of events (live or archived) from the database. The query provides the contents of the events that were created within a specific time period. The messages are provided in an output file in XML format.The XML format is the same format for the Web Services for queries on messages.
Purpose
Prerequisites To query events, the Alliance Access server can be running in either operational or housekeeping mode. Note Your Alliance Access licensing agreement allows only a certain number of operators to use the system concurrently. Running a query to extract messages starts an operator session with Alliance Access, and this session is included in the count of concurrent users of the system.
To query events in the database 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_query command. For command location, syntax, and results, see "saa_query" on page 295. The contents of all events that have a creation time or date within the time period are copied from the database to an output file. The progress of the command is displayed on the screen. The following output appears onscreen when Alliance Access finds no more events that match the time period specified:
INFO INFO INFO INFO INFO Logging to C:\Alliance\Access\log\sa_extract_20110419T163427.output Start time : 2011-04-19T00:00:00.000Z End time : 2011-04-19T23:59:59.000Z 720 records exported Extraction successful
18.3
Query the Database to Operator Details

You can run a query to extract information about operators and operator profiles from the database. The command extracts details only from the Alliance Access instance from which the command is run. The extracted information is stored in an output file in XML format.The XML format is the same format for the Web Services for queries on messages.
Purpose
142
Prerequisites To query operator details, the Alliance Access server can be running in either operational or housekeeping mode. In addition, to extract the delegation details of an operator, the operator profile of the operator that runs the command must include the System Management entity in the selected permissions. By default, the default operator profile, R7.0_Import_Export includes the required permissions. Note Your Alliance Access licensing agreement allows only a certain number of operators to use the system concurrently. Running a query to extract messages starts an operator session with Alliance Access, and this session is included in the count of concurrent users of the system.
To query events in the database 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_query command. For command location, syntax, and results, see "saa_query" on page 295. The operator details are copied from the database to an output file. If the operator that launches the command has delegated units, profile, or destinations, then only those allowed units, profiles and destinations are exported. The progress of the command is displayed on the screen. The following output appears onscreen when Alliance Access finds no more events that match the time period specified:
INFO INFO INFO INFO INFO Logging to C:\Alliance\Access\log\sa_extract_20110419T163427.output Start time : 2011-04-19T00:00:00.000Z End time : 2011-04-19T23:59:59.000Z 720 records exported Extraction successful
30 September 2011
143
19
Backing Up Data
Introduction Data generated by Alliance Access is stored in a database and archives. It is important to make backups of this data. This can be done in either of the following ways: by using the Backup/Restore command from the System Management application (through the Access Control application, using an Alliance Workstation). by typing a command from a Command Prompt window. For detailed instructions, see "saa_system" on page 231. SWIFT recommends to: back up (and remove) the Message File and Event Journal archives every week perform a database backup on a daily basis take a full system backup at least weekly, or more frequently if required. Important To take a full system backup, all applications on the system must be stopped. This includes stopping the Alliance Access bootstrap service and the database, using the saa_bootstrap stop command.
Alliance Access maintains all of its software in a directory defined by the environment variable $ALLIANCE. To ensure operational security and efficient data recovery in the event of a major problem, all Alliance Access data AND associated system configuration data must be backed up periodically. This section describes the procedures used to back up the Alliance Access data, as well as the complete system. The frequency with which backups are taken, and the number of historical copies retained before the oldest is overwritten, is for individual organisations to decide according to local requirements for operational security. The main reason for making regular backups is to ensure minimal downtime in the event of disaster. It is therefore highly recommended that you implement regular backup procedures to protect against equipment failure.
19.1
Database Backup
Alliance Access configuration data (for example, operator definitions, profiles, routing rules, RMA authorisations, and so on) is maintained in the $ALLIANCE/database directory. The collection of all such data is referred to as the Alliance Access database. All message and event data is stored in the database and cannot be amended once they are archived. For information about archiving, see the Daily Operations Guide. Note An Alliance Access database backup does not include messages or events.
Description
144
Backing Up Data
19.2
Archive Backup
Archives of the Message File and Event Journal are kept in the database until they are backed up. Only the archive backups that were created using the Backup/Restore function are compatible between versions of Alliance Access. Note You cannot create backups of archives that were created using Alliance Access 6.0 or earlier.
Description
Management of backup files A backup is the only way to free the space that the archives use. If you do not have to use the archives on a daily basis, then you are advised to make regular backups of the archives and remove the original archives. This action makes disk space available and enables data to be recovered efficiently in the event of a major problem, such as, disk failure.
19.3
Temporary Storage Directory for Backup

If one of the environment variables $TMP, $TMPDIR or $TEMP are set, it will be used as storage for temporary files created during a backup. You can check the path name of these variables by issuing the following command:
echo "TMP=$TMP" && echo "TMPDIR=$TMPDIR" && echo "TEMP=$TEMP"
Overview
If none of the variables are set, then backup system will revert to using the /tmp directory. You can check the available space on this file system by typing:
df /tmp command
To create a temporary directory: 1. 2. 3. 4. 5. Open the System Administration window. Check the name of your Alliance Access instance in the Instance menu. Open an Xterm window from the OS Configuration menu. Change to the home directory of all_adm (normally /home/all_adm) with the cd command. Use the command ls -al to confirm that the file .swa.*instance name.rc exists. Replace *instance name with the instance name obtained in step 2 (by default, .swa.init.rc). If this file does not exist, create it using the instance name from step 2. 6. Open the file and add the following line: export TMPDIR=/alliance/tmp
30 September 2011
145
Note
If you select not to create this entry, temporary files will populate the /var/ tmp and /tmp directories during operation and backups. These files must be deleted manually during maintenance periods. An exception is the /var/ tmp/alliance directory, which contains important log files and is maintained by Alliance Access.
7.
Save the file and quit the System Administration window.
19.4
Performing a Manual Backup of Archives

You can create a backup of archives manually using the System Management application.
Introduction
Location of Archive backup files The following are the default locations of an archive backup file: Event Journal archive: $ALLIANCE/usrdata/backup/eja Message archive: $ALLIANCE/usrdata/backup/mfa Where $ALLIANCE is the directory in which Alliance Access is installed. If you select a location different from the default location, then the new location is not recorded permanently. Status of the archives The archives that appear in the Available list in the Alliance Backup window can have the following states:
Status Ready Done Description Alliance Access has created an archive successfully, and the archive is ready to be backed up. Alliance Access has created a backup of the archive successfully. An archive has been successfully restored from a backup.
Before you begin You do not have to stop the Alliance Access servers before you start this procedure. To perform a manual backup of archives: 1. 2. Run the System Management application. From the File menu, select Backup. The Backup Alliance window appears. 3. Click one of the following tabs: Journal Archive Message Archive 4. In the Backup operating mode field, select Manual.
146
Backing Up Data
5.
Click
Backup
The Alliance Backup window appears.
6.
The Backup Directory field specifies the location where Alliance Access stores the backup file. If required, click ... to specify a different location. If you intend to copy the backup to tape or a hard disk, then make a note of this directory path for future reference.
7.
In the Operation panel, select one of the following: Backup, to create a backup of the archive, without deleting the archive. Backup and Remove, to create a backup of the archive, and then delete the original archive after the backup is complete. Remove, to delete an archive that has the status Done, without creating a backup for the archive.
8.
Select the archives to back up, by clicking the transfer arrows to move the archives between the Available pane and the Selected pane. Note An archive must have the status of Ready or Done, before you can create a backup for it.
OK
9.
Click
If the Alliance Access creates the backup file successfully, then it displays a confirmation message. Click OK in the confirmation dialog box. The selected archives are backed up, or removed according to your selection.
30 September 2011
147
Names of archive backup files Alliance Access creates a directory for every archive backup, and uses the following naming convention for the directory:
<Entity>_<ArchiveName> <Entity>_<ArchiveName1_ArchiveNameN>
Where: <Entity> represents the type of item being archived: JRAR, for backups of Event Journal archives MEAR, for backups of Message File archives ArchiveName represents the name of the archive that Alliance Access backed up. Examples of directory names:
MEAR_20070617 JRAR_20070610_20070614
19.5
Performing a Manual Backup of the Database

You can create a backup of the Alliance Access database manually using the System Management application.
Introduction
Location of database backup files The default location of database backup files is $ALLIANCE/usrdata/backup/db. Where $ALLIANCE is the directory in which Alliance Access is installed. If you select a location different from the default location, then the new location is not recorded permanently. Before you begin You do not have to stop the Alliance Access servers before you start this procedure. To perform a manual backup of the database: 1. 2. Run the System Management application. From the File menu, select Backup. The Backup Alliance window appears. 3. 4. 5. Click the Database tab. In the Backup operating mode field, select Manual. Click
Backup
The Alliance Backup window appears.
148
Backing Up Data
6.
The Backup Directory field specifies the location where Alliance Access creates the directory for the backup. If required, click Tip
...
to specify a different location.
If you intend to copy the backup to tape or a hard disk, then make a note of this directory path for future reference.
OK
7.
Click
If the Alliance Access creates the backup file successfully, then it displays a confirmation message. Click OK in the confirmation dialog box. Following the successful backup of a database, Alliance Access writes the version number of the Alliance instance and the current date in an information file called backup.info. Alliance Access stores backup.info in the same directory as the backup. If the backup process fails, then Alliance Access deletes the database backup directory and any files in it. Alliance Access stores a maximum of two backups. If two backups exist at the time of backup, then Alliance Access shows a warning message and prompts you to confirm to remove the oldest backup. If you click No , then it does not remove the oldest backup. If you click Yes , then it removes the oldest backup and logs an event. Naming convention for backup directories Alliance Access creates a directory for every database backup, and uses the following naming convention for the directory:
YYYYMMDDTHHMMSS_SAA_DATA_BACKUP
Where YYYYMMDDTHHMMSS represents the local time on the server when the backup was created.
30 September 2011
149
Examples of directory names:

20070426T120000_SAA_DATA_BACKUP 20070426T220000_SAA_DATA_BACKUP
19.6
Scheduling Automatic Backups

It is possible to schedule automated backups of the database and of archives. The Alliance Backup/Restore application starts backups according to the schedule defined. For more information, see "Configuring the Calendar and Scheduling Processes" in the System Management Guide.
Overview
Backup schedule exceptions If a backup or restore is running at the time the backup is scheduled, the scheduled backup is not performed and an event is logged in the Event Journal. Also, scheduled backup does not take a backup of the archives that are either under construction (that is, the archive process is running), or being consulted.
19.7
Following a Backup
The Backup/Restore application creates backup files and places them in a backup directory. By using the browse function you can back up to any device with a drive designation on your machine. It is up to you to decide what you do with the backup files. They can be copied to tape or a hard disk. Once created, store your backups in a safe location, according to your institution's security procedures.
Description
150
Restoring Data
20
Restoring Data
Introduction You can restore archived information from a backup in either of the following ways: by using the Backup/Restore command from the System Management application (through the Access Control application, using an Alliance workstation). This can only be used to restore archive backups. by typing a command from an X-term (from the OS Configuration menu in the System Administration window). For detailed instructions, see: "saa_system" on page 231 to restore archive backups "saa_dbrestore" on page 285 to restore database backups. You can restore: Event Journal archives Message File archives Some or all of the configuration data For more details, see "Backing Up and Restoring" in the Daily Operations Guide.
20.1
Restoring an Archive Backup

The restore procedure imports the contents of an archive backup file into the Alliance Access database. The backup archive file remains in the backup directory. If backed up archives of Journal or Message entries are needed (for example, for an audit), then you can restore them from the backup files, using the Backup/Restore application or the command line tools. You can also restore archives from backup using the System Management application, which is accessible through Alliance Workstation. Note On UNIX, if you are restoring from a backup made with Alliance Access 6.0, then you must use the saa_system archive restoretar command.
Overview
Restoring Telex and Fax messages You can restore Telex and Fax messages processed with releases earlier than release 7.0. However, due to database structural changes required to remove Telex and Fax functionalities for release 7.0, the following fields are not restored: for Telex messages: Telex Number, Answerback, and Network application for Fax messages: Fax Number, CUI, and Network application.
30 September 2011
151
To restore an archive backup: 1. 2. Run the System Management application. From the File menu, select Restore. The System Management - Restore window appears.
3.
Select one of the following types of archive to restore: Journal Archive Message Archive
4.
Click
Restore...
The Alliance Restore window appears.
The Entity field displays the type of archive backup to be restored. You cannot edit this field. 5. 6. 7. The Backup Directory field contains the current path name of the archive to be restored. If required, select another path by clicking ... . Click the transfer arrows to move the archives between the Available pane and the Selected pane. Click
OK
to restore the selected archives.
152
Restoring Data
If the archive is restored successfully, then a confirmation message appears. Click
OK
20.2
Restoring the Alliance Access Database

You can restore the content of the database if it becomes corrupt, possibly because of a partial or complete disk failure. If such a failure occurs, you may have to reinstall the Alliance Access software before you can restore the database. Important If you have to restore from a backup, then you lose all the changes that you have made to your system since this backup. Therefore, you must create backups frequently. You cannot restore a database from a backup that was created with a previous release of Alliance Access.
When to restore
Location to which the database is restored When you restore the database, Alliance Access automatically restores it to the correct path, even if the path is different from the one that the database was backed up from originally. This enables you to restore the database to a different installation of Alliance Access on a different computer, or disk. Restore Sets You can restore either the complete contents of the database or just a set of related data, which is called a Restore Set. If you restore the complete database to the same system from which the database backup was created, then the Message File and Event Journal entries are overwritten during the restore. You can use the Restore Set option to restore a set of related data, to the exclusion of all other data. For example, to copy configuration files and security definitions from a fully configured primary site onto a secondary or backup site. To restore the database completely, select all the Restore Sets. Before restoring data, you can check the consistency of the Restore Set with your current database. For more information, see "Restore Sets" on page 155. Disabling connectivity and ADK components When restoring the Alliance Access database, it is possible to disable automatically the connectivity with different networks, back-office applications, and printers, as well as ADK components. If the restored system is used as a cold backup system, then you must disable this connectivity. Licence verification When backing up the complete Alliance Access database, the Backup application also backs up licensing. The Backup/Restore application verifies that the licensed options on the target machine are the same as those on the backup machine. This ensures that the licensed options on the test system and live system are the same. If a difference is found, a warning is given and the restore operation stopped.
30 September 2011
153
20.2.1 Overview of Restoration Process

Database restoration The restoration of the Alliance Access database involves the following tasks: 1. 2. 3. 4. Run a consistency check on the data that you are restoring. Stop the Alliance Access servers. Restore the data from the backup file (that is, importing it into the database). Run the saa_configconnection tool to import the Certificate and Private Key. For more information, see "saa_configconnection" on page 230. If you do not know the password used to encrypt the file containing the Private Key (created by the swrpc_keytool), then you must run swrpc_keytool tool first. 5. Start the Alliance Access servers.
The Backup/Restore application keeps a catalogue of entities that are validated when selectively restored (for example, Units, Operators, Keywords, Exit Points and Queues, and so on). Synchronisation between Live and Test Alliance Access systems Some users maintain both "live" and "test" systems. The test systems, which are usually backups of the live system, are used to prove that a new release functions correctly or to validate a new configuration before it is deployed for live operations. To provide users with a less error-prone method of selectively restoring a part of the database onto the live machine, Alliance Access provides verification on each selected Restore Set. The information used to verify that the restored data entities is catalogued during the backup process. You can test the following information before deploying it in a live system: routing information correspondent information operator and profile definitions Following each validation, and before data in the Restore Set is restored, an overview appears showing the results for each data entity. For example:
The following entities were checked for consistency: 1.Operators no inconsistencies were found. 2.Keywords the following inconsistencies were found: keyword xyz does not exist on the backup ----Detailed information can be found in the following file: /tmp/<logfile>
154
Restoring Data
Note
When restoring data from a database backup, the Restore application verifies that the licensed options on the target machine are the same as those on the machine where the backup was made. For destinations, the Backup/Restore application does not check the Test and Training destinations that the users added). If a difference is found, then a warning appears, and the user must stop the restore operation. You cannot restore archives or the database from a network drive.
20.2.2 Running a Consistency Check

Description The Restore Set option restores a set of related data, to the exclusion of all other data. For example, you can use this option to copy configuration files from a fully configured primary site onto a secondary or backup site. Before restoring data, you can check the consistency of the Restore Set, with your current database, using the saa_dbrestore command. For command location and syntax, see "saa_dbrestore" on page 285.
20.2.3 Restoring the Database

Permissions required You need the Alliance Access Administrator account to restore a database backup. Before you begin Before making a partial restore of a database from another machine, make sure that the Alliance instance on the new machine was built from a full restore of the same database. If required, run a consistency check on the Restore Set. For more information, see "Running a Consistency Check" on page 155. If you have database recovery activated, then you must deactivate it, as described in "Deactivate the Database Recovery Mode" on page 177. Stop the Alliance Access servers. Restore the database You restore the database using the saa_dbrestore command. For command location and syntax, see "saa_dbrestore" on page 285.
20.2.4 Restore Sets

ADK storage If option 99:TOOLKIT RUN-TIME is licensed, information specific to the ADK applications is restored when this Restore Set is selected. If the ADK Storage Restore Set is selected, the <Alliance installation directory>/data/ADK_DIR directory and all its sub-directories are restored.
30 September 2011
155
Correspondent The Correspondents information is restored when this Restore Set is selected. Operator When you restore the Operator Restore Set, Alliance Access imports the operator definitions, entitlements, and permissions into the database. When restoring the Operator Restore Set, the consistency check ensures that no conflicts exist in the definitions. For Units, the validation is to ensure that they exist. There is no check to ensure that their definition is the same. If there is an inconsistency between units, then the restore is not allowed. When the consistency check is complete and before the restore is performed, a report shows the validated entities and their level of consistency. The location of a detailed log file is provided at the end of the overview. RMA Authorisations The RMA authorisations are restored when this Restore Set is selected. Routing information When selecting the Routing Information Restore Set, the following definitions are restored and a verification is made that the entities exist: operator names keywords exit points units queues There is no validation of the contents of these records. When validation is completed and before the restore is performed, an overview showing all validated entities and consistency information. The location of a detailed log file is provided at the end of the overview. If an inconsistency is detected between Queues, Exit Points, Units, and Keywords, the restore is not allowed. If other inconsistencies are detected (operator names), an option to continue or cancel the restore operation is provided, with a warning about possible inconsistencies. The following is also restored when this Restore Set is selected: keyword information routing schemas routing rules queues. SWIFT To restore destination details, logical terminals, and own destinations. When the SWIFT Restore Set is selected, you can also specify whether information concerning SWIFTNet connections must be restored.
156
Restoring Data
After a restore, if an LT uses a specific Authoriser DN that no longer exists, then you must assign another SWIFTNet connection to the LT, or update the SWIFTNet connection assigned to the LT. SWIFTNet Interface Restore Set To restore the emission and reception profiles. When restoring the SWIFTNet Interface Restore Set, you can also select whether the SWIFTNet connection information must be restored.
30 September 2011
157
21
Managing Disk Space

Introduction Alliance Access monitors the different parameters related to available disk space. These parameters are listed in the following section and can be updated using the System Management application. The most critical parameter ensures that there is always enough disk space available for Alliance to take a copy of the largest file of the database (for archiving and recovery purposes). The Alliance Access servers will go down if these criteria are not met. Typically the sizes of the message and event journals will rapidly reach high values if backup (of the message file and the event journal) is not performed on a regular basis. If archiving and backup of messages and events is not done regularly, then the available disk space decreases. You can only free disk space when archives are backed up and removed.
21.1
Monitoring Available Disk Space

Applications such as the Event Journal and the Message File applications are continually adding new records in the database, which consume the available disk space. It is, therefore, necessary to perform archiving and backup operations to make sure the disk space is continually available to other applications. The system resource display provides a parameter (Disk Space) which enables you to monitor the available disk space for the database at any given time. Exceptional events are defined for many object classes monitored in the Monitoring application. For example, the Disk Space parameter is considered to be in the exceptional state if the free space is less than the minimum value specified by the Disk Space configuration parameter Warning - MB. For more information about Disk Space parameters, see the System Management Guide.
Description
21.2
Modifying Disk Space Parameters

There are a number of disk space parameters set by default.
Introduction
To modify disk space parameters: 1. 2. 3. Run the System Management application. If the Configuration view is not displayed, then select Configuration from the View menu. Look for the parameters with class 'Disk Space' and double-click the parameter that you want to modify. Fore information about the parameters available, see the System Management Guide.
158
Managing Disk Space
21.3
System Resources
The Monitoring application provides a Disk Space parameter which enables you to monitor the available disk space and system archiving. The parameter indicates the amount of space currently available in the database. The available disk space can also be obtained using the df UNIX command. This command reports: total file system sizes, amount used and amount available (in KB) as well as '% capacity' used. Any file system reported as nearing capacity should be investigated so as to free up disk space.
Description
21.4
How To Recover Disk Space

1. 2. 3. Remove unwanted files from the system (for example: Core dump files, old files held in print queues, and so on). Perform regular archiving of the messages and events. Clean up archives using the Backup and Remove option in the System Management application.
To recover disk space:
21.5
Backing Up the Instance Registration File

Use these commands to copy the directory containing the instance registration file to an archive file in a suitable directory: su root #provide password cd /usr tar cvpf <target directory>/<archive file> swa/* The instance registration file can be identified by its title 'insts'.
Description
30 September 2011
159
22
22.1
Managing the Database

Getting Information about the Alliance Access Database
The saa_dbinfo tool provides the following information: version information about the database initialisation parameters current database sessions tablespace information whether the redo log files are correctly sized and reside on disks with adequate performance diagnostics reports for specific time periods assessment information about database performance with greater/smaller available physical memory (RAM). Prerequisites The tool must be run from the Alliance Access Administrator account. The database must be running. Procedure 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_dbinfo command. For command location and syntax, see "saa_dbinfo" on page 282. The tool provides, for the period specified, the available hourly diagnostic information generated by the database engine.
Introduction
22.2
Checking the Alliance Access Database

Verifies the integrity (absence of unauthorised updates) of the Alliance Access database. You can check the whole database, including the daily tables, or just the static (non-daily) tables.
Purpose
Procedure 1. 2. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu.
160
3.
Enter the saa_system dbintegrity command. For command location and syntax, see "saa_system" on page 303.
22.3
Configuring the Embedded Database

The saa_dbconfig command provides the following facilities: related to the tablespaces display the current location, allocated size and usage, of all the tablespaces or for a specific tablespace change the location of a specific tablespace change the size of a tablespace, to either a specific size or to its minimum required size reorganise a tablespace to reclaim unused space and resize it to its minimum required size related to the redo log files display the current location and size of the redo log files move all the redo log files to a different location and resize them to the specified size related to the memory allocated to the database display or change the amount of memory allocated Note This command starts the database of the Alliance Access instance if it is not already running.
Purpose
Explanation of terms Tablespace A tablespace groups database entities in data files. Redo log file A set of files that protect altered database data in memory that has not been written to the data files. Prerequisites The command must be run by the Alliance Access Administrator account. The Alliance Access Bootstrap service must be stopped. The servers must be stopped, except in the case of saa_dbconfig -display. Note You cannot use the saa_dbconfig command with a hosted database configuration.
30 September 2011
161
Working with tablespaces 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_dbconfig tablespace command. For command location and syntax, see "saa_dbconfig" on page 281. Working with the redo log files 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_dbconfig redolog command. For command location and syntax, see "saa_dbconfig" on page 281. Note The original redo log files remain in the original directory.
Location of database files The Location Journal Events and Location Messages configuration parameters can be used to change the default location of the datafiles used to store Journal Events and Messages. For more information, see the System Management Guide, Classes of Configuration Parameters. Displaying and changing memory settings 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_dbconfig command. For command location and syntax, see "saa_dbconfig" on page 281. Note To allocate more memory to the database, it is recommended to have the projectmax-shm-memory parameter at least equal to the database memory value plus 2 GB. The minimum for project-max-shm-memory should be 4 GB. If there are multiple Alliance Access instances for the same user account, then the database memory value (in the above formula) is the sum of each Alliance Access instance database memory size.
22.4
Backing Up the Alliance Access Database

The saa_system dbbackup command is used to perform a full database backup. The database can be either hosted on a separate Oracle database, or embedded in Alliance Access.
Purpose
162
Procedure 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_system dbbackup command. For command location and syntax, see "saa_system" on page 303. Note Alliance Access removes the oldest backup if more than two backups exist within the target backup directory.
22.5
Moving the Database to a New Host

Use this procedure if you need to move the hosted database to a new host machine.
Purpose
Procedure 1. 2. 3. 4. Stop the Alliance Access servers. Move the database to the new host machine. Run the saa_dbpwdutil command (for information and details, see "saa_dbpwdutil " on page 282). Start the Alliance Access servers.
22.6
The saa_bankquery Tool

The saa_bankquery tool provides a dedicated Alliance Access database enquiry and repair facility to verify and repair database entities.
Purpose
Prerequisites Only an Alliance Access Administrator can run saa_bankquery . Given the powerful nature of this tool, its use is protected by three passwords: the first password is the Solaris password of the Alliance Administrator (needed initially to log on to the Alliance Administrator account to run saa_bankquery) the second password is that of any Alliance Access operator (for example, a supervisor) who has been granted the specific entitlement, within Alliance Access, to run saa_bankquery the third password is a dedicated password that must be obtained from Support, as described further. When running the saa_bankquery tool for repair, the Alliance Access servers must not be running.
30 September 2011
163
Note
An operator who uses One-Time Passwords or LAPD authentication cannot use the saa_bankquery tool.
22.6.1 Running saa_bankquery

Overview The need to run the saa_bankquery tool implies that you have a serious problem that cannot be resolved without assistance from SWIFT. If so, first contact Support and be ready to follow the procedure described further. To run saa_bankquery: 1. 2. 3. Log on as Alliance Administrator to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_bankquery command. For command location and syntax, see "saa_bankquery" on page 279. You are prompted to enter the name and password of a valid Alliance Access operator. This operator must have been granted the entitlement to use saa_bankquery within the Access Control application of Alliance Access. This entitlement is granted automatically to the default Supervisor and SuperKey profiles. Assigning this entitlement to other operators requires the approval of both security officers. 4. When prompted, enter a valid Alliance Access operator nickname and the associated password. The saa_bankquery tool then generates a "session ID" which you must communicate (by phone) to Support. A message is displayed, like: *** The ID to be used today is "01 SAAGBEBB B04D035F REL6200". ZERO ONE SIERRA ALPHA ALPHA GOLF BRAVO ECHO BRAVO BRAVO BRAVO ZERO FOUR DELTA ZERO THREE FIVE FOXTROT ROMEO ECHO LIMA SIX TWO ZERO ZERO Please contact SWIFT customer support for the password 5. Inform Support of the ID shown on the screen. In return, Support informs you of a special password, based on the ID you have provided. You need this password to run saa_bankquery and it is only valid for one saa_bankquery session. When prompted, enter the one-time password, as provided by Support, into saa_bankquery. When using saa_bankquery, Support can guide you as to the commands to enter to investigate and resolve your problem. Be ready to read out the relevant responses to each command from the screen. 7. To terminate the execution of saa_bankquery, type:
q
6.
This quits saa_bankquery and returns control back to the Xterm window.
164
Database Recovery
23
23.1
Database Recovery
About Database Recovery
The relational database of Alliance Access can be configured to enhance protection against media failures such as a disk crash or datafile loss. Database recovery provides functionality that allows an Alliance Access administrator to recover the database content, including "live" messages and events. The functionality is subject to the licence option 14:DATABASE RECOVERY. Once activated, database recovery maintains ready-to-use backups of database updates on separate disks (mirror and backup disk). In case of a media failure resulting in the loss of the database content, database recovery provides a single command to restore the database from the data available on the mirror and backup disks, including "live" messages and events. Two types of database recovery are available: Full database recovery The full database content is restored. This requires the availability of the full mirror and backup disk data. In this scenario, only synchronous replication of the mirror and backup disks is allowed. Partial database recovery This option must be used when the recovery data set is not guaranteed to be consistent, that is, typically when it is maintained on a remote site through an asynchronous replication from a primary site. The "partial" recovery restores the database to a consistent state, but possibly without the last updates done on the primary site (before switching to the remote site). An automatic repair of the recovered database is performed (to prevent duplicate transactions). For more information, see "Repairing Messages" on page 173. The main database recovery functions are: configure the database for enhanced resiliency, by defining additional mirror and backup disks. schedule database recovery backups. These backups can also be generated on request, to be included in an external scheduler maintained by the customer. A recovery backup of the database contains all the data present in the database and no information is lost when using these backups for recovery. recover the database to its last committed state in case of a major incident affecting the database files, by using the full database recovery process or the partial recovery process. Database recovery also provides the following options: exclude backed up or restored archives from the recovery backups: this reduces the time required to restore data
Introduction
30 September 2011
165
Recovery will ignore: restored archives (which have been backed up) days of traffic backed up (but not removed from the database) compress the generated recovery backups: this reduces the size of the recovery backup. For more information, see "Scheduling Database Recovery Backups" in the System Management Guide. Note The disks used for the recovery backup disk and the recovery mirror disk must be mounted exclusively so that only the Alliance Access system where the database recovery is activated can access them.
Recovery on a local site In an active or standby configuration, the Alliance Access system is running on the active site. The database (and optionally its software) is replicated on a backup (standby) site. In this configuration, the active site data is synchronously replicated to the standby site, ensuring that the data maintained on the active and the standby sites is always identical. The replication is implemented by the file system used by Alliance Access. This replication is often provided by a Storage Area Network (SAN) infrastructure. The SAN replication must not affect the overall file system performance and is therefore only possible when the distance between the two sites is limited, usually less than 300 kilometres. When the distance is too large, a synchronous replication is not possible, as it would degrade the disk performance too much, and possibly affect the availability and reliability of the system. In case of a failure in the primary site, operations can be resumed in the standby site. The Alliance Access in the backup site can be activated and will be able to resume operations from the replicated database. In this scenario, operations are resumed on the standby site without any data loss. The back-office communication is interrupted until the standby site has been activated and Alliance Access has been restarted. Recovery on a remote site To protect against local site failures, customers sometimes maintain a remote site, located far away from the primary site. In this configuration, an Alliance Access system is set up on the remote site and remains inactive until a failover from the primary site occurs. During normal functioning of the primary site, recovery data from the primary site is asynchronously replicated on the remote site. With asynchronous replication, the data is not identical between the two sites. There is an inherent time delay before the information generated on the primary site is available on the remote site. The delay is mainly linked to the quality and speed of the connection between the two sites. This delay can vary a lot, from a few minutes for the most sophisticated infrastructures to a few seconds for less advanced configuration. The delay is usually never exceeding half an hour. Due to the asynchronous replication, the data will be inconsistent, as the last updates done on the primary site will not be available on the remote site. The amount of information lost will correspond to the database updates done during the replication delay. Database recovery allows to restore the database in a consistent state, but missing the last updates done on the primary site. This is due to the asynchronous replication of data from the primary site to the remote site. This will result in resuming with a database that is not an exact up-to-date image of the live database at the incident.
Database Recovery
This situation may generate duplicate transactions. That is, messages just completed before the incident, may re-appear as "live" in the remote database. If not addressed, the "live" messages will be sent again to SWIFT or to the back-office applications, leading to duplicate transactions. To avoid, on the remote site, the re-emission of messages already sent on the primary site, a message repair operation takes place. For more information, see "Repairing Messages" on page 173. Managing recovery backups From the System Management application, you use the Manage Recovery Backups command to specify: when to generate a full or incremental recovery backup of the database (either based on a time schedule or on disk space usage) whether to include archives already backed up (messages and events) in the recovery backup whether to compress the generated recovery backups. The Manage Recovery Backups command also allows to launch a full or incremental recovery backup. For more information about this command, see "Scheduling Database Recovery Backups" in the System Management Guide. Disk space monitoring The Monitoring application provides a System Resources view to check the size of the recovery backup disk containing the recovery backups. For more information, see "The System Resources Window" in the Daily Operations Guide. The "Recovery Shutdown - MB" and "Recovery Warning - MB" configuration parameters can be set with relation to disk space monitoring. For more information, see "Classes of Configuration Parameters - Disk Space" in the System Management Guide.
23.2
Database Configuration for Enhanced Resiliency

The relational database of Alliance Access is physically made of three main structures: datafiles, which contain all the database data. In Alliance Access, these datafiles are mapped to logical database structures called tablespaces. These tablespaces group the database entities. redo log files, which record all the changes made to the database data. control files, which contain information specifying the physical structure of the database (that is, database name, names, and locations of datafiles and redo log files). Alliance Access provides a database configuration tool (saa_dbconfig) to move redo log files and tablespaces (hence datafiles) to another physical location. The activation of the database recovery on Alliance Access enhances further the database resiliency and allows a recovery of the Alliance Access database to its last committed state in case of media failure.
Description
30 September 2011
167
Activate Recovery Mode The following changes have been performed after the activation of the database recovery mode: 1. After having set up the database for "DB recovery mode", the structure has been changed and is as follows:
Live Disk
Recovery Mirror Disk
Recovery Backup Disk
CONTROL01.CTL CONTROL02.CTL CONTROL03.CTL
REDO01.LOG REDO02.LOG REDO03.LOG
REDOM01.LOG REDOM02.LOG REDOM03.LOG
ARCHIVED REDO LOG DATAFILES FULL BACKUPS INCREMENTAL BACKUPS
This database configuration implies that: The Recovery Mirror Disk is a fast disk, as it is constantly accessed for writing the redo log files. The Recovery Backup Disk is a large-size disk, as it stores the different database backups and the archived redo log files. Note SWIFT recommends using a separate disk controller for the Recovery Mirror Disk and the Recovery Backup Disk.
2. The database is configured to archive the online redo log files. 3. A first full recovery backup of the database has been taken and consists of: a database backup which contains all the database data, excluding the backed up or restored archives of messages, and events a backup of the Alliance Access configuration files stored outside the database
168
D0540176
Database Recovery
4. The database size is monitored, which triggers the generation of full or incremental database recovery backups when specified disk size thresholds are reached. The default configuration for the recovery backups can be changed using the Manage Recovery Backups command in the System Management application. Note No recovery is possible if the Recovery Mirror Disk or the Recovery Backup Disk are damaged, or have missing or corrupted files. As soon as you discover that the recovery disks are damaged, you must deactivate the recovery mode.
For more information on how to activate the database recovery mode, see "Activate the Database Recovery Mode" on page 176. Alliance Access setup on remote site To use the database recovery functionality on a remote site in case of failure, the following steps must be performed: 1. Install Alliance Access on the primary and remote site, with the same licence, version and patch level, and instance name. The IP address, host name, operating system level, software installation location and paths for mirror and backup disks may be different. 2. Set up the asynchronous replication between primary site and remote site. After the asynchronous replication of the disks is set up, Alliance Access will automatically create or update the database control file and trigger the replication of the latest files available on the mirror and backup disks of the primary site to the mirror and backup disks on the remote site. Important A partial database recovery up to the last valid transaction is performed. If you want to use the data from the partial database recovery, then you must set the value of the "Message Repair Action" security parameter on the Alliance Access of the primary site.
23.3
Database Recovery Process

Before a database recovery is initiated, the following conditions must be met: The Alliance Access servers must be stopped. The recovery files present on the mirror disk and backup disks must be available. In case of a recovery on a remote site (disaster site recovery), the complete information present on these mirror and backup disks must be available on the remote site. In case of recovery on a remote site, the Alliance Access system where the recovery takes place must be set up. For more information, see "Alliance Access setup on remote site" on page 169.
Prerequisites
Full recovery process The full recovery of the Alliance Access database is initiated by launching the saa_dbrecovery command line tool, using the -r option. For the command to succeed, it is mandatory that the recovery data is complete. This will always be the case when using the local
recovery data. The full recovery command will be rejected if it is executed against recovery data that has been replicated, but is not complete (as is the case with asynchronous replication). During a full recovery, database recovery will transparently perform the following steps required to recover the database up to the last committed transaction: 1. 2. 3. 4. Restore the latest full recovery backup. Restore the incremental recovery backups, if any. Restore and replay the archived redo log files, if any. Replay the redo logs available on the mirror disk.
The database is recovered to its last committed state based on the information available in the database backups, archived redo log files, and on-line redo log files. For more information on how to start the database recovery, see "Activate the Database Recovery Mode" on page 176. Note The recovery process assumes that the mirror and backup disks are locally available to be restored on the database. In case of a remote recovery, the mirrored control file, on-line redo logs, archived redo logs, and database backups must be available on the remote site, with up-to-date information. The recovery procedure will fail if the various files used for recovery are not up-todate, containing the last committed data. This constraint is particularly important for the mirrored control file and the on-line redo log files that are constantly updated during database activity. Partial recovery process The partial recovery of the database is initiated by launching the command line tool saa_dbrecovery, using the -v option. This recovery mode must be used when the recovery data is not complete. It is therefore the only option allowed when executing a recovery from a remote site, using recovery data replicated asynchronously from the primary site. During a partial recovery, database recovery will transparently perform the following steps required to recover the database up to the last valid transaction: 1. 2. Locate the last valid transaction available in the redo logs present on the mirror disk. Restore the database up to that point by: restoring the latest full recovery backup restoring the incremental recovery backups, if any restoring and replaying the archived redo logs, if any replaying the redo logs available on the mirror disk. Database recovery will indicate the timestamp of the last restored transaction. After successful completion of the partial recovery, the database will be in a consistent state, but will miss some of the last updates done on the primary database. In order to avoid, on the remote site, the re-emission of messages already sent on the primary site, database recovery performs the following actions:
170
Database Recovery
Produce a report with the outstanding live message instances following the database recovery. Add a possible duplication indicator (PDE) to each outstanding live message instance present in the restored database. Perform on these live message instances the action defined by the value of the security parameter "Message Repair Action" (previously set on the primary site): Complete: the message instance is completed Investigate: the message instance is routed to the _MP_recovery queue for further investigation None: the message instance is left in its queue for further routing Prompted: the action to be taken must be specified when launching the saa_dbrecovery command. A report on repaired messages is stored in the following file: <Alliance installation directory>/usrdata/report/saa_msgrepair_YYYYMMDDTHHMMSS.xml For more information about launching the database recovery process, see "Database Recovery Process" on page 169. For more information about possible actions on message instances, see "Processing Repaired Messages" on page 175.
23.4
Database Recovery Backups
23.4.1 Database Recovery Backups

Overview Database recovery backups can be taken if option 14:DATABASE RECOVERY is licensed and if the operator has the function "Manage Rec Backup" of the System Management application included in the operator profile. There are two ways of creating database recovery backups: using the Manage Recovery Backups command in the System Management application. For more information, see "Performing Manual Database Recovery Backups" in the Daily Operations Guide. using the saa_dbrecovery command line tool. For command location and syntax, see "saa_dbrecovery" on page 283.
23.4.2 Creating Database Backups in Recovery Mode

Purpose Alliance Access provides functionality to schedule a database-recovery backup or to create a database-recovery backup manually. A database-recovery backup includes all the data present in the Alliance Access database. A database is backed up either fully or in increments.
30 September 2011
171
Contents of a database-recovery backup If the database and Alliance Access configuration files, which are stored outside the database, have been changed since the last recovery backup was taken, then a database-recovery backup also includes these files. The following outlines the contents and results of a database-recovery backup:
Backup type Full Contents and results The backup on the recovery-backup disk contains all data files including archive backups. It also includes archive backups if the Include Archive Backups option is selected. Alliance Access deletes the existing backups of the type: incremental backups and the archived redo logs full recovery backup(1) Incremental The backup on the recovery-backup disk contains of all data files for which changes have occurred since the last backup was created (any backup type). It also includes archive backups if the Include Archive Backups option is selected. The existing archived redo logs are deleted.
(1) You can remove the existing full recovery backup before taking a new one, by using the option -e with the saa_dbrecovery command. You can also use this option to create disk space if there is insufficient disk space to launch a new full recovery backup.
Include archive backup files An archive backup is a data file that contains an archive of messages or events. Therefore, a data file may contain archives that were backed up previously but not removed from the database. Also, a data file may contain archives that were restored previously. However, you can include the archive backups in the database-recovery backup using the Include Archive Backups option. Available disk space When you perform a database recovery backup, Alliance Access first verifies that the estimated size of the recovery backup is less than the available disk space on the recovery backup disk. If insufficient space is available, then the backup operation will fail. This will not affect normal Alliance Access operations. To create a database backup You can create backup in either of the following ways: 1. Manually create a database-recovery backup in either of the following ways: Use the Manage Recovery Backups command in the System Management application. For more information, see the Daily Operations Guide, Performing Manual Database Recovery Backups. Use the saa_dbrecovery command-line tool. Use this tool if you prefer to rely on the external scheduling of these backups instead of relying on the internal Alliance Access scheduler. For more information about running this command, see "saa_dbrecovery" on page 283.
172
Database Recovery
2.
Schedule database-recovery backups using the Manage Recovery Backups command in the System Management application. For more information, see the System Management Guide, Scheduling Database Recovery Backups.
23.5
Repairing Messages
23.5.1 Repairing Messages after Partial Database Recovery

Purpose The message repair functionality ensures that no duplicate transactions are generated following a partial database recovery. When the Alliance Access database is partially recovered on a remote disaster site, it could be that some FIN, InterAct, or FileAct messages sent or received by Alliance Access on the primary site, or some FIN network acknowledgements (ACK or NAK) have not been replicated on the remote disaster site. Some of these messages would reappear as live and hence, these messages would be resent to SWIFT, which can result in duplicate messages. The message repair functionality helps you to avoid this because the outstanding live messages are identified with possible duplicate emission (PDE) flags, which ensures that potential duplicate re-emissions are identified properly. The message repair functionality is available with the following tools: automatically, with the saa_dbrecovery tool when a partial recovery is launched (option v) manually, by launching the saa_msgrepair tool to resume the repair process if interrupted due to a failure when running as part of the recovery process to perform the message repair action following a recovery on an Alliance Access with hosted database You use the saa_msgrepair tool: on an Alliance Access with an embedded database to re-launch a message repair operation previously interrupted. The tool is used to take corrective actions following the interruption of message repair operation launched by the saa_dbrecovery tool. on an Alliance Access with a hosted database to launch a message repair operation after a database restore was performed without the saa_dbrecovery tool. In this case, licence option 13:HOSTED DATABASE must be present. For details about the usage of saa_msgrepair, see "saa_msgrepair tool" on page 174. When the message repair operation is launched, a possible duplicate emission (PDE) indicator is added to all the outstanding live messages present in the restored Alliance Access database.
30 September 2011
173
For the live messages that are flagged with PDE, one of the following actions is performed: Complete all the outstanding live messages present in the restored Alliance Access database. Route all the outstanding live messages present in the restored Alliance Access database into a dedicated queue, _MP_recovery, for further investigation. Leave all the outstanding live messages present in the restored Alliance Access database in their queue, but flagged with PDE. This will trigger their automatic re-emission to SWIFT or to the back office. Note You can resume the normal operations only after the message repair operation has been executed completely and successfully.
saa_msgrepair tool The tool allows you to: display the status of the message repair operation select the message repair option Warning You must exclusively use the saa_msgrepair tool in the context of a database recovery following a disaster on an Alliance Access hosted on a primary site. You must not use it as a support tool to complete outstanding live messages during normal operations. If you launch the tool when there is no database recovery operation, then the tool will return an error.
Prerequisites The Alliance Access Administrator must run the command. The Alliance Access servers must be stopped. To process the live outstanding messages: 1. 2. 3. Stop the Alliance Access servers. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_msgrepair command. For command location and syntax, see "saa_msgrepair" on page 295. The outstanding live messages are either completed, routed to _MP_recovery for further investigation, or left in the routing point.
174
Database Recovery
Note
A report on the outstanding live messages is stored in the following file: <Alliance installation directory>/usrdata/report/ saa_msgrepair_<YYYYMMDDTHHMMSS>.xml where YYYYMMDDTHHMMSS is the timestamp when the message repair operation was started. Error or confirmation messages are produced upon execution of the saa_msgrepair tool. Logging information is stored in the following file: <Alliance installation directory>/log/ saa_msgrepair.<YYYYMMDDTHHMMSS>.output where <YYYYMMDDTHHMMSS> is the timestamp when the message repair operation was started.
23.5.2 Processing Repaired Messages

Process messages after a partial database recovery You can find the live outstanding messages that have been repaired following a database recovery in the Message Approval application. If the messages are completed or if there is no action, and if such messages are moved to the repair queue, then the queue will be empty. In the Message Approval window, you can select the Recovery option from the View menu. Within this Recovery view, one of the following actions can be performed on these messages: Complete: completes the message instance. Authorise and Route: routes the message instance as per the routing defined in the _MP_recovery queue. Move to Original: moves the message instance to the queue where it was before the message repair operation.
23.6
The saa_dbrecovery Command

The saa_dbrecovery command line tool is available if the database is embedded on Alliance Access and if licence option 14:DATABASE RECOVERY is present.
Tool availability
23.6.1 Display the Database Recovery Mode

Purpose This procedure provides instructions for displaying the database recovery mode in which Alliance Access is operating.
30 September 2011
175
The modes available are: Activated Deactivated The database recovery mode is managed using the saa_dbrecovery tool. Permissions required The Alliance Access Administrator account must run the command. To display the current database recovery mode: 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. How do you want to run the saa_dbrecovery tool?
To launch command with parameters without parameters go to step 4 go to step 5 Then
4.
Run the command:

saa_dbrecovery -m
The database recovery mode is displayed. If the mode is Activated, then the command also displays the total disk size and the free disk space available in MB for the live disk and each recovery disk. For more information about the saa_dbrecovery tool, see "saa_dbrecovery" on page 283. 5. Run the command: 1. saa_dbrecovery 2. Select Display Recovery Mode. 3. Select Quit. The database recovery mode is displayed. If the mode is Activated, then the command also displays the total disk size and the free disk space available in MB for the live disk and each recovery disk.
23.6.2 Activate the Database Recovery Mode

Purpose This procedure provides instructions for activating the database recovery mode using the saa_dbrecovery tool. For more information about active database recovery mode, see "Database Configuration for Enhanced Resiliency" on page 167.
176
Database Recovery
Permissions required The Alliance Access Administrator account must run the command. Prerequisite The Alliance Access database must be running. To activate the recovery mode: 1. 2. 3. Stop the Alliance Access servers. From the System Administration application, select Xterm from the OS Configuration menu. How do you want to run the saa_dbrecovery tool?
4.
Run the command:

saa_dbrecovery -a -p <pathname_recovery_mirror_disk> -q <pathname_recovery_backup_disk> [-f]
Optionally use -f to specify whether a full recovery backup must be created as part of the activation. The command displays the total disk size and the free disk space available in MB for the live disk and each recovery disk. For more information about the saa_dbrecovery tool, see "saa_dbrecovery" on page 283. 5. Run the command: 1. saa_dbrecovery 2. Select Activate Recovery Mode. 3. Specify the full path names of the mirror and backup disks. 4. Select Quit. The command displays the total disk size and the free disk space available in MB for the live disk and each recovery disk. Information about the success or failure of the command is recorded in a log file at the following location: <Alliance installation directory>/log/ saa_dbrecovery.YYYYMMDDTHHMMSS.output where YYYYMMDDTHHMMSS is the time when the command was run.
23.6.3 Deactivate the Database Recovery Mode

Purpose This procedure provides instructions for deactivating the database recovery mode using the saa_dbrecovery tool.
Permissions required The Alliance Access Administrator account must run the command. Prerequisite The Alliance Access database must be running. To deactivate the recovery mode: 1. 2. 3. Stop the Alliance Access servers. From the System Administration application, select Xterm from the OS Configuration menu. How do you want to run the saa_dbrecovery tool?
4.
Run the command:

saa_dbrecovery -d
For more information about the saa_dbrecovery tool, see "saa_dbrecovery" on page 283. 5. Run the command: 1. saa_dbrecovery 2. Select Deactivate Recovery Mode. 3. Select Quit. Information about the success or failure of the command is recorded in a log file at the following location: <Alliance installation directory>/log/ saa_dbrecovery.YYYYMMDDTHHMMSS.output where YYYYMMDDTHHMMSS is the time when the command was run.
23.6.4 Create a Database Recovery Backup

Purpose This procedure provides instructions for creating a full backup or an incremental (partial) backup of the database using the saa_dbrecovery tool. This tool is available if the database is embedded on Alliance Access and if licence option 14:DATABASE RECOVERY is present. To create a database backup in recovery mode, the database recovery mode must be activated, as described in "Activate the Database Recovery Mode" on page 176. Before performing a database recovery backup, Alliance Access estimates the space required for the backup, and then verifies that the recovery backup disk has enough disk space available to store the database backup.
178
Database Recovery
By default, old database backups are removed after Alliance Access creates a new fulldatabase backup successfully. However, you can specify that Alliance Access removes the old backup before creating a new backup. Disks for backups The Recovery Backup Disk and the Recovery Mirror Disk must be mounted exclusively to allow only the Alliance Access system where the database recovery is activated to access these disks. Permissions required The Alliance Access Administrator account must run the command. Prerequisite The Alliance Access database must be running. To create a database recovery backup: 1. 2. From the System Administration application, select Xterm from the OS Configuration menu. How do you want to run the saa_dbrecovery tool?
To launch command with parameters without parameters Create full backup go to step 3 go to step 4 Create incremental backup go to step 5 go to step 6
3.
Run the command:

saa_dbrecovery -c f [-e]
Optionally use -e to specify that Alliance Access removes the old backup before creating a new backup. For more information about the saa_dbrecovery tool, see "saa_dbrecovery" on page 283. 4. Run the command: 1. saa_dbrecovery 2. Select Create Full Database Backup. 3. Optionally, you can specify that Alliance Access removes the old backup before creating a new backup. 4. Select Quit. 5. Run the following command:
saa_dbrecovery -c i
For more information about the saa_dbrecovery tool, see "saa_dbrecovery" on page 283.
30 September 2011
179
6.
Run the command: 1. saa_dbrecovery 2. Select Create Incremental Database Backup. 3. Select Quit.
180
Handling System Failures
24

Introduction This section describes possible causes of system failure and the procedures to recover the Alliance Access system following such a failure. The commands described must be run by the Alliance administrator, when logged on to the Alliance Administrator account. Depending on the nature of the failure, Alliance Access offers different levels of restart and recovery possibilities: If the Alliance Access software has been lost or corrupted, then it must to be re-installed and the data must be restored from a backup. If a disk has failed, then the Alliance Access software must be re-installed and the data must be restored from a backup. If there is a serious hardware failure, then Alliance Access may be recovered using another (backup) system. For more information, see "Recovery on a Different Host Using a Cold Backup" on page 183. If ever a disk failure causes the loss or corruption of the operating system, then the operating system must be either completely re-installed, or restored from backup. It is therefore important that you back up your operating system after it has successfully been installed and configured for Alliance Access (that is, immediately following Alliance Access installation). The procedures described in this section must be followed if the Alliance Access servers halt, or fail to start, due to a process failure, power failure, or disk failure. These procedures assume that, following a hardware failure, the system has been repaired, and that the operating system is available and has been fully configured for Alliance Access.
24.1
Process Failure
Some Alliance Access server processes may terminate unexpectedly for various reasons: software errors, RPC time-outs, kill process commands issued from the shell, system management actions, and so on. Whatever the reason, all unexpected process terminations are journalised and an automatic recovery process initiated by Alliance Access. Following the failure of a particular process, the process is automatically restarted. The client of the server, whose request was being served at the time of failure, may receive a time-out from the server and possibly enter into recovery mode. Following recovery, future clients will automatically start speaking to the recovered server again.
Description
30 September 2011
181
24.2
Power Failure
After a power failure, the disk(s) are checked automatically by the operating system when the system reboots. If a disk error is found, then the recovery scenario is the same as for a disk failure. See "Disk Failure" on page 182. If no damage has occurred to the disk(s), then the recovery scenario is the same as for a process failure. See "Process Failure" on page 181.
Description
24.3
Disk Failure
Following a disk failure, all data held on the damaged disk is either lost or inaccessible. You must repair or replace the damaged disk and then restore both the Alliance Access software and data from backups. If you have the licence option 14:DATABASE RECOVERY, then you can restore your database to the last committed state as it was just before the disk failure. If the damaged disk contained the operating system as well, then the operating system must be recovered from backup before Alliance Access may be restored.
Overview
24.3.1 Restoring Alliance Access Database and Archives

Overview You restore the Alliance Access database by typing a command from an Xterm window (available from the OS Configuration menu of the System Administration window). For more information about restoring the Alliance Access database, see "Restoring Data" on page 151. You can restore Alliance Access archives in either of the following ways: by using the Backup/Restore command from the System Management application (through the Access Control application, using an Alliance workstation). by typing a command from an Xterm window (available from the OS Configuration menu of the System Administration window). For more information about restoring Alliance Access archives, see "Restoring Data" on page 151. Note Before attempting a restore of any data files or archives, check that the backup directories exist. For example, $echo $ALLIANCE_DB
182
24.4
Recovery on a Different Host Using a Cold Backup

This section provides instructions for preparing for, and recovering Alliance Access on a different host using a cold backup. If you have the licence option 14:DATABASE RECOVERY, then you can recover the Alliance Access database to its latest committed state (including live messages) on a remote system. For more information, see "Database Recovery" on page 165. Where relevant, additional information is provided if you have the licence option 14:DATABASE RECOVERY.
Overview
24.4.1 Recovery Overview

Purpose You can choose to recover the entire Alliance Access software on a different host using a "Cold Backup" system. This requires an active system and a backup system. This recovering the Alliance Access software and its database, and then configuring Alliance Access to run on a different host using the recovered information. Overview 1. 2. Normally, Alliance Access runs on the active system from which you can take daily backups. Upon failure of the active system, you can restore the most recent recovery backups onto the backup system, and continue working from the backup system. You can take daily recovery backups using the backup system. When the active system is running again, you can apply the switch-over procedure in the reverse order to restore the database backup from the backup system onto the active system.
3.
24.4.2 Configure the Active System

Prerequisites On the active system: 1. Install and configure the correct operating system software. For information about the system requirements, see the Release Letter and "Preparation" on page 13. 2. Install Alliance Access, as described in "Installation" on page 32. 3. Install any required Alliance Access patches. Make a note of what has been loaded, because the same patches must also be installed on the backup system.
30 September 2011
183
Configure Alliance Access cold backup 1. 2. 3. Customise the active system installation as required (for example, define operators, routing, message partners, and import RMA authorisation data). Configure the active system for SWIFTNet. See Part B, "Configuring for SWIFTNet" on page 97. Back up the Alliance Access database, see "Backing Up Data" on page 144. Perform this step regularly, for example on a daily basis. If you have the licence option 14:DATABASE RECOVERY, then you can configure your system for database recovery instead of performing a database backup: 1. Activate the database recovery mode of the Alliance Access database. For more information, see "Database Recovery" on page 165. 2. Check and possibly change the trigger for the creation of the database recovery backup. For more information, see "Scheduling Database Recovery Backup" in the System Management Guide. 4. Generate a report of your system configuration, using the Report command in the File menu of the System Administration application. Repeat this step whenever you update your system (for example, after installing a new patch, or changing an IP address of the active system). 5. 6. Continue to work normally with Alliance Access for live operations. Perform regular archives of the Event Journal and Message File. You can schedule automatic archiving from the Event Journal and Message File applications respectively, or perform manual archiving from these applications. Perform regular backups of the Event Journal and Message File archives. You can schedule automatic backups from the System Management application, or perform manual backups from this application.
7.
Notes and recommendations For security reasons, the database backup utility does not back up the Message File and Event Journal. This prevents Alliance Access from processing a message that was processed already, in particular after an old backup was restored. If you have the licence option 14:DATABASE RECOVERY: in case of a full database recovery backup, the content includes all the data present in the database at the time of the backup, except the restored archives or archive backups if the configuration explicitly excluded them. The external database and Alliance Access configuration files are also included in these backups. in case of incremental database recovery backup, the content includes only the changes compared to the previous full or incremental backups. For more information, see "Database Recovery" on page 165. To back up the archives, you must perform the backup from Alliance Access, which stores these archives in a release-independent backup format. This allows you to restore the archives on the current and on any future release of Alliance Access. When you have backed up an archive, the archive may be removed from the database.
184
SWIFT recommends that you archive and back up data on a regular basis: back up the release tree whenever you upgrade the Alliance Access release or you install an Alliance Access patch perform a database backup on a daily basis perform archives of the Message File and Event Journal every week back up the Message File and Event Journal archives every week. Store these backups on separate media, not on the one from which Alliance Access is loaded. These backups must be readily available in the event of a crash of the active system. If you have the licence option 14:DATABASE RECOVERY, then the recovery disks and optionally the archive backups must be readily available in the event of a crash of the active system.
24.4.3 Configure the Backup System

Overview You must configure your backup system (install the same operating system software and define paging space, for example) in the same way as your active system. Configure Alliance Access on your backup system 1. Install Alliance Access using the same release media as for the active system. Assign a different global and local IP address to the backup system. The global IP address is the IP address used within your network environment, as it is known to SWIFT. Use the same Alliance Access Initialisation and Master passwords as those used on the active system. At this stage, there is no need to configure operators, routing, for example, in Alliance Access. When needed, Alliance Access configuration data is restored from database backups, taken from the active system. The $PATH definition for root must be the same for Alliance Access on both systems. To check this, log on as root and type: echo $PATH The result of this command must be the same on both systems. If not, then type: export PATH=$PATH:<missing directory path> 2. After installation, if the range of ports that is defined on Alliance Access for server and messenger is different from the ports range defined on the active system, then update the /usr/swa/alliance_port file. Then, run apply_alliance_ports command to configure the same range of ports for server and messenger on both primary and the backup system. For more information about using this command, see "TCP Configuration for the Alliance Access Server" on page 243. If any patches or release upgrades have been applied to the active system, then ensure that they are also applied to the backup system.
3.
30 September 2011
185
4.
Restore the database backup from the active system. Restore all data sets, including the SWIFTNet Interface Restore set. You restore the database using the saa_dbrestore command. You may disable connectivity when restoring the database. For more information, see "Restoring the Alliance Access Database" on page 153. To disable the startup of the SWIFT connectivity and Alliance Developers Toolkit applications on Alliance Access when starting the servers in Operational mode, you can also prevent the SWIFT Interface Services, SWIFTNet Support Services, or any Alliance Developers Toolkit components from starting by following these steps: 1. Start the Alliance Access servers in Housekeeping mode. 2. Run the System Management application. 3. Select Stop Component from the File menu. The Stop Component window appears. 4. Select the component that you want to stop in this window and click step for other components if needed. Then click Cancel . 5. Restart the Alliance Access servers in Operational mode. Important First restore a database backup from the active system before taking any database backup on the backup system. This procedure restores all of your Alliance Access configuration data, except for the Event Journal and Message File. Empty files are created for these objects. For more information about restoring the database, see "Restoring the Alliance Access Database" on page 153.
Stop
. Repeat this
5. 6. 7.
Start the Alliance Access servers, to validate the installation. Stop the Alliance Access servers. If you use server authentication and a CA certificate was obtained on your active system (using swrpc_keytool), then you may want to use the same certificate on your backup system. In this case, use the saa_configconnection tool to import the certificate onto the backup system. For more information about using this tool, see "saa_configconnection" on page 230. Start the Alliance Access servers. Important If the active system has a logical terminal configured with automatic login, then at server startup on the backup system, the logical terminal automatically attempts to log in. The same is true for automatic activation of emission and reception profiles.
8.
9.
Stop the SIS and SNIS components from the System Management application.
10. Possibly modify the configuration of your backup system for SWIFTNet (see Part B, "Configuring for SWIFTNet" on page 97). For example, this may be necessary if the Alliance Gateway to which the system will to connect is located on another host. 11. Start the SIS and SNIS components from the System Management application.
186
Note
Any changes to ports on the active system must also be made on the backup system.
24.4.4 Switch Over to the Backup System

Procedure 1. 2. Log on to the backup system as Alliance Access administrator. Use the Report command from the File menu of the System Administration application to check the configuration of the backup system. Compare this report with the latest report taken from the active system. Check that the OS release level, paging space allocation, number of user processes, port allocations, Alliance Access release level, and patch level are correct. Restore your most recent backup of the Alliance Access database (taken from the active system) to the same directory on the backup system. Restore all data sets except the SWIFTNet data (the SWIFTNet Interface Restore Set). To restore the database, use the saa_dbrestore tool (with options -w n). For more information about restoring the Alliance Access database, see "Restoring the Alliance Access Database" on page 153. Note This step restores all of your Alliance Access configuration data, except for the Event Journal and Message File. Empty files are created for these objects. If you have the licence option 14:DATABASE RECOVERY, then restore on the backup system the Alliance Access database from the recovery backups available on the recovery backup disk. Use the saa_dbrecovery tool, as described in "saa_dbrecovery" on page 283. 4. If you use server authentication and a CA certificate was obtained on your active system (using swrpc_keytool), then you may want to use the same certificate on your backup system. In this case, use the saa_configconnection tool to import the certificate onto the backup system. For more information about using this tool, see "saa_configconnection" on page 230. Start the Alliance Access servers. Important If the active system has a logical terminal configured with automatic login, then at server startup on the backup system, the logical terminal automatically attempts to log in. The same is true for automatic activation of emission and reception profiles.
3.
5.
6. 7. 8.
Sign on to Alliance Access (as Supervisor - existing passwords apply) and check whether the correct configuration of Alliance Access has been recovered. Stop the SIS and SNIS components from the System Management application. Use the System Management application to restore backups of your Message File and Event Journal archives, as required. Messages and Events which were not included in the archives cannot be recovered.
30 September 2011
187
9.
Verify the SWIFTNet connection details of your logical terminals, and of your SWIFTNet emission and reception profiles. For more details, see Part B, "Configuring for SWIFTNet" on page 97.
10. Start the SIS and SNIS components from the System Management application. 11. Use the SWIFT Interface application to connect to the SWIFT network to check the connection to FIN. Note The first Login and Select may generate a negative acknowledgement (NAK) because of incorrect sequence numbers. To correct this, repeat the Login and Select commands.
12. If you exchange FileAct or InterAct messages, then use the SWIFTNet Interface application to check the connection to SWIFTNet. When all is well, resume normal live operations using your backup system.
188
Replication of Configuration Data
25

Overview This section describes how to replicate configuration data from one Alliance Access instance to another instance. This functionality allows you to: validate the configuration changes of a test system before applying these changes on a production system. easily change the configuration of several production systems that increase the levels of resilience and load balancing. automate repetitive configuration changes. For example, Service Bureaux can use this functionality to add new customers or BICs. No additional licence is required to replicate configuration data.
25.1
Configuration Replication
Alliance Access provides the following command-line tools to replicate configuration data from one Alliance Access instance to one or several target Alliance Access instances: The export tool (saa_export) uses a parameter file which defines the type of data to export and exports the configuration data from the source Alliance Access instance to an export file. The import tool (saa_import) uses the configuration data in the export file to update the configuration of the target Alliance Access instance. You run the export tool locally on the source instance and the import tool locally on any target instance:
Description
Export tool
Import tool
Access
Export file (User modifiable file - text format)
Access
When you run the export tool, the configuration data that matches the criteria defined in the export parameter file is transferred to the export file. The export file is in XML format. Before running the import tool on the target Alliance Access instance, you can edit in any text editor the export file that the export tool produced. This allows you to customise the configuration in the target instance. For example, you can replace Test and Training logical terminals by Production logical terminals before replicating a test instance configuration into a production instance.
30 September 2011
189
D0540183
Parameter file validation The parameter file used during the export or import operation is validated against schema definitions (.xsd files). These .xsd files are located in the following directory:
<Alliance installation directory>/bin/xsd
Configuration data suitable for replication An entity is a component of Alliance Access and all occurrences of that component within the Alliance Access instance. For example, the Unit entity indicates all Unit occurrences defined in Alliance Access. Other examples of entities are operator, exit point, emission profile. All the entities for which you can replicate configuration data are listed in "Entities Eligible for Export and Import" on page 192. You can use the import and export tools to replicate one or several entities at a time to a target Alliance Access. Alliance Access does not support the replication of operational entities, such as, calendar entries, events, or messages, or the entities that it configures automatically either at installation time or at relicensing time, such as, Destinations. Sensitive data Some entities have parameters that may contain sensitive data. You can choose whether to export sensitive data to the export file. For more information, see "Handling the Export and Import of Sensitive Data" on page 191. The data in the export file is not protected by a signature. Ensure that the export file is properly secured, especially if it contains sensitive data, such as the digests for operator passwords. Permissions The default operator profile, R7.0_Import_Export, contains the permissions required to export and import configuration data using the configuration replication tools. You can assign the R7.0_Import_Export profile to the software owner (all_adm) through the "Software Owner Profile" security parameter. If you do not assign this profile to the software owner, then you must run the tools with the -user, or -application, and -password options, to provide the user credentials. For more information about the permissions required to export or import specific entities, see "Entities Eligible for Export and Import" on page 192. In all of the cases below, the user must have the profile R7.0_Import_Export assigned:
User account all_adm Software Owner Profile is defined? Y N Any other OS account (operator) N Specify -user, or -application, and -password Optional Mandatory Mandatory
190
25.2
Handling the Export and Import of Sensitive Data

You can export sensitive data, that is, the operator passwords, using the exportsensitivedata parameter with the saa_export command. You can export an operator's password if the Authentication Method for the operator is Local If the same entities exist in both the source and the target Alliance Access instance, then you can update the configuration of the entities in the target instance using the -overwrite parameter with the saa_import command.
Overview
Operator passwords If you export sensitive data using the -exportsensitivedata parameter with the saa_export command, then the following results are achieved:
Action
exportsensitiveda ta specified
Result
Export Import
Y Y
The password information (password digest) is added to the export file. The password information (password digest) is added to the entities in the target instance.
Operators occurrence exists in target Alliance Access If the operator entity exists in the target instance and if its Authentication Method is Local, then the import process varies depending on whether a password is present in the import file. If a digest exists for the password, then the Alliance Access instance: creates the operator with the existing password from the Import file. marks the password of the operator as being expired, which will require the operator to reset the password the next time the operator logs on. If no digest exists for the password, then the Alliance Access instance: leaves the operator password unchanged. logs this action in the report file with the occurrence reference of the operator entity. Operators occurrence does not exist in target Alliance Access If the operator entity does not exist in the target instance and if its Authentication Method is Local, then the Import process varies depending on whether a password is present in the Import file. If a digest exists for the password, then the Alliance Access instance: creates the operator with the existing password from the Import file. marks the password of the operator as being expired, which will require the operator to reset the password the next time the operator logs on.
30 September 2011
191
If no digest exists for the password, then the Alliance Access instance: sets a system-generated password as the value of password for the operator. logs the action in the report file with the occurrence reference of the operator entity. If -exportsensitivedata not specified
Action
exportsensitiveda ta specified
Result
Export Import
N N
The password information (password digest) is not exported to the export file. If a new operator is added, then Alliance Access generates a password and assigns it to the operator. If the operator exists in the target instance, then the passwords are not changed.
25.3
Entities Eligible for Export and Import

Entity Configuration Correspondent Permission required for export System Management Correspondent Info - Open/ Print Correspondent Details Permission required for import System Management: Modify Configuration Parameter Correspondent Information: Open/Print correspondent details and Add correspondent, and/or Modify correspondent details Distribution List System Management System Management: Add Distribution List, and/or Modify Distribution List Emission Profile SWIFTNet Interface: Open/ Print Emission Profile (1) SWIFTNet Interface: Open/Print Emission Profile Add Emission Profile, and/or Modify Emission Profile Schedule Emission Profile(2), and/or Disable Emission Profile auto Enable Emission Profile auto Event Distribution System Management System Management: Modify Event List
Filtering fields
192
Entity Exit Point
Permission required for export Application Interface: Open/ Print Exit Point (3)
Permission required for import Application Interface: Open/Print Exit Point(3) Add Exit Point, and/or Modify Exit Point
File Template(5) Input Channel
Mesg Creation SWIFTNet Interface: Open/ Print Input Channel (4)
Mesg Creation: Add/Mod/Rem Template SWIFTNet Interface: Adopt Input Channel and Open/Print Input Channel(4)
Logical Terminal
SWIFT Support
SWIFT Support: Add LT, and/or Modify LT Set default Live, and/or Set default T&T
Logical Terminal Definition
SWIFT Interface: Own Destination List (6)
SWIFT Interface: Modify LT, and Add Action, and/or Modify Action, and/or Remove Action, and/or Enable / Disable Auto Mode, and/or Enable / Disable Reconnect , and/or Own Destination List(6)
Message Partner
Application Interface: Open/ Print Partner (7) Access Control: Files on Server
Application Interface: Open/Print Partner(7) Add Partner, and/or (8) Modify Partner(8) Access Control: Files on Server
Operator
Security Definition
Security Definition: Add Operator, and/or Modify Operator
Operator Profile
Security Definition
Security Definition: Add profile, and/or Modify profile
30 September 2011
193
Entity Output Channel
Permission required for export SWIFTNet Interface Open/ Print Output Channel (4)
Permission required for import SWIFTNet Interface: Adopt Output Channel and Open/Print Output Channel(4)
Reception Profile
SWIFTNet Interface: Open/ Print Reception Profile RT and Open/Print Reception Profile SnF (9)
SWIFTNet Interface: Open/Print Reception Profile RT,(9) and/or Open/Print Reception Profile SnF Add Reception Profile, and/or Modify Reception Profile and Schedule Reception Profile,(2)and/or Disable Reception Profile auto or Enable Reception Profile auto
Routing Keyword
Routing
Routing: Add Keyword, and/or Modify Keyword
Routing Keyword Definition
SWIFT Support
SWIFT Support: Add Keyword, and/or Modify Keyword
Routing Rule(10)
Routing: Open Routing Point

(11)
Routing: Open Routing Point(11) Add Rule, and/or Modify Rule Default Rule (12)
Routing Schema
Routing
Routing: Add Schema, and/or Modify Schema
SWIFTNet Connection System Queue Unit
SWIFTNet Support: SNL Handling (13) System Management Security Definition
SWIFTNet Support: SNL Handling (13) System Management: Modify Queue Security Definition: Add Unit, and/or Modify Unit
194
Entity User Queue
Permission required for export System Management
Permission required for import System Management: Add Queue, and/or Modify Queue
(1) Alliance Access exports or imports only the Emissions profiles that are configured for the explicitly allowed the services or BICs, or that are not explicitly prohibited for those services or BICs. The R7.0_Import_Export profile is configured with 'Prohibited: None'. (2) To import scheduled actions (adding or possibly overwriting existing ones), then the operator must have the permissions to add actions and/or modify actions and/or remove actions as required by the specific import needs. The R7.0_Import_Export profile is configured with 'Add / modify / remove actions allowed'. (3) Alliance Access imports or exports only the exit points that are explicitly allowed (or not explicitly prohibited). The R7.0_Import_Export profile is configured with 'Prohibited: None'. (4) Alliance Access imports or exports only the Input Channel or Output Channel occurrences that belong to the destinations (BIC8) that are explicitly allowed (or not explicitly prohibited). The R7.0_Import_Export profile is configured with 'Prohibited: None'. (5) Permissions for file templates are not included in the default R7.0_Import_Export profile. This entity is available for import and export only from Alliance Access 7.0.30. (6) Alliance Access imports or exports only the logical terminal (Logical Terminal Definition) occurrences that belong to the destinations (BIC8) that are explicitly allowed (or not explicitly prohibited). The R7.0_Import_Export profile is configured with 'Prohibited: None'. (7) Alliance Access imports or exports only the message partner profiles that are explicitly allowed (or not explicitly prohibited). The R7.0_Import_Export profile is configured with 'Prohibited: None'. (8) LAU keys are not imported. Therefore, there are no constraints. (9) Alliance Access imports or exports only the store-and-forward (SnF) reception profiles that are configured for explicitly allowed BICs (or for BICs that are not explicitly prohibited). The R7.0_Import_Export profile is configured with 'Prohibited: None'. (10) Alliance Access imports or exports only the user-defined routing rules. It does not import or export internal or default routing rules. (11) Alliance Access imports or exports only the routing rules that relate to routing points that are explicitly allowed (or not explicitly prohibited). The R7.0_Import_Export profile is configured with 'Prohibited: None'. (12) To change the default action for a routing rule, Alliance Access must be operating in housekeeping mode. (13) Alliance Access imports or exports only the SWIFTNet connections where the Connection Handling permission is set to 'Y'. The R7.0_Import_Export profile is configured with SNL Handling-Connection Handling set to 'Y'.
Settings for LAU keys

Action Export Import Result LAU keys are never exported. Therefore, the LAU keys for Message Partner entities and SWIFTNet Connection entities are not included in the export file. New entity You must define the LAU keys after the import is completed because a new entity is added in the target instance without LAU keys. LAU keys remain as they are defined already in target instance.
Existing entity
30 September 2011
195
25.4
Status of Entities Before and After Import

Entities have dependencies between themselves or some entities refer to other entities. For example, an Operator entity refers to a Profile entity and a Unit entity. A Message Partner entity refers to a Profile entity. The Message Partner, Operator, and Routing Rule entities refer to Unit entities. During an import, ensure that the entities that are referred to by imported entities exist in the target Alliance Access instance or are imported as part of the same import command and these entities are in the same export file. For example, when you import Operator entities, the Units to which the operators belong must either exist in the target instance or be part of the same export file as the operators being imported. In addition, the Unit to which an operator belongs must be in an approved state in target instance. If it is not, then import will fail. The following diagram shows the dependencies between entities for import and export actions:
Entity dependencies
For example, the red arrows in the diagram show the following relationships: Routing Keyword requires Routing Keyword Definition Logical Terminal requires Logical Terminal Definition Status of entities before and after export This section lists the entities and the status they must have in the target Alliance Access before the import and their status after the import is complete.
196
Any invalid status stops the export or the import process. Important If Alliance Access cannot add an entity, then it exports only the fields that are required to identify the occurrence of the entity in the target instance, and the fields that can be updated.
New occurrence in target instance? Prerequisites Status in target instance Before import ADK Storage parameter is readonly (left unchanged during import) Country and Correspondent type fields are read-only (left unchanged during import Distribution, if equal to Fixed, then it is read-only (left unchanged during import) Assigned Message Partner field is read-only (left unchanged during import) The server must be running in operational mode. Add or update = input channel adoption The import tool skips updates. The server must be in running in housekeeping mode. Before update: SIS component must be stopped After import -
Entity name
Configuration
Correspondent
Distribution List Emission Profile Event Distribution
Y Y -
Disabled -
Disabled -
Exit Point
File Template Input Channel
Y Y
Logical Terminal Logical Terminal Definition Message Partner Operator
Y Y Y
Disabled Disabled
Disabled Approved status: Unapproved and Enable status: disabled All operators using the updated operator profile get disabled and unapproved -
Operator Profile
No operator using that operator profile can be logged on
Output Channel
Add or update = output channel adoption The import tool skips updates. -
Reception Profile
30 September 2011
Disabled
Disabled
197
Entity name
New occurrence in target instance? Y Y
Prerequisites
Status in target instance Before import After import -
Routing Keyword Routing Keyword Definition Routing Rule
In some cases, user routing rules existing in the target instance are deleted before adding the occurrences present in the export file.(1) Before a routing rule is added or updated, the assigned routing schemes must be inactive, or else the server must be running in housekeeping mode. After add or update, the assigned routing schemes become unapproved. -
Routing Schema
Any
Add: unapproved Update: remains unchanged -
SWIFTNet Connection System Queue Unit
Before add or update: SIS and SNIS components must be stopped -
Approval status: unapproved (add) or remains unchanged (update) -
User Queue
(1) For example, if the Full indicator is present in the parameter file, and if the routing rule exists in the target instance, then that routing rule is deleted before the new routing rule is created in the target instance.
25.5
Parameter File for Configuration Replication

You use the export parameter file to specify the entity types and entity occurrences that must be exported. You can specify the following details in the export parameter file: The type of entity to export. You must define at least one type of entity.
Description
198
For more information about the entities that you can export and import, see "Entities Eligible for Export and Import" on page 192. For each entity type, you can specify additional filtering criteria to export specific entity occurrences. The filtering criteria are optional. If no filtering criteria are specified, then Alliance Access exports the configuration data of all the entities specified in the parameter file. The filtering criteria fields depend on the entity type. The unique identifier of the entity in the database is always available as a filtering criterion. Sample parameter files Two sample export parameter files are provided in the $ALLIANCE/samples directory: saaExportParam-Complete.xml, listing all the entities that can be exported and all possible filtering criteria saaExportParam-Basic.xml, listing all the entities that can be exported, without any filtering criteria. You can copy and update a sample export parameter file to match your own export criteria. That is, remove some entities that must not be exported or add filtering criteria to some entities to restrict the export. For more information, see "Filtering fields" on page 192. Syntax of the parameter file The following is the syntax to use in the parameter file:
<entities>  <entity name='<entity_name>' <filterset> <filter attrib='<Field_name>' value='<field_value>' [op='<operator>'] /> > </entity> </entities>
You can combine the filtering criteria for several fields by using: a logical OR. To do this, specify multiple <filterset> elements. Example:
 <entity name='Correspondent'> <filterset> <filter attrib='BIC11' value='SAAABEBBXXX' /> </filterset> <filterset> <filter attrib='Update on BIC Load' value='Yes' /> </filterset> <filterset> <filter attrib='Correspondent Definition' value='External' /> </filterset> </entity>
a logical AND. To do this, specify multiple <filter> elements.
30 September 2011
199
Example:
 <entity name='Logical Terminal'> <filterset> <filter attrib='BIC8' value='SAAABEBB' /> <filter attrib='LT Code' value='A' /> </filterset> </entity>
Also, for each filtering field, you can provide a wildcard value or a set of values, each of them allowing to import an occurrence. Syntax description To specify a list of entity or entities to export, and any optional filtering criteria, use the following elements and attributes in the parameter file:
Element
<entities>  <entity name='<entity_name>' >
Description Denotes the start of the parameter file. Comments about a specific entity. The name of an entity. The 'entity_name' can be used only once in the file, and it must be an entity that is eligible for configuration replication(1). The criteria by which to select the entities to export. If you specify multiple <filterset> elements, then a logical OR is applied when forming the selection criteria. A <filterset> cannot have two filters with the same attrib and op If you specify multiple <filter> elements, then a logical AND is applied when forming the selection criteria: attrib - a field by which you can filter value - value of the field(3). op - SQL operator For a list of values, see "Op values" on page 201.
Mandatory? Y N Y
<filterset>
<filter attrib='<Field_name> ' value='<field_value> ' [op='<operator>'] /> >
(2)
</filterset> </entity> </entities>
Denotes the end of the filterset definition. Denotes the end of the entity definition. Denotes the end of the parameter file.
N Y Y
(1) You can replicate the configuration data for the entities that are listed in the section, "Entities Eligible for Export and Import" on page 192. (2) If <filterset> is used, then <filterset> must include at least one <filter> element. (3) Use either single (') or double quotes ("), irrespective of the type of data.
200
Op values The following table outlines the values of the Op operator that you can use in the parameter file for exporting or importing data:
operator
EQ
Description Equal to (=) The default is EQ (equal). Greater than (>) Greater than or equal to (>=) Not equal to (!=) Less than or equal to (<=) Less than (<) Same as EQ (equal) but you can use wildcards, such as% or _ Same as NE (not equal) but you can use wildcards, such as% or _ The item is contained in a list The item is not contained in a list
GT GE NE LE LT LIKE NOT LIKE IN NOT IN
Example of parameter file with filtering criteria The following shows an example of a parameter file with filtering criteria for the entities, Routing Rule, Configuration, and Operator Profile:
<entities>  <entity name='Routing Rule'> <filterset> <filter attrib='Routing Point Name' value='_SI_from_SWIFTNet'/> </filterset> <filterset> <filter attrib='SeqNo' value='200'/> </filterset> <filterset> <filter attrib='Assigned Scheme' value='AB'/> </filterset> <filterset> <filter attrib='Last Update Timestamp' value='30/04/2010 13:30:55' op='GE'/> </filterset> </entity>  <entity name='Configuration'> <filterset> <filter attrib='Component' value='BSS'/> </filterset> <filterset> <filter attrib='Object' value='Display Format'/> </filterset> <filterset> <filter attrib='Parameter' value='Amount'/> </filterset> </entity> </entities>
30 September 2011
201
 <entity name='Operator Profile'> <filterset> <filter attrib='Name' value='R7.0_SuperKey' /> <filterset conjunction='OR'> <filter attrib='Name' value='R7.0_RMA%' op='LIKE' /> <filter attrib='Name' value='R7.0_MsgEntry' /> </filterset> </entity>
Filtering criteria for correspondents Use the following filtering criteria to export BICs:
To export BIC8 BIC11 Test and Training BICs Internal Correspondents Correspondents that cannot be modified by the BIC upload Use the BIC11 filter attribute and positions 9 - 11 set to xxx the BIC11 filter attribute and positions 9 - 11 set to *** the BIC11 filter attribute and position 8 set 0 the Correspondent Definition filter attribute set to
Internal
the Update on BIC Load filter attribute set to No
25.6
Fields Eligible for Export and Filtering

The following table outlines the fields that you can export for each entity in Alliance Access. It also shows the fields that you can use to filter the exported data. For more information about how to use the filtering, see "Parameter File for Configuration Replication" on page 198.
Description
Fields for export and filtering You can filter on one or several of these exported fields:
Entity name Configuration Exportable fields Component Object Parameter Value Filter on field?
202
Entity name Correspondent
Exportable fields Address Branch info City name Comment Correspondent type Correspondent definition Correspondent status Country Institution full name Institution (BIC11) Location POB location POB number Preferred language Profile Sub-type Selected integrated applications and their details Update on BIC load
Filter on field?
Distribution List
Name Operators Selected operators Selected internal correspondents SNMP server IP address or port number
30 September 2011
203
Entity name Emission Profile
Exportable fields ACTIONS = Action ID, Day profile, Time, Action Calendar Delivery mode Delivery notification queue Delivery notification required Input channel Manual / Automatic mode Messaging service Name Non repudiation required Retry limit Requestor DN Schedule category Sequence 1: SWIFTNet connection name, Use specific Authoriser DN, [Authoriser DN] Sequence 2: SWIFTNet connection name, Use specific Authoriser DN, [Authoriser DN] Sequence 3: SWIFTNet connection name, Use specific Authoriser DN, [Authoriser DN] Sequence 4: SWIFTNet connection name, Use specific Authoriser DN, [Authoriser DN] Service name Signing required Use input channel Window size
Filter on field?
Event Distribution
Alarm Component Configuration management Distribution Distribute alarm Event number Type To distribution list
204
Entity name Exit Point
Exportable fields Assigned to message partner Display rules allowed Maximum message age Modify rules allowed Name Processing order Queue threshold Selected Valid Routing Targets
Filter on field?
30 September 2011
205
Entity name File Template
Exportable fields Authorisation Notification Authoriser DN Comment Copy Direction File Description File Info File Path (only if File in User Space has the value true) File In User Space Header Info Logical File Name Name Non Repudiation Notification Requested Overdue Warning Delay Overdue Warning Time Possible Duplicate Priority Reception Profile Requestor DN Responder DN Request Type Service Name Signature Method Signature Level Third Party List Transfer Description Transfer Info Unit User Reference
Filter on field?
Input Channel
Name
206
Entity name Logical Terminal
Exportable fields BIC8 = Destination name LT Code Master BIC for T&T (for Test and Training LTs only) MstvId Window Size
Filter on field?
Logical Terminal Definition(3)
Auto reconnect BIC8 = Destination name Delivery subsets LT Code Operation mode Scheduling category, Calendar, Action ID, Day profile, Time, Action Selection mode Sequence 1: SWIFTNet Connection name, Use specific Authoriser DN, [Authoriser DN], Use specific CID Signing DN, [CID Signing DN] Sequence 2: SWIFTNet Connection name, Use specific Authoriser DN, [Authoriser DN], Use specific CID Signing DN, [CID Signing DN] Sequence 3: SWIFTNet Connection name, Use specific Authoriser DN, [Authoriser DN], Use specific CID Signing DN, [CID Signing DN] Sequence 4: SWIFTNet Connection name, Use specific Authoriser DN, [Authoriser DN], Use specific CID Signing DN, [CID Signing DN]
30 September 2011
207
Entity name Message Partner
Exportable fields Allowed direction Always transfer MAC / PAC Batch file validation Build unique file transfer reference Connection method Description DETAILS = details of any type of Connection Method Disposition Format of original message Increment sequence number across sessions Local authentication required Message emission format Message in Message modification allowed Name Original message Profile name Reply Routing code transmitted Selected exit points Send original message Transfer PKI signature Transfer UUMID Unit to be assigned Validation error code Validation level
Filter on field?
208
Entity name Operator
Exportable fields Application Authentication method Display password Full name LDAP user identifier Name(4) Operator Profile(4) Selected allowed profiles Selected assigned units Selected Delegated Destinations Selected Delegated Profiles Selected Delegated Units Unit(4)
Filter on field?
Operator Profile
All Permission Details (if any) Name Selected applications Selected functions
Output Channel Reception Profile
Name ACTIONS = Action ID, Day profile, Time, Action Calendar Delivery mode Manual / Automatic mode Name Queue name Schedule category Selected subset names Sequence 1: SWIFTNet connection name, Use specific Authoriser DN, [Authoriser DN] Sequence 2: SWIFTNet connection name, Use specific Authoriser DN, [Authoriser DN] Sequence 3: SWIFTNet connection name, Use specific Authoriser DN, [Authoriser DN] Sequence 4: SWIFTNet connection name, Use specific Authoriser DN, [Authoriser DN] Window size
30 September 2011
209
Entity name Routing Keyword
Exportable fields Description Name Type
Filter on field?
Routing Keyword Definition
Column range from Field tag Line range from MstvId Name Selected messages Subfield
210
Entity name Routing Rule(1)
Exportable fields Action on Assigned schemes Condition on Description Last update timestamp(2) Message New instance action New instance addressee New instance append intervention New instance free text intervention New instance notification type New instance priority New instance Routing code New instance type New instance Unit New instance selected valid target point Routing Point Name Selected function result SeqNo Source instance action Source instance append intervention Source instance free text intervention Source instance notification type Source instance priority Source instance Routing code Source instance selected valid target point Source instance type Source instance Unit
Filter on field?
Routing Schema
Description Name
30 September 2011
211
Entity name SWIFTNet Connection
Exportable fields FileAct port number FileAct SSL Name Hostname Port number SSL CA Certificate SSL Certificate SSL settings LAU settings
Filter on field?
System Queue
Name Queue Threshold Modify rules allowed Display rules allowed Selected Valid Routing Targets Maximum message age
Unit
Full description Name
User Queue
Display rules allowed Maximum message age Modify rules allowed Name Selected Valid Routing Targets
(1) Alliance Access exports user-defined routing rules only. It does not export or import internal or default routing rules. (2) You can use this as a filtering criterion to export only the entities that have a Last update timestamp that meets a specific condition. You can use a date/time interval condition to export entities that have been last updated during that date/time interval. For example, you can use it to export only entities that have been updated after a specific start date/time. (3) The specified delivery subsets must exist on the target system for the import to be successful. (4) You can filter on one or several of these fields: Name, Unit, Operator Profile
25.7
Export Configuration Data

Before launching the export tool, check the following: The Alliance Access server is running in operational mode. The export parameter file is created and stored in a directory of your choice. For more information, see "Parameter File for Configuration Replication" on page 198.
Prerequisites
212
To export the configuration data 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_export command. For command location and syntax, see "saa_export" on page 287. The export process starts. The progress of the export process is displayed on the screen as the different entity occurrences are exported and stored in the export file. After the export process is completed, the following message appears. Export completed Total no. of occurrences exported: 20 CONFIGURATION REPLICATION (EXPORT) - END Start of export and end of export are logged as events in the Event Journal. Note Note If the import fails, check the report file. You can export multiple entities in a single export command. An overall counter of all exported occurrences (across entity types) is available in the report file and the Event Journal.
25.8
Import Configuration Data

Before launching the import tool, check the following: The Alliance Access server is running in the required mode (operational or housekeeping) for the import. This prerequisite depends on the entity to be imported. During the import, if you want to update some entity occurrences, then check whether the entities are in the appropriate status. For more information about the required status, see "Status of Entities Before and After Import" on page 196. If you are using message partners with the Print connection method, before importing the configuration data, verify in the export file that the printer name is less than or equal to 40 characters. An operator profile must be disabled for the import tool to be able to update it. Therefore, no operator with that profile can be logged on when the tool is launched. When an operator launches the import tool, that operator must ensure that the export file does not contain his/her operator profile. In addition, the tool cannot import the operator profile that is assigned to the Software Owner Profile security parameter. The operator profile that is assigned to the Software Owner Profile security parameter is always considered as being logged on and must not appear in the import file. The target Alliance Access is licensed according to the entities that you import.
Prerequisites
30 September 2011
213
Important
If the import command fails to import any entity occurrence present in the export file, then the import process stops. However, the entity occurrences (present in the export file) that have successfully been imported before the failure are not rolled back. Therefore, in this case, it is recommended to perform the following steps: Back up the database Import the configuration data If the import process fails after having imported at least one occurrence successfully, then stop Alliance Access restore database from the backup taken in the first step restart Alliance Access.
Import options The configuration specified in the input export file is imported into the target Alliance Access instance according to the input parameters. Some entities must have a specific status before they can be updated by the import command (for example, Message Partner must be disabled). For more information, see "Status of Entities Before and After Import" on page 196. For example, if a Routing Rule entity is exported with no filtering or with no Name specified, then the Full indicator is added to the Export file: <ns2:Full>True</ns:Full>. During an import action, if the Full indicator is present in the parameter file, then Alliance Access replaces all the routing rules in the target instance with the rules that are defined in the export file. If an entity occurrence is present in the export file and is not present in the target Alliance Access instance, then the entity occurrence is added into the target instance. For information about importing sensitive data, see "Handling the Export and Import of Sensitive Data" on page 191. Tip If occurrences cannot be added for a specific entity (for example, a configuration entity), then the import process skips the occurrence and continues with the next occurrence. For more information, see "Entities Eligible for Export and Import" on page 192. The overwrite parameter You can force an update to the configuration data in the target Alliance Access instance by using the overwrite parameter in the import command.
214
For each entity occurrence present in the export file, and for the corresponding entity occurrence present in the target Alliance Access instance: When the import command is executed with the -overwrite parameter, then the data in the export file overwrites the data in the target instance even if the values were identical before the export process. When the import command is executed without the -overwrite parameter, then the data in the export file for that entity occurrence is ignored or skipped and the occurrence in the target instance remains unchanged. If the Full indicator is present in the Export file (<ns2:Full>True</ns:Full>), then the overwrite parameter is ignored during an import. To import the configuration data 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_import command. For command location and syntax, see "saa_import" on page 288. The entity occurrences are added or updated into the database of the target Alliance Access instance. The progress of the import process is displayed on the screen as the different entities are added or updated. Once the import process is completed, the following messages appear:
Import completed Total no. of occurrences processed: 20 (Added: 0) (Updated: 20) (Skipped: 0) CONFIGURATION REPLICATION (IMPORT) - END
4.
After the import is complete, define LAU keys if new Message Partner entities or SWIFTNet Connection entities were created in the target instance. If the import fails, check the report file.
Note
25.9
Report File for Configuration Replication

Alliance Access creates a report file when you run the configuration replication tools, saa_export and saa_import. The report file for saa_export contains an exhaustive list of the occurrences that were skipped or exported. It also contains warning messages related to the export, for example, if errors occurred while handling sensitive data. The report file for saa_import contains an exhaustive list of the occurrences that were skipped or imported, that is, added or updated in the target Alliance Access instance. The file also contains warning messages related to the import, for example, if errors occurred while handling sensitive data or the import was not completed successfully.
Description
30 September 2011
215
Additional notes about the file: The file does not contain any password information. The content in the file is overwritten with the new logs created during the export process. The file is not deleted when the product is removed. You can specify a name and location for the report file using the -reportfile parameter. Name and location of report file If you do not specify this parameter, then the tool creates a report file in the <Alliance installation> directory with the name:
For export: For import: export<timestamp>.log import<timestamp>.log where <timestamp> indicates the date and time at which the command was run. The format for the date is yyyymmdd followed by T and the time hhmmss, based on the 24-hour format.
216
Integration of Operational Data with Third-Party Applications
26
26.1
Integration of Operational Data with ThirdParty Applications

Overview of Operational Integration
The Operational Integration functionality provides command line tools to help integrate the monitoring and management of Alliance Access entities into third-party applications. Operational monitoring The monitoring tool extracts the monitoring information from Alliance Access based on a specific list of entities and fields that are provided through a parameter file. The monitoring information about the entity occurrences (such as the status of an entity) is stored an XML file. The information can be transferred to other applications that monitor operations. Operational management The management tool performs actions on Alliance Access entities based a list of specific actions that are provided through a parameter file. An exit code provides the results of the management actions which the tool performed. The tool manages operations, such as enabling or disabling a message partner, logging on to a logical terminal, or logging off from a logical terminal. In addition, an operator can launch the tool manually, or from a scheduler application that is running outside Alliance Access. Entities The term "entities" refers to all defined occurrences of an entity of a specific type. For a list of entities, see "Entities Eligible for Operational Monitoring" on page 221 and "Entities Eligible for Operational Management" on page 228.
Overview
26.2
Permissions for Launching Operational Integration Tools

The Alliance Access software owner (all_adm) or any operating system account (operator) defined in the system can launch the tools.
Permission required
Software Owner Profile The permissions for the user that runs the tools depends on the value of the Software Owner Profile security parameter, as follows: Software Owner Profile is defined for all_adm, then it is optional to provide the user, or application, name and password. Software Owner Profile is not defined for all_adm, then it is mandatory to provide the user, or application, name and password to run the command.
30 September 2011
217
If any other operating system account launches the tool, then it is mandatory to provide the user, or application, name and password. Depending on the permissions, the operator (of type Human or Application) can run the command. The following table outlines in more detail how the parameter influences the permissions:
Command launcher Software Owner Profile is defined Specify user, or application, name and password in command Optional User credentials
all_adm
Yes
If user, or application, name and password are not provided: all_adm If user, or application, name and password are provided: operator
No
Mandatory
The user or application name, and the password must be provided to run the command. The user or application name, and the password must be provided to run the command.
Any other OS account (operator)
No
Mandatory
For more information about the Software Owner Profile parameter, see the Security Guide.
26.3
Operational Monitoring
26.3.1 Parameter File for the Monitoring Tool

Purpose A parameter file contains the entity types and the selection criteria used to define the monitoring scope. The file is in XML format. You can find a sample parameter file that contains all the entities for operational monitoring in the directory $ALLIANCE/samples. You can copy and update this file to match your own criteria. Validation of the parameter file The parameter file is validated against XML schema definitions (.xsd files). These .xsd files for each entity are located in the following directory:
Scope of monitoring For each entity type, one of the following options are applicable for the selection of entity occurrences to monitor:
Scope of monitoring All Summary Description Monitor all occurrences of the entity type are monitored. Provide the monitoring information in summary format for an entity type. Summary information is applicable only when monitoring an operator session.
218
Scope of monitoring Exception Selection
Description Monitor all occurrences in exception state for that entity type. Monitor all occurrences that match the user criteria for the entity type.
Structure of the parameter file

<MonitorEntities>       <entity name="Logical Terminal"></entity>  <entity name="Logical Terminal"> <LT>SAAABEBBB</LT> <LT>SAABBEBBB</LT> </entity>  <entity name="Logical Terminal" scope="Selection"> <LT>SAAABEBBB</LT> <LT>SAABBEBBB</LT> </entity>  <entity name="Logical Terminal" scope="Exception"></entity>  <entity name="Message Partner"> <Name>FileInput</Name> </entity>  <entity name="Message Partner"> <Status>ABORTING</Status> <Status>CLOSED</Status> </entity>  <entity name="Message Partner" scope="Exception"></entity>  <entity name="Queue"> <Name>XYZ</Name> </entity>  <entity name="Queue" scope="Exception"></entity>  <entity name="Emission Profile"></entity>  <entity name="Emission Profile" scope="All"></entity>  <entity name="Emission Profile" scope="Selection"> <Name>saaabebb_rma</Name> <Name>saabbebb_rma</Name> </entity>  <entity name="Emission Profile" scope="Selection"> <Enabled>true</Enabled> </entity>  <entity name="Emission Profile" scope="Selection"> <Enabled>false</Enabled> </entity>  <entity name="Emission Profile" scope="Selection"> <SessionStatus>ACTIVE</SessionStatus>
<SessionStatus>ACTIVATING</SessionStatus> <SessionStatus>DEACTIVATING</SessionStatus> <SessionStatus>INACTIVE</SessionStatus> <SessionStatus>INTERRUPTED</SessionStatus> </entity>  <entity name="Emission Profile" scope="Exception"></entity>   <entity name="Reception Profile"></entity>  <entity name="Reception Profile"> <Name>saaabebb_rma</Name> <Name>saabbebb_rma</Name> </entity>  <entity name="System Resource"></entity>  <entity name="System Resource" scope="Exception"></entity>  <entity name="Process"></entity>  <entity name="Operator Session"></entity>  <entity name="Operator Session" scope="Summary"></entity>  <entity name="File Transfer"></entity> </MonitorEntities>
26.3.2 Extract the Data for Operational Monitoring

Purpose The monitoring tool saa_monitor extracts data for operational monitoring from Alliance Access based on a specific list of entities and fields that are provided through a parameter file. The information can be transferred to other applications that monitor operations. Prerequisites Before launching the command, ensure that: The tool is run locally on the Alliance Access instance that you are monitoring. Note If you want to launch the tool remotely, then you are responsible for ensuring that the remote implementation is secure.
the Alliance Access server is running in Operational mode. a monitor parameter file is available, which defines the monitoring scope. For more information, see "Parameter File for the Monitoring Tool" on page 218. To extract the data 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_monitor command (for details, see "saa_monitor" on page 293).
220
The monitoring information about the entity occurrences is stored an XML file, which is called the monitor output file. An exit code provides feedback about the results of the command. Tip Note You can use the Enter key to stop the monitoring. The monitoring tool uses minimal Alliance Access resources even if it is used intensively.
26.3.3 Entities Eligible for Operational Monitoring

Entities eligible for monitoring The following entities are eligible for operational monitoring: file transfer logical terminal message partner operator session process queue SWIFTNet profile system resource
30 September 2011
221
Scope of monitoring data The following table outlines the scope of operational monitoring and the fields that can be monitored:
Entity name Scope of Monitoring All or Exception or Selection Fields for selection of occurrences LT or Status Monitored fields
Logical Terminal
Logical Terminal (LT) Status Mode Urgent (U) Normal (N) System Messages in Queue (S) Sent Received Connection name User-controlled sent counter(1) User-controlled received counter(1) Exception indicator In exception timestamp
Message Partner All or Exception or Selection
Name or status or Session Status
Name Status Session status Session number Queued Sent Received User-controlled sent counter(1) User-controlled received counter(1) Exception indicator In exception timestamp
222
Entity name
Scope of Monitoring All or Exception or Selection
Fields for selection of occurrences Name
Monitored fields
Queue
Name Entries Reserved Overdue Message partner Status Age of the oldest message instance in queue Exception indicator In exception timestamp Throughput information (Overflow count, entry per second, exit per second, trend, delay (optional - only in case of flow control)
SWIFTNet Profile
All or Exception or Selection
Name or Enabled or Session status
Name Input / Output (I / O) Enabled (True or False) Status Session status Mode Urgent (U) Normal (N) Sent Received Connection name User-controlled sent counter (emission profile only)(1) User-controlled received counter (reception profile only)(1) Exception indicator In exception timestamp
System Resource
All or Exception
NA
System resource name and type(2) Value Exception indicator In exception timestamp
30 September 2011
223
Entity name
Scope of Monitoring All
Fields for selection of occurrences NA
Monitored fields
Process
Component Description Started by Process Identification Number (PID) Thread ID (TID) Display (that is, hostname) PName (Process name) Status Stoppable Client address
Operator Session
All
NA
Operator Operator type Remote IP Expiration Session type
Summary
NA
Count of human operator sessions Count of application operator sessions
224
Entity name
Scope of Monitoring All
Fields for selection of occurrences NA
Monitored fields
File Transfer
Input / Output (I / O) Transfer reference Correspondent Request type User reference Progress Start date and time Profile name Service name Network priority Logical file name File description File information File size Transfer description Transfer information Copy required Copy type Copy status Possible duplicate Stored transfer reference
(1) This counter can be used for statistical purposes. For performance reasons, these counters are not updated every time a message is sent or received. Operator permissions control the resetting of these counters, which can be performed using the Alliance Web Platform. (2) The type indicates the type of system resource monitored. The possible values are: DISKSPACE, RECOVERYBACKUP, DATABASEBACKUP, JOURNALARCHIVE, JOURNALARCHIVEBACKUP, MESSAGEARCHIVE, MESSAGEARCHIVEBACKUP, and OTHER
Fields descriptions For more information about these fields, see the following guides: Daily Operations Guide, monitoring the Object windows. Monitoring Guide
30 September 2011
225
26.4
Operational Management
26.4.1 Parameter File for the Management Tool

Purpose A parameter file contains the entity types and the selection criteria used to define the management scope. The file is in XML format. You can find a sample parameter file that contains all the entities for operational management in the directory $ALLIANCE/samples. You can copy and update this file to match your own criteria. Validation of the parameter file The parameter file is validated against XML schema definitions (.xsd files). These .xsd files for each entity are located in the following directory:
Scope of management For each entity type, one of the following options are applicable for the selection of entity occurrences to monitor:
Scope of monitoring All Selection Description Monitor all occurrences of the entity type will be monitored Monitor all occurrences that match the user criteria for the entity type
Structure of the parameter file

<ManageEntities>      <entity type="Component"> <FieldSet> <field name="Name" value="SIS"/> <field name="Name" value="SNIS"/> </FieldSet> </entity>  <entity type="Component" occurrence="Selection"> <FieldSet> <field name="Name" value="SIS"/> <field name="Name" value="SNIS"/> </FieldSet> </entity>  <entity type="Logical Terminal" occurrence="Selection"> <FieldSet> <field name="LT" value="SAAABEBBB"/> </FieldSet> </entity>  <entity type="Emission Profile"> <FieldSet> <field name="Name" value="saaabebb_rma"/>
<field name="Name" value="saabbebb_rma"/> <field name="Name" value="saacbebb_rma"/> <field name="Name" value="saadbebb_rma"/> <field name="Name" value="saaebebb_rma"/> </FieldSet> </entity>  <entity type="Reception Profile"> <FieldSet> <field name="Name" value="saaabebb_rma"/> </FieldSet> </entity>  <entity type="Message Partner"> <FieldSet> <field name="Name" value="FileInput"/> </FieldSet> </entity>  <entity type="Queue"></entity>  <entity type="Operator"> <FieldSet> <field name="Name" value="user1"/> </FieldSet> </entity> </ManageEntities>
26.4.2 Manage Alliance Access Entities

Purpose The management tool saa_manage performs actions on Alliance Access entities based a list of specific actions that are provided through a parameter file. Prerequisites Before you launch the command, ensure that: The tool is run locally on the Alliance Access instance that you are monitoring. Note If you want to launch the tool remotely, then you are responsible for ensuring that the remote implementation is secure.
the server is running in either housekeeping or operational mode, as required for the entity being managed. a manage parameter file is available, which specifies the entities to be managed. For more information, see "Parameter File for the Management Tool" on page 226 Important Your Alliance Access licensing agreement allows only a certain number of operators to use the system concurrently. Running this tool starts an operator session with Alliance Access, and this session is included in the count of concurrent users of the system.
To manage the data 1. 2. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu.
227
30 September 2011
3.
Run the saa_manage command (for details, see "saa_manage" on page 290). An exit code provides the results of the management actions which the tool performed. The command launches the management action immediately. For example, for the logicalterminal login action, the tool does not wait until the logical terminal is logged in to return an exit code. If you run the command on several occurrences of a specified entity, and the command fails for one or more occurrences, then the action is stopped. However, the actions that were completed successfully for some are not rolled back.
26.4.3 Entities Eligible for Operational Management

Details
Entity name Component Occurrence identification Name field values Management actions
Start
Permission required System Management, Stop, Start Component System Management, Stop, Start Component SWIFT Interface, Login, Select SWIFT Interface, Login, Select SWIFT Interface, Login, Select SWIFT Interface, Login, Select SWIFT Interface, Enable / Disable Auto mode Monitoring: Reset LT Counter
Stop
Logical Terminal
All or logical terminal field values
Login select_FIN Logout Quit Change_mode

(1) (1)
Reset_Sent
Reset_Received
Monitoring: Reset LT Counter SWIFTNet Interface, Activate EProf / Activate RProf SWIFTNet Interface, Deactivate EProf / Deactivate RProf SWIFTNet Interface, Enable EProf / Enable RProf SWIFTNet Interface, Disable EProf / Disable RProf SWIFTNet Interface, Enable EProf auto / Disable EProf auto / Enable RProf auto / Disable RProf auto Monitoring, Reset EProf Counter (Emission profile) or Reset RProf Counter (Reception profile) Monitoring, Reset EProf Counter (Emission profile) / Reset RProf Counter (Reception profile)
Emission / Reception SWIFTNet profile
All or Name field values
Activate
De_activate
Enable
Disable
Change_mode
Reset_Sent (for Emission
Profile only) (1)

Reset_Received (for
Reception Profile only) (1)
228
Entity name Message Partner
Occurrence identification All or Name field values
Management actions
Enable
Permission required Application Interface, Enable Message Partner Application Interface, Run Session Application Interface, Abort Session Application Interface, Start Session Application Interface, Stop Session Monitoring, Reset MP Counter
Run_session
Abort_session
Start_session
Stop_session
(1) (1)
Reset_Sent
Reset_Received
Monitoring, Reset MP Counter System Management, Hold Queue System Management, Release Queue Security Definition, Enable Operator Security Definition, Disable Operator
Queue
Hold
Release
Operator
Enable
Disable
(1) When these actions are executed, the value of the counter before the reset is provided in the output.
Information about actions For more information about these management actions, the System Management Guide or the Configuration Guide.
30 September 2011
229
27
Using Command Line Tools

Introduction In addition to the System Administration application, you can use a number of tools available from the command line to administer Alliance Access.
27.1
saa_configconnection
Using the saa_configconnection tool, you can: display, add, or delete IP addresses that the SwRPC layer uses to listen for the client connections (Alliance Workstation and ADK-based clients) display, add, or delete IP addresses of SwRPC layer clients that Alliance Access accepts (Alliance Workstation and ADK-based clients) import server SSL certificates and display certificate information
Purpose
Prerequisites The tool must be run from the Alliance Access Administrator account The tool is used to configure the Alliance Access instance that it is packaged with. Procedure 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_configconnection command. For command location and syntax, see "saa_configconnection" on page 280. The configuration program starts. Note If the Alliance Access servers are running when the command is run, then they must be restarted before your changes become effective.
After a change of IP address After an Administrator changes the IP address of Alliance Access, you must perform the following actions: 1. 2. 3. 4. 5. Run the saa_configconnection tool. Remove all the RPC interfaces. Remove all the MAS interfaces. Add new RPC and MAS interfaces so that they match the IP address of Alliance Access. Save the changes and quit the saa_configconnection tool.
230
27.2
saa_system
The saa_system tool provides a number of commands for administering Alliance Access. This tool allows you to: archive messages and events take archive backups take database backups list archive backups restore archive backups run database and software integrity checks start and stop the Alliance Access servers get information about the status of the Alliance Access servers and database start and stop tracing list all Alliance Access instances on a host rename Alliance Access instances copy the Event Journal to a text file. The saa_system tool is provided in the Alliance Access software and in the Remote API software.
Introduction
Prerequisites The Alliance Access bootstrap must be running. See "Starting and Stopping the Bootstrap Service" on page 240. The saa_system commands must be run from the Alliance Access Administrator account. saa_system tool location <Alliance Access installation directory>/bin/saa_system
27.2.1 Displaying All saa_system Commands

Introduction The saa_system command displays all the available commands and the syntax that you must use to run the commands. Procedure 1. 2. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu.
30 September 2011
231
3.
Enter the saa_system command. For command location and syntax, see "saa_system" on page 303.
27.2.2 Messages and Events Archives

Introduction You can use the saa_system command to manage your archives. You can create, list, back up, restore, and remove archives.
27.2.2.1 Archiving Messages and Events

Introduction You may archive messages and events using Alliance Workstation. Alternatively, you can use the saa_system command. Procedure 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_system archive command. For command location and syntax, see "saa_system" on page 303. If you are archiving messages, only days that have all messages completed can be archived. The <NumberOfDays> variable is used to specify the number of days to be retained in the database (minimum 1, maximum 999).
27.2.2.2 Listing Archives

Purpose The saa_system archive list command is used to list archives present in the database. Procedure 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_system archive list command. For command location and syntax, see "saa_system" on page 303.
27.2.2.3 Backing Up Archives

Purpose The saa_system archive backup command is used to back up one or several archives that are present in the database. Alternatively, you can use the System Management application.
232
Procedure 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_system archive backup command. You must specify the type of archive, name of the archive, and the directory where the backup is to be stored. For command location and syntax, see "saa_system" on page 303.
27.2.2.4 Removing Archives

Purpose The saa_system archive remove command is used to remove archives from the database. Procedure 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_system archive remove command. You must specify the type of archive and the name of the archive. For command location and syntax, see "saa_system" on page 303.
27.2.2.5 Restoring Archives

Purpose The saa_system archive restore command is used to restore backed up archives to the database. Alternatively, you can use the System Management application. Note To restore archives created in previous releases of Alliance Access, you must use the saa_system archive restoretar command.
Restoring Telex and Fax messages You can restore Telex and Fax messages processed with releases earlier than release 7.0. However, due to database structural changes required to remove Telex and Fax functionalities for release 7.0, the following fields are not restored: for Telex messages: Telex Number, Answerback, and Network application for Fax messages: Fax Number, CUI, and Network application. Procedure 1. 2. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu.
30 September 2011
233
3.
Enter the saa_system archive restore command. You must specify the type of archive and the full path of the backup. For command location and syntax, see "saa_system" on page 303.
To restore archives made in previous releases of Alliance Access: Enter the saa_system archive restoretar command. You must specify the type of archive, the name of the archive that you want to restore, and the full path of the tar file containing the archive. For command location and syntax, see "saa_system" on page 303.
27.2.2.6 Putting Selected Events into a Text File

Purpose You can use the saa_system readlog command to place events that belong to a specified period into a text file. Procedure 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_system readlog command. You must specify the full path for the text file to be created. For command location and syntax, see "saa_system" on page 303.
27.2.3 Checking the Alliance Access Software Files

Purpose You can use the saa_system integrity command to verify the integrity of the Alliance Access software files. Procedure 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_system integrity command. For command location and syntax, see "saa_system" on page 303.
27.2.4 Listing and Renaming Instances

Purpose You can use the saa_system instance command to list all the instances on the host, and to rename the current instance.
234
To list instances: 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_system instance list command. For command location and syntax, see "saa_system" on page 303. To rename the current instance: 1. 2. 3. 4. Log on as administrator to the machine where Alliance Access is installed. Ensure that the Alliance Access servers are stopped. From the System Administration application, select Xterm from the OS Configuration menu. Type the command: su root 5. Enter the saa_system instance rename command. For command location and syntax, see "saa_system" on page 303. 6. After the running the command successfully, you must activate the change as follows: 1. Log out as root. 2. Log out as the Alliance Administrator. 3. Log on again as the Alliance Administrator. The current instance is renamed according to the value specified. For more information, see "Instances" on page 245.
27.2.5 Checking the Alliance Access Database and Server

Purpose You can use the saa_system status and saa_system dbintegrity commands to check the status of the Alliance Access database and servers, and also to detect unauthorised updates to the Alliance Access database. Procedure 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_system status command. You can view the status of either the database or the server, or both. For command location and syntax, see "saa_system" on page 303. If the servers are running, then the mode of operation is displayed.
30 September 2011
235
4.
To check the integrity of the database, enter the saa_system dbintegrity command. For command syntax, see "saa_system" on page 303.
27.2.6 Starting and Stopping the Alliance Access Server

Purpose This section describes how to use the saa_system command to start, stop or restart the Alliance Access server. The Alliance Access server must be running before a user can use a client application of Alliance Access. Permissions The operator that runs the saa_system must have administrator permissions on the server. To start in Housekeeping mode 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_system start housekeeping command. For command location and syntax, see "saa_system" on page 303. To start in Operational mode 1. 2. 3. Log on to the machine where Alliance Access is installed. Open an Xterm window. Enter the saa_system start operational command. For command location and syntax, see "saa_system" on page 303. Note When the above command is run, the server processes are started in an order that respects interdependencies between them. The script does not return control to the terminal (The command prompt does not appear) until either all server processes have successfully started or a time-out value is reached. For information about how to display errors, see "Considerations when Using the "Start Alliance Servers" Command" on page 132. To stop the server 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_system stop command. For command location and syntax, see "saa_system" on page 303.
236
To restart the server You can restart the server by first running the saa_system stop command and then the saa_system start housekeeping|operational command. Related alarms When the servers are started after Alliance Access is installed for the first time, Alliance Access displays an alarm message per live destination, like: ********************* ALARM ******************** SUBSET DEFINITION: 'XXXX': INITIALISED TO SYSTEM DEFAULT Such alarms are logged in the Event Journal as "severe" events. These alarms occur because the licensed destinations have no delivery subsets defined for them in Alliance Access.
27.2.7 Starting and Stopping Tracing

Purpose You can use the saa_system command to start or stop tracing activities. Prerequisite To run tracing, you need a configuration file provided by SWIFT. To start tracing 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_system traceset command. For command location and syntax, see "saa_system" on page 303. You must enter the directory and file name of the configuration file provided by SWIFT. To stop tracing 1. 2. 3. Log on to the machine where Alliance Access is installed. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_system tracereset command. For command location and syntax, see "saa_system" on page 303.
27.3
saa_configbootstrap
The saa_configbootstrap command is used to configure the Alliance Access Name Service and Bootstrap Service to start automatically at system boot time.
Purpose
Prerequisite The saa_configbootstrap tool must be run using the root account.
27.3.1 Starting the Alliance Access Name Service at Boot Time

Overview You can set the Name Service to start automatically after a system boot. This is done by using the saa_configbootstrap command. This command can only be issued from the root account. How to revert back to manual starting of the Name Service is described at the end of this section. To start the Name Service at boot time: 1. Log on as root or type: su root 2. 3. Enter the appropriate password. Enter the saa_configbootstrap -nameservice command. For command location and syntax, see "saa_configbootstrap" on page 280. The service is added to the Service Management facility. To revert back to manual startup: To remove the service from the Service Management Facility type the following:
svcs -l "*saans*" svcadm disable <fmri> svccfg delete <fmri>
27.3.2 Starting the Alliance Access Bootstrap Service at Boot Time

Overview You can set the Bootstrap Service to start automatically after a system boot. This is done by using the saa_configbootstrap command. This command can only be issued from the root account. How to revert back to manual starting of the Bootstrap Service is described at the end of this section. To start the Bootstrap Service at boot time: 1. Log on as root or type: su root 2. 3. Enter the appropriate password. Enter the saa_configbootstrap -bootstrap command. For command location and syntax, see "saa_configbootstrap" on page 280. The service is added to the Service Management Facility.
238
To revert back to manual startup: Remove the service from the Service Management Facility, by typing:
svcs -l "*saabootstrap*" svcadm disable <fmri> svccfg delete <fmri>
27.4
saa_bootstrap
The saa_bootstrap tool can be used to: start or stop the Alliance Access Name Service start or stop the Alliance Access Bootstrap Service, and the Alliance Access database. Running the script produces either confirmation or error messages. Logging information is kept in the system log file and in the file saa_bootstrap.out.<x>, where <x> is a value from 0 through 5. This allow for six logs to be kept. This file is created in the log sub-directory of the installation directory (that is, $ALLIANCE/log/).
Purpose
Prerequisite The saa_bootstrap tool must be run using the Alliance Access Administrator account. Tool location The command is located in bin sub-directory beneath your installation directory. You can run the command in the following ways: By navigating to the bin sub-directory beneath your installation directory and entering the command from there. From another directory, by specifying the full path to the command, and the command itself. About the system log file The system log is a mechanism provided by UNIX systems to gather activity reports from the system and user processes. It can be configured to only record a particular level of error messages, or only a few selected sources of error messages. If you wish to record all the messages coming from saa_bootstrap are to be recorded for review later, you must do the following: 1. The syslogd daemon must be running (this is a UNIX service) 2. It must be properly configured. This is done in the file /etc/syslog.conf. This file must simply contain a line like:
user.info <path to a log file (typically /tmp/syslog.out)>
This instructs syslogd to record messages coming from all user sources (among which saa_bootstrap) in the given file. 3. To activate the new configuration, type: kill -HUP <pid of syslogd>
30 September 2011
239
From this point on, the system log file contains messages from saa_bootstrap about the start and stop of the database or servers, whether the database was shut down and automatically restarted, and so on.
27.4.1 Starting and Stopping the Name Service

To start the Name Service: 1. 2. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_bootstrap -nameservice start command.
For more information about the command and its syntax, see "saa_bootstrap" on page 279. To stop the Name Service: 1. 2. From the System Administration application, select Xterm from the OS Configuration menu. Enter saa_bootstrap -nameservice stop command.
27.4.2 Starting and Stopping the Bootstrap Service

To start the Bootstrap Service: 1. 2. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_bootstrap start command.
For more information about the command and its syntax, see "saa_bootstrap" on page 279. To stop the Bootstrap Service: 1. 2. From the System Administration application, select Xterm from the OS Configuration menu. Enter the saa_bootstrap stop command.
For more information about the command and its syntax, see "saa_bootstrap" on page 279.
27.5
Alliance CIFA Export

Using the script $ALLIANCE/BSS/bin/$ARCH/export_cif, you can export selected information from the Correspondent Information File application (CIFA) to the screen (stdout) or to an ASCII file. Using the export_cif script, the following information can be exported: The Correspondent File (CORR) From the UNIX command line, the command is issued using the following syntax: export_cif -c | -h Where the following is the output of the -h help option:
Description
240
-c : all correspondent (corr) info -h : help The output of the command is sent to stdout by default, any errors are sent to stderr. It is up to the user to redirect the output to a file. This can be achieved using the redirect operator as follows: export_cif -c > correspo.txt This creates the text file correspo.txt and it contains all information contained in the Correspondent File. The exported information is formatted with each record separated by a blank line. As an example, here is the export layout for the Correspondent File (CORR):
BIC Code : <corr_X1>
27.6
TCP/IP Service Files

Alliance Access relies on TCP/IP settings which are contained in operating system files and the Alliance Access database. The following operating system files are maintained by operating system commands and/or Alliance Access: /etc/hosts - maps remote host names to their IP addresses (when DNS is not used). /etc/services - maps port numbers and the associated TCP protocol, to service names The following TCP/IP related settings are managed by the saa_configconnection tool: RPC Interfaces - which IP addresses the SwRPC layer uses to listen for the client connections (Alliance Workstation, ADK-based clients, and CAS MXA) Allowed Workstations - specifies which SwRPC layer clients (Alliance Workstation and ADKbased clients) that Alliance Access accepts. Tip Normally CAS MXA creates TCP/IP sockets with the IP address associated with the command "hostname". In a cluster environment, this may cause communication problems as the TCP service would only listen to the network adapter with address <hostnameIP>. 5101. If you have such a problem, then specify the correct IP address as the very first entry in RPC interfaces using the saa_configconnection tool.
Description
When using the interactive connection method to connect to a host, service names are referenced by message partner profiles using the term Connection Identifier. For more information about the /etc/services file and message partner profiles, see "Managing Message Partner Profiles" in the System Management Guide.
27.7
The Reset Message Partners (reset_mp) Script

The reset_mp script is used to reset and disable a message partner. The tool is passwordprotected and you must contact Support to use it. The tool must only be used when the Alliance Access servers are not running.
Overview
30 September 2011
241
To start the tool and reset a message partner: 1. 2. From the System Administration application, select Xterm from the OS Configuration menu. Enter the reset_mp command. For command location and syntax, see "reset_mp" on page 278. 3. 4. You are then required to enter a user name and password. You must be an Alliance user that has the Bank Query permission. An ID to be used is displayed on the screen. This ID must be communicated to Support. You then receive an appropriate password to be typed in.
Usage: The switch reset_mp -h displays the syntax of the command.
242
TCP Configuration for the Alliance Access Server
28
28.1

Port Configuration
The TCP configuration defines the ports used by the Alliance Access servers in the alliance_ports file (located in /usr/swa). A base port and range of ports for each Alliance Access instance are created by Alliance Access during the installation of, or migration to, release 7.0. The range for the server ports is 6, and these are required for critical processes of Alliance Access. The Alliance swa_boot process (previously swa_rpcd) has only one port. The default number of ports for Alliance Web Platform (for example, for Messenger) is three. Alliance Access allocates default ports that are not currently in use by the system (not used in /etc/services). The file has the following format:
alliance server messenger server messenger swa_boot <instance_name1> <instance_name1> <instance_nameN> <instance_nameN> <swa_boot_port> <base_port1> <base_port1> <base_portN> <base_portN>
Description
The messenger entry is used for specifying the ports used when accessing Alliance Access through web services. The following is an example of the alliance_ports file:
alliance server server messenger messenger swa_boot SAA_TEST SAA_LIVE SAA_LIVE SAA_TEST 48009 48100 48200 48300 48400
In this example, the following ports are used by Alliance Access instances:
alliance server swa_boot SAA_TEST 48009 48100 48101 48102 48103 48104 48105 48106
30 September 2011
243
server
SAA_LIVE
48200 48201 48202 48203 48204 48205 48206
messenger
SAA_LIVE
48300 48301 48302
messenger
SAA_TEST
48400 48401 48402
The Alliance Administrator can modify this file if other default base_ports (<base_portN>) must be used for the Alliance Access servers. If the swa_boot port is changed (default 48009), then the configuration for each Alliance Workstation connected to the server must be changed to select this new port. If the file is changed by the System Administrator, then the apply_alliance_ports tool must be run to update the operating system files. The ports for the servers and swa_boot must not be changed. Using firewalls If you use a firewall blocking port between Alliance Access and Alliance Workstation, then check before the installation whether the "default ports" are free. If they are, then you can already configure these ports on the firewall to allow an Alliance Workstation to connect to the Alliance Access server.
28.2
apply_alliance_ports Tool
After any change to the alliance_ports file, the operating system files (/etc/ services) must be updated with the new ports allocations using the apply_alliance_ports tool (located in /usr/swa). This tool must be run by root with the Alliance Access servers shut down. To run the tool, type: cd /usr/swa ./apply_alliance_ports -<option>> <instance name> Where:
-<option> =
Introduction
I to update the ports for a specific instance R to remove the ports for a specific instance
<instance_name>=
the instance
244
Note that in a cluster environment, the apply_alliance_ports tool must be run on each node of the cluster to update /etc/services. Note The comment # SWIFTAlliance_SWRPC is a reserved comment and must only be used for apply_alliance_ports.
28.2.1 Handling Multiple Network Cards - IP Address Configuration

Description By default, only one IP address is used by the Alliance Access servers for RPC communication and is obtained at the startup of the servers. In a system with multiple network cards (which use different IP addresses), or a UNIX cluster environment, the default behaviour can be overruled by running the "saa_configconnection" tool. For a system with multiple network cards, you must run the "saa_configconnection" tool to declare all the IP addresses used on the system (use option 1: Configure Interfaces). If you want to prohibit the use of an IP address for the RPC communication, then it is the system administrator's responsibility to ensure that the IP address is removed from the configuration.
28.2.2 Instances
Description When an instance is created or renamed, the alliance_ports file is updated to add or rename the instance, and the apply_alliance_ports tool is run. If an Alliance Access instance is removed, then the Uninstaller program automatically removes this instance from the alliance_ports file. If an Alliance Access instance is renamed, then the swa_boot and saa_bootstrap processes must be stopped and restarted.
28.2.3 Installation
Description The installation process adds an entry in the alliance_ports file for the new Alliance Access instance. If the file does not exist, then it is created.
30 September 2011
245
29
General Troubleshooting
Introduction As with many complex applications, if one file or program is altered in any way, the complete system may not operate correctly or even at all. Alliance Access provides the following facilities to assist with troubleshooting, should problems arise: The Alliance Configuration Report The Report facility produces a formatted report on the current configuration of your Alliance Access system. This facility is particularly useful for remote diagnostic purposes. Should problems arise, the script may be run and the resulting report faxed to Support to verify that the system is correctly configured or to identify configuration problems. The JOURNAL_query Facility This facility allows you to query the Event Journal of Alliance Access, without having to sign on to Alliance Access and use the Event Journal application. JOURNAL_query may also be used for diagnostic purposes if the Alliance Access user interface is unavailable or cannot be started. Pre-installation Check The checkhost command is used before an installation to check the software and resources that are currently available on the customers machine. All hardware and software checks associated with the installation procedure are carried out by this script and the result can be made available as a text file. Customers can fax or e-mail this text file to Support to outline the resources of their machine in cases of performance or installation problems. For information about invoking this script, see "Checking Your System Configuration" on page 93. Software Integrity Check The saa_system integrity command checks whether the Alliance Access software files have been altered since installation.
29.1
The Alliance Configuration Report

The Report command, from the File menu of the System Administration application, allows you to generate a system status report. This report, which may be output to screen, file or printer is useful for diagnostic purposes and may also be used to record the current status of your system.
Overview
To generate a configuration report: 1. 2. Log on to the Alliance Administrator account, using the current password. The main window of the System Administration application will appear. Select the Report command from the File menu.
246
3.
In the Output To field, select the target destination for the report. Choose from: Screen: The text of the report will be displayed in the scrolling text area in the main window of the System Administration application. Use the scroll bars to view the contents of the report. Printer: The text of the report will be sent to your printer. You will be asked to enter the name of the printer. Printed reports are formatted for A4-sized paper, suitable for FAX transmission. If problems arise, use this option to generate a status report and fax it to Support for first-level diagnosis. File: The text of the report will be written to a file. You will be prompted to enter the path name of the file in which the report is to be written.
4.
In the Filter field, select the type of information you require: All Information: All of the following information is included in the report. Operating System: Details related to your operating system are included in the report. The report includes a list of the OS patches and packages currently installed on the system. A check is also made to diagnose any patch mismatches. File Systems: Details related to the file systems currently defined are included in the report. Licensed Options: Details related to the packages, servers and licensed destinations defined at licensing are included in the report. Hardware Configuration: Details related to hardware such as disk drives, network adaptors, and so on are included in the report. TTY Configuration: Details relating to the status of the serial ports are included in the report (only if your system has such ports). Alliance Release: Details of the installed Alliance Access release are included in the report. Patches: Details of the patches installed on your system are included in the report. Paging Space: Details of the paging space on your system are included in the report.
5.
Having selected the type of report and destination, click
OK
The type of report selected is generated and output to the screen, file, or printer.
30 September 2011
247
29.2
The JOURNAL_query Facility

Alliance Access maintains an audit trail of all significant actions performed by Alliance Access users and by the Alliance Access system itself. Each significant action is referred to as an 'event' and is recorded in an audit file known as the Event Journal. The Event Journal provides the primary means by which all user and system-related activity may be monitored. All events are categorised and may be defined as security events or as alarms. Within Alliance Access, a dedicated application (the Event Journal application) is used to query the Event Journal and to generate reports. However, the Alliance Access system administrator does not normally have access to the applications within Alliance Access and, even if he has, if a problem has occurred which makes the user interface unavailable, the Event Journal application cannot be used. The JOURNAL_query facility enables the Alliance administrator to monitor the Event Journal from within the System Administration application, without having to sign on to Alliance Access.
Overview
To monitor the Event Journal: 1. 2. Log on with the Alliance Administrator account, using the current password. The main window of the System Administration application will appear. Select the Journal_Query command from the Alliance menu.
The entries you make in the above window are used to instigate a search of the Event Journal. The results of this search may be directed to the scrolling text area of the main window, to a printer or to a file. 3. In the Start Date/Time and End Date/Time fields, enter values to determine the scope of the search. For example, if a problem has occurred recently then request all events which have occurred in the last 15 minutes. Dates must be entered in the form DD/MM/ YY and times as hh:mm:ss, using 24-hour notation. Where no dates or times are entered, the current day from midnight onwards is taken.
248
4.
In the Output To field, select the destination for the search results. Select from: Screen (the scrolling area of the main window) Printer (you will be prompted to enter the name of a printer) File (you will be prompted to enter the name of a file)
5.
The Number of Records field is used to limit the total number of records sent to the printer or a file when you have selected Printer or File in the previous step. Where you have selected Screen in the Output to field, then the Number of Records field value is used to navigate through the output when using the Next and Previous buttons. In the Number of Records field, select the number of records you want to skip when using the commands Next and Previous. Where no value is specified here then the default value of '1' is taken. The information extracted from the Event Journal is held in a buffer. All operations using the commands Next and Previous will begin scrolling through the buffer with reference to the number of records specified here.
6.
The Search Filter field allows you to input-specific criteria so as to locate particular types of event. This field may be used ONLY in consultation with Support and when specific investigations are conducted. Events are recorded in the journal in a 'plate-stack' manner, where the latest event is always situated at the top of the stack. Consequently, the earliest event will always be found at the bottom of the stack. The Event Journal is a large file and even a simple search can yield a significant number of events. To display particular events: Use the scroll bar at the side of the main window to scroll through the events displayed Use the Top and Bottom commands to move to the top (most recent) event in the window or to the bottom (oldest) event Use the Next and Previous buttons to jump backwards or forwards by the number of events specified in the Number of Records field.
7.
8.
When operating under the direction of Support, use the Search command to start an interrogation of the Event Journal after entering criteria in the Search Filter field. If the search in not successful a warning appears in the main window. If successful, the result of the search is sent to a destination defined under the
Output To
The main window of the System Administration application displays the result of the search by default. This can be found directly beneath the search window. Note This command is not available when Output To is set to 'Screen' or 'Print'.
30 September 2011
249
250
Part D - Appendices
Part D
Appendices
30 September 2011
251
252
Appendix A - Setup Recommendations
Appendix A
Setup Recommendations
A.1 Alliance Access for Service Bureaux
Overview Alliance Access provides functionality to support a multi-banking environment for Service Bureaux and includes: extended data segregation, with the capability to allow institutions served by a Service Bureau to route only their own messages to their own Exit Points the ability to create "local" security officers, so that institutions served by a Service Bureau can create and maintain their own set of operators the ability to restrict message text viewed in the event log, allowing a Service Bureau to control whether the text of messages is stored in the event log or not. Data segregation Data segregation is achieved by controlling access through the APPLICATION Interface, and Routing applications using the permissions of each operator setup for an institution, as follows: APPLICATION Interface application: Open/Print Partner Open/Print Exit Point Routing application: Open/Print Routing Points For each permission it is possible create a list of either the "allowed" or "prohibited" entities (that is, Message Partner, Exit Point, or Routing Point) for the operator concerned. For details about setting up permissions, see "Managing Alliance Access Security" in the System Management Guide. Local security officers When the "Restrict Delegation" configuration parameter is set, the Service Bureau can create "local" security officers for a served institution by granting them only "restricted delegation" rights. These security officers can be given access to, and delegation rights for, a subset of Operator Profiles, Units and Licensed Destination, which are specific to the institution concerned. The "local" security officers can be used by the institution to create and maintain their own set of operators, by delegating rights, and permissions which belong to their restricted subset only. For details about setting up local security officers, see "Setting Up Local Security Officers" in the System Management Guide.
30 September 2011
253
Restrict message text viewed in event log The Service Bureau can also control whether the text of messages is journalised in the event log or not. This can be used to ensure that the text of messages of an institution is not viewable by another user. See the Security Guide for details of how to set up security parameters. Example setup A setup like the following can be used to achieve a typical Service Bureau configuration: Naming conventions The Service Bureau must first define the naming conventions, for example, entities can start with the first four characters of the BIC of the served institution as follows: Institution: AAAABEBB Exit Points: AAAA_EP1 and AAAA_EP2, Message Partners: AAAAFileOutput1, AAAAFileOutput2, and AAAAPrinter1. Such a naming convention facilitates the use of wild-card characters when setting up the names of "allowed" or "prohibited" entities. Security Definition application The Service Bureau gives the operators of the served institution, the permissions to manage their own Message Partners and Exit Points. Alternatively, the Service Bureau can create "local" security officers for the institution so that the institution can create and maintain its own operators. For details about setting up operator permissions and creating local operators, see "Managing Alliance Access Security" in the System Management Guide. APPLICATION Interface application For each institution served by the Service Bureau, the Service Bureau can create a User Defined Queue (UDQ), for example, AAAAUDQ for institution AAAABEBB and BBBBUDQ for institution BBBBBEBB. For more information, see "Configuring Queues" in the System Management Guide. Operators of the institution that have been given the correct permissions can only assign Exit Points to a Message Partner or a Message Partner to an Exit Point according to the list they manage. Routing application The Service Bureau defines the routing of the _SI_from_SWIFT queue to each institution. Messages arriving in the _SI_from_SWIFT queue are routed to the institution-specific UDQ, based on the message receiver (BIC8). Operators of the served institution, define the routing of their own UDQ (optionally this can be done by the Service Bureau as well). Messages arriving in an institution-owned UDQ are routed according to the specific requirements of the served institution. See "Message Routing" in the System Management Guide for more information.
254
A.2
A.2.1
Alliance Access as Standalone Message Entry and Repair System

Overview
You can set up Alliance Access as a standalone message entry/repair system for MT and XMLbased messages. This setup requires that the standalone Alliance Access server is licensed with option 07:STANDALONE REC. This licence option cannot be ordered individually. It is part of a specific licence package, allowing the configuration of a dedicated Alliance Access system for standalone message entry/repair next to a master Alliance Access system. Within such a configuration, the standalone Alliance Access server has no connectivity to SWIFT. This allows for the segregation of the manual message entry/repair activity from the straight through processing of SWIFT traffic. Such a configuration requires at least two Alliance Access systems: a standalone Alliance Access server, with no connectivity to SWIFT, which allows manual entry and repair of MT and XML-based messages, and which can also receive messages through batch input sessions a master Alliance Access system connected to SWIFT. Both Alliance Access systems must use WebSphere MQ to exchange MT and XML-based messages. WebSphere MQ connectivity is provided by the native Alliance Access WebSphere MQ Host Adapter, using the XMLv2 data format to exchange MT and XML-based messages. Note The activation of the MQ Host Adapter on the master Alliance Access system requires licence option 13:MQ HOST ADAPTER.
Systems and licences required
The following figure summarises the supported architecture of such a configuration.
30 September 2011
255
Figure 1 - Standalone message entry and repair configuration
Standalone Alliance Access 1 TR_REC
Standalone Alliance Access 2 TR_REC
Back-Office
MQ Host Adapter
MQ Host Adapter
XMLv2
XMLv2
Central Middleware Infrastructure
XMLv2
MQ Host Adapter
Master Alliance Access system(s)
SWIFT
D0540167
A.2.1.1 Message Creation

Overview The primary function of a standalone Alliance Access system is to support the manual creation of MT and XML-based messages. The messages created on the standalone Alliance Access system are handled by the central middleware infrastructure like any other messages created by back-office applications. Moreover, messages can be input in the standalone Alliance Access system through the various adapters available: File Transfer or MQ Host Adapter, for example. To support the manual creation of MT and XML-based messages, along with reconciliation of the network transmission notifications generated on the master Alliance Access system, a standalone Alliance Access system includes the following functionality: the creation of an input message on the standalone Alliance Access system the transmission of the message through the MQ Host Adapter to the master Alliance Access system
256
the reception of network transmission notifications from the master Alliance Access system over the native MQ Host Adapter, and their reconciliation with the corresponding input message the reception of delivery notifications over the native MQ Host Adapter, and their reconciliation with the corresponding input message. This requires that the Logical Terminals (LTs) used on the standalone and on the master Alliance Access systems have the same logical terminal code and the same message syntax table assigned. The reconciliation, on the standalone Alliance Access system, of the received delivery notification with the input message initially sent requires that the LT code of the input message and the LT code of the delivery notification are identical. Note The transmission notification generated on the master Alliance Access is a new message instance of type transmission notification. The delivery notification sent from the master Alliance Access to the standalone Alliance Access is actually a delivery notification system message, as received from the network.
A.2.1.2 Message Repair

Overview The standalone Alliance Access system also supports the repair of messages created by backoffice applications, when NACKed by SWIFT. In this configuration, the messages created by the back office and that were NACKed, can be forwarded to the standalone Alliance Access system for manual repair, and then sent back to the master Alliance Access system. To support this repair function, the standalone Alliance Access system includes the following functionality: the reception of a network transmission notification that includes the details of the original message over the native MQ Host Adapter the creation of an input message, on reception of the above transmission notification containing the details of the original input message.
A.2.2
Key Features of a Standalone Alliance Access System

A standalone Alliance Access system has mainly three features: it has no connectivity to SWIFT: as a result, the time required for the reception of an acknowledgement is longer than when Alliance Access is connected to SWIFT Real-time InterAct messaging is not supported through a standalone Alliance Access system: the business response of real-time InterAct messages cannot be forwarded from the master Alliance Access system to the standalone Alliance Access system. it introduces a dedicated logic to reconcile the received transmission notifications with the messages created on the standalone Alliance Access system. If the reconciliation fails for a negative transmission notification, then the creation of a repair message is possible. it allows, through a security parameter, to check whether an RMA authorisation exists, although the Alliance Access system has no connectivity to SWIFT.
Overview
30 September 2011
257
A.2.2.1 Use of the "OTHER" Network

Overview The default Alliance Access routing rules make use of the "Route To Addressee" action to route the messages to the preferred correspondent network, which in most cases is the SWIFT network, resulting in messages being sent to the "_SI_to_SWIFT" queue (for FIN). With a standalone Alliance Access system, the messages must not be routed to the "_SI_to_SWIFT" queue but to the exit point associated to the WebSphere MQ message partner that will communicate with the master Alliance Access system. Multiple exit points may exist if communication with multiple master Alliance Access systems is implemented. To facilitate the routing to specific exit points, the preferred network (when creating a message) is set to "OTHER" by default. To achieve this, when a Full Bank File or a Bank Update File is installed, the "OTHER" network is selected as preferred network, instead of the SWIFT and SWIFTNet networks. Similarly, when a new correspondent is defined manually in the Correspondent File application, its preferred network must be set to "OTHER". In this way, the "Route To Addressee" action used in existing routing rules routes the messages to the unique existing "_OI_to_OTHER" queue. The only main routing change consists in defining the appropriate routing rules on the "_OI_to_OTHER" queue to send the message to the appropriate exit points associated to the WebSphere MQ message partner(s).
A.2.2.2 The _AI_waiting_ack Queue

Overview Normally, for an Alliance Access system directly connected to SWIFT, the acknowledgement from the SWIFT network is received very quickly: the 'Waiting Ack' state is a very short transient state. With a standalone Alliance Access system, the "Waiting Ack" state may last much longer. If the network transmission is held in the master Alliance Access system or, following a configuration error, is not routed back to the standalone Alliance Access system, then this "Waiting Ack" state could last forever, until a manual action is taken. To cope with this potentially long "Waiting Ack" state, the standalone Alliance Access system uses the "_AI_waiting_ack" queue. This queue holds the messages waiting for the network transmission notification from the master Alliance Access system. A routing rule must be added to the exit point associated with the WebSphere MQ message partner so that the messages get routed to the "_AI_waiting_ack" queue after being sent to the central middleware.
A.2.2.3 Check for the Presence of an RMA Authorisation

Overview The routing logic based on the "OTHER" network provides a straightforward routing change in the standalone Alliance Access system to route the messages to the master Alliance Access system. However, it does not check for the existence of a valid RMA authorisation at message creation. This is linked to the fact that the OTHER network is a user network and not a SWIFT network. To support RMA lookup, assuming that the relevant RMA authorisations are present in the standalone Alliance Access system, the security configuration parameter "Check authorisation exist" is used. When the value of this parameter is set to "Yes", the check for the existence of an RMA authorisation is performed at message creation, even for correspondents having "OTHER" as network.
A.2.3
Message Flows
This section details the three different flows that a standalone Alliance Access system provides: the creation and emission of MT or XML-based messages the reconciliation of transmission notifications with the created messages the creation of a repair message following the reception of a negative transmission notification that cannot be reconciled with an original input message the reconciliation of optional delivery notifications with the created messages.
Overview
A.2.3.1 Message Entry Flow

Overview The scenario where messages are created on the standalone Alliance Access system implies the following: the support of the emission of the input message created on the standalone Alliance Access system the reconciliation of the transmission notification received from the master Alliance Access system with the created message. For information about the optional processing of a network delivery notification received from the master Alliance Access system, see "Reception of Delivery Notifications" on page 263. The following diagram gives an overview of the steps involved in this scenario for the creation of an MT or an XML-based message.
30 September 2011
259
Figure 1 - Message emission flow
Standalone Alliance Access Alliance Workstation 1 1

_OI_to_OTHER
Back-Office Application
Alliance Web Platform
EP1 toMaster
_AI_waiting_ack
3 4 MQ Host Adapter
3 4
XMLv2 Message
XMLv2 Transmission Report MQ queue MQ queue

D0540168
A.2.3.1.1 Emission of an Input Message

Overview Referring to figure 1 (Message emission flow), the following steps occur: 1. The input message is created in either of the following ways: manually:

from the Message Creation application in Alliance Workstation from Messenger on Alliance Web Platform
the message can be input through a back-office application. The input messages created in the standalone Alliance Access system are not sent to the usual queues _SI_to_SWIFT or _SI_to_SWIFTNet as this system has no connectivity to SWIFT. These input messages are routed to the _OI_to_OTHER queue. 2. From the _OI_to_OTHER queue, the message is routed to a specific exit point, EP1ToMaster, defined by the user, and assigned to a WebSphere MQ message partner.
260
3. Upon processing of the message by the WebSphere MQ message partner: a. the message is queued on the standalone Alliance Access system in the _AI_waiting_ack queue awaiting the transmission notification b. the message is queued as an XMLv2 message in a WebSphere MQ queue waiting for processing by the central middleware which routes this message for processing by the master Alliance Access system. To cater for this scenario, the following configuration tasks must be performed:
Task Create exit points Create message partners Define routing rules associated to the exit points Update routing of _AI_from_APPLI Update routing of _OI_to_OTHER See section "Exit Points" on page 264 "Message Partners" on page 264 "Exit Points" on page 264 "_AI_from_APPLI" on page 266 "_OI_to_OTHER" on page 269
A.2.3.1.2 Reception of Network Transmission Notifications

Overview When the input messages are queued in the routing point _AI_waiting_ack, they expect a positive transmission notification before being completed. The transmission notifications transit through the master Alliance Access system and can be either of the following: a network transmission notification received from the SWIFT network a transmission notification generated by the master Alliance Access system following a local rejection (for example, if there is no authorisation, or if the reception of the messages in Application Interface fails). Referring to step 4 in figure 1 (Message emission flow), the following occurs: The positive or negative acknowledgement received from SWIFT by the master Alliance Access system generates a transmission notification (including original message details) which is queued in a specific WebSphere MQ queue for processing by the standalone Alliance Access system. The message partner associated with the WebSphere MQ queue containing the transmission notification reconciles it with the input message present in the _AI_waiting_ack queue based on the original details it contains, and completes the message or puts it in the _MP_mod_text queue if it has to be corrected. To cater for this scenario, the following configuration tasks must be performed:
Task Create message partners Update routing of _AI_waiting_ack Update routing of _AI_from_APPLI See section "Message Partners" on page 264 "_AI_waiting_ack" on page 265 "_AI_from_APPLI" on page 266
30 September 2011
261
A.2.3.2 Message Repair Flow

Overview The flow where messages originally created in back-office applications are repaired in the standalone Alliance Access system implies the creation of an input message based on original message details included in the transmission notification received from the master Alliance Access system. The following diagram gives an overview of the steps involved in this scenario for the repair of a message.
Figure 2 - Message repair flow
Standalone Alliance Access
_OI_to_OTHER
_MP_mod_text
2
_AI_waiting_ack EP1 toMaster _AI_from_APPLI
1 MQ Host Adapter
XMLv2 Message
XMLv2 Transmission Report MQ queue MQ queue

D0540169
The triggering event for this flow is the presence within a WebSphere MQ queue of a negative transmission notification for a message which the standalone Alliance Access system has never been aware of before. Referring to figure 2 (Message repair flow), the following steps occur: 1. The message partner associated with the WebSphere MQ queue processes the transmission notification and after failing to reconciliate against a message, creates an input message based on the original details it contains. 2. The message is routed to the _MP_mod_text queue to allow its modification before reemission. The emission steps are as described in "Message Entry Flow" on page 259. The required configuration tasks are the same as in "Message Entry Flow" on page 259.
262
A.2.3.3 Reception of Delivery Notifications

Overview A standalone Alliance Access system can receive delivery notifications from the master Alliance Access system. It stores them and can route them to the existing _TR_REC queue for reconciliation with a local input message instance. The following figure gives an overview of the processing related to the reception of delivery notifications within the standalone Alliance Access system.
Figure 3 - Reception of delivery notifications
Standalone Alliance Access
_TR_REC
_AI_from_APPLI
1 MQ Host Adapter
1
XMLv2 Transmission Report MQ queue
D0540170
The triggering event for this flow is the presence within a WebSphere MQ queue of a delivery notification for a message sent by the standalone Alliance Access system. Referring to figure 3 (Reception of delivery notifications), the following steps occur: 1. The message partner associated with the WebSphere MQ queue processes the delivery notification. 2. The message is routed to the _TR_REC queue to allow the reconciliation with the input message. To cater for this scenario, the following configuration tasks must be performed:
Task Create message partners Update routing of _AI_from_APPLI
30 September 2011
See section "Message Partners" on page 264 "_AI_from_APPLI" on page 266

263
A.2.4
Configuration of the Standalone Alliance Access System
A.2.4.1 Creation of Exit Points and Message Partners

A.2.4.1.1 Exit Points
Overview The input messages sent from the standalone Alliance Access system are queued in exit points for further processing by the associated message partner. For details about creating exit points, see "Managing Exit Point Profiles" in the System Management Guide.
A.2.4.1.2 Message Partners

Overview As the supported configuration for a standalone Alliance Access system is based on the native MQ Host Adapter, you must create the message partners with connection method 'WebSphere MQ' and data format 'XMLv2' revision 2, or above. The emission message partner associated with the exit point sends the messages present in the exit point to the defined WebSphere MQ queue. The reception message partners process transmission or delivery notifications queued in different WebSphere MQ queues. If you want a repair input message created in case the reconciliation of a negative transmission notification fails, then you must activate the "Create repair message" option of the message partner. For details about creating message partners, see "Managing Message Partner Profiles" in the System Management Guide.
A.2.4.2 Routing Setup

A.2.4.2.1 Exit Points
Overview The messages queued at exit points such as EP1ToMaster are routed to the _AI_waiting_ack queue when successfully processed by the associated message partners. First, the _AI_waiting_ack queue must be set as valid routing target for the exit points. Note If an exit point or routing point is not visible in the Routing application, then use the System Management application to make it visible and allow modification of rules. For more information, see "Queue Details Window - Routing Info Tab" in the System Management Guide.
From the Queue view in the System Management application, open the details of EP1ToMaster From the Routing Info tab, move _AI_waiting_ack to the Selected list box as valid routing target
264
Define a routing rule like the following one for the EP1ToMaster routing point:
Sequence number Description Condition on Function Result Action on Action Append Intervention Unit Routing code Priority 100 Source to _AI_waiting_ack Function Success Source Route to _AI_waiting_ack No Intervention Keep Current NA Keep Current
A.2.4.2.2 _AI_waiting_ack
Overview The routing rules associated to this queue must be defined based on the type of transmission notification: when a positive transmission notification is received, the original message instance must be completed when a negative transmission notification is received, the original message instance must be routed to an investigation queue such as _MP_mod_text. These routing rules are applied following a successful reconciliation of the received transmission notification with an existing LIVE message instance in the _AI_waiting_ack queue. Define routing rules like the following ones for the _AI_waiting_ack routing point: Positive transmission notifications
Sequence number Description Condition on Message Action on Action Append Intervention Unit Routing code Priority 100 positive transm. notification Message (Network_delivery_status = Network_Acked) Source Complete No Intervention Keep Current NA Keep Current
Negative transmission notifications

Sequence number Description 200 negative transm. notification
30 September 2011
265
Condition on Message
Message (Network_delivery_status = Network_Aborted) or (Network_delivery_status = Network_N_A) or (Network_delivery_status = Network_Nacked) or (Network_delivery_status = Network_RejectedLocally) or (Network_delivery_status = Network_TimedOut) or (Network_delivery_status = Network_WaitingAck)
Action on Action Append Intervention Unit Routing code Priority
Source Route To _MP_mod_text No Intervention Keep Current NA Keep Current
Note
XML-based messages queued in MP_mod_text must be modified using Messenger on Alliance Web Platform.
A.2.4.2.3 _AI_from_APPLI
Overview You must update the routing rules associated with the _AI_from_APPLI queue to: ensure that input messages received through dedicated messages partners are properly routed to the _OI_to_OTHER queue route to the _MP_mod_text queue the input messages created in the standalone Alliance Access system following a repair operation route the delivery notifications of MT and XML-based messages to the _TR_REC queue for the reconciliation with the original input messages. First, the OI_to_OTHER and_TR_REC queues must be set as valid routing targets for the _AI_from_APPLI queue. From the Queue view in the System Management application, open the details of _AI_from_APPLI. From the Routing Info tab, move OI_to_OTHER and_TR_REC to the Selected list box as valid routing targets. Define routing rules to cater for the following: The input messages (created by specific input message partners) are routed to the _OI_to_OTHER queue.
Sequence number Description Condition on 30 input to _OI_to_OTHER Message
266
Message
(Instance_type = Original) and ((Src_entity ='FileInput') or (Src_entity ='MXFileInput')) and (Sub_format = Input) where: "FileInput" and "MX FileInput" are the message partners that have processed the message for input in the standalone Alliance Access system. If you use other message partners, then this condition must be updated. Source Route to _OI_to_OTHER No Intervention Keep Current NA Keep Current
The input messages created following a repair operation (upon failed reconciliation in _AI_waiting_ack of a received negative transmission notification) are routed to the _MP_mod_text queue.
Sequence number Description Condition on Message 40 repair to _MP_mod_text Message (Instance_type = Original) and (Src_entity = 'MPxxx') and (Sub_format = Input) where: 'MPxxx' is the message partner that has processed the transmission notification coming from the master Alliance Access system. Other criteria, such as Creating_mpfn or Creating_application, can also be used. Source Route to _MP_mod_text No Intervention Keep Current NA Keep Current
A similar routing rule must be set up for input messages created by the back-office applications, but which failed the middleware checks. The delivery notifications of MT messages are routed to _TR_REC to allow reconciliation with the original input messages.
Sequence number Description Condition on Message 50 MT traffic reconciliation Message (Mesg_type='010') or (Mesg_type='011') or (Mesg_type='012') or (Mesg_type='015') or (Mesg_type='019')
30 September 2011
267
Action on Action on Action Append Intervention Unit Routing code Priority Action on Type Action Append Intervention Unit Routing code Priority
Source and New Instance Source Route to System No Intervention Keep Current NA Keep Current New Instance Copy Route To _TR_REC No Intervention Keep Current NA Keep Current
The delivery notifications of XML-based messages are routed to _TR_REC to allow reconciliation with the original input messages.
Sequence number Description Condition on Message Action on Action on Action Append Intervention Unit Routing code Priority Action on Type Action Append Intervention Unit Routing code Priority 60 MX traffic reconciliation Message (Nature = NETWORK_MSG) and (Format = 'Internal') Source and New Instance Source Route to MXSystem No Intervention Keep Current NA Keep Current New Instance Copy Route To _TR_REC No Intervention Keep Current NA Keep Current
268
A.2.4.2.4 _OI_to_OTHER
Overview The user-defined queue _OI_to_OTHER is used to gather all the messages input either manually or by message partner within the standalone Alliance Access system. The routing of _OI_to_OTHER must route the messages to the defined exit points according to the defined routing criteria. The main reason for using this routing point is to avoid changing the preferred network of the correspondents defined in the Correspondent File (if the Route to Addressee routing action is used). You must define routing rules like the following one:
Sequence number Description Condition on 100 always to EP1ToMaster Always or Message, if you want to customise the routing based on message content (for example, for a given Sender LT to one master Alliance Access system, for another Sender LT to a different master Alliance Access system) Route to EP1ToMaster No Intervention Keep Current NA Keep Current
Action Append Intervention Unit Routing code Priority
A.2.4.3 Message Preparation

Overview To ensure that messages manually input in the standalone Alliance Access system are routed to the _OI_to_OTHER queue by default, the configuration parameter "Preferred Order" defined in the System Management application must be set to "OTHER,APPLI". To dispose a message directly to _OI_to_OTHER, you must define the_OI_to_OTHER queue as valid routing target for the exit points and for the queues _MP_creation, _MP_mod_text, _MP_verification, and _MP_authorisation. For a specific queue, perform the following steps: From the Queue view in the System Management application, open the details of the queue From the Routing Info tab, move OI_to_OTHER to the Selected list box as valid routing target.
A.2.5
Configuration of the Master Alliance Access System

In addition to the emission, and reception of messages to and from SWIFT, the master Alliance Access system must forward the following to the standalone Alliance Access system: negative transmission notifications associated to messages originating from the standalone Alliance Access system transmission notifications associated to messages created on the back-office applications
Introduction
30 September 2011
269
delivery notifications associated to messages created on the standalone Alliance Access system. This requires that you set up exit points, message partners, and specific routing rules.
A.2.5.1 Exit Points and Message Partners

Overview You must create two exit points: DLVtoAloneEP1, to collect all the delivery notifications to be sent to the standalone Alliance Access system TRANStoAloneEP1, to collect all the transmission notifications to be sent to the standalone Alliance Access system. The emission message partners that process the transmission notifications must have the "Send Original Message" field set to "Always". This ensures that the original message is also included in the XMLv2 TransmissionReport. For details about creating message partners, see "Managing Message Partner Profiles" in the System Management Guide.
A.2.5.2 Routing Setup

Overview The following exit points are used to gather these transmission and delivery notifications: LocalSWIFTAcks and LocalMXAcks: positive transmission notifications LocalSWIFTNacks and LocalMXRejects: negative transmission notifications DeliveryNotifAcks, DeliveryNotifNacks, MXDeliveryNotifAcks, and MXDeliveryNotifNacks: reconciled delivery system messages with original messages sent. As such, the delivery notifications are not routed to the standalone Alliance Access system, but the delivery system messages are. As these notifications must be delivered in specific exit points, the routing for the following routing points must be updated: _SI_to_SWIFT for the transmission notifications associated to MT messages _SI_to_SWIFTNet for the transmission notifications associated to MX messages _SI_from_SWIFT for the delivery notifications associated to MT messages _SI_from_SWIFTNet for the delivery notifications associated to MX messages. Other criteria than the ones present in the routing rules below can be used to refine the routing of these transmission and delivery notifications. As on any Alliance Access system, the modification queues (such as _MP_mod_transmis) on the master Alliance Access system must be monitored to ensure that all the traffic is properly sent to and received from SWIFT. You must define routing rules like the following ones: For _SI_to_SWIFT
270
Route all transmission notifications related to messages originating from the standalone Alliance Access system
Sequence number Description Condition on 50 transmission notifications Message: (Src_entity=Message Partner which treated the input messages coming from the standalone Alliance Access system) Source and New Instance Source Complete No Intervention Keep Current NA Keep Current New Instance Notification Transmission Route To TRANStoAloneEP1 No Intervention NA
Action on Action on Action Append Intervention Unit Routing code Priority Action on New instance type Action Append Intervention Routing code
For _SI_to_SWIFTNet Route all transmission notifications related to messages originated from the Alliance Access system.
Sequence number Description Condition on 50 transmission notifications Message: (Src_entity=Message Partner which treated the input messages coming from the standalone Alliance Access system) Source and New Instance Source Complete No Intervention Keep Current NA Keep Current New Instance Notification Transmission Route To TRANStoAloneEP1
Action on Action on Action Append Intervention Unit Routing code Priority Action on New instance type Action
30 September 2011
271
Append Intervention Routing code
No Intervention NA
For _SI_from_SWIFT Route all delivery notifications to the standalone Alliance Access system.
Sequence number Description Condition on 50 delivery notifications Message: (Mesg_type='011') or (Mesg_type= '012') or (Mesg_type='010') or (Mesg_type='015') or (Mesg_type='019') Function Result = Success Route To DLVtoAloneEP1 No Intervention Keep Current NA Keep Current
For _SI_from_SWIFTNet Route all delivery notifications to the standalone Alliance Access system.
Sequence number Description Condition on 50 delivery notifications Message: (Nature = NETWORK_MSG) and (Format = 'Internal') Function Result = Success Route To DLVtoAloneEP1 No Intervention Keep Current NA Keep Current
272
Appendix B - Command Line Tool Syntax Reference
Appendix B
Command Line Tool Syntax Reference

Introduction This section provides the location and the syntax of commands described in this guide. Running the tools Note that the tools can be run in two ways: By entering the command from the directory where the tool is located. From another location. In this case, you must provide the full path, and command. Getting help You can display the syntax for each tool by entering one of the following commands: <tool name> <tool name> -h where <tool name> is the name of the tool that you want to use.
B.1
checkhost
Tool location <Alliance installation directory>/SunOS/checkhost Command syntax
checkhost.ksh [-req <pathname of requirements file]>] [-rootdir <pathname of a directory>] [-out <pathname of the report file>]
Parameters
Parameter
-req
Description Used to specify the Alliance Access base requirements file, for a comparative analysis report. Used to specify the path to a drive or file system against which the checkhost tool must perform a disk space validation. Used to specify the location for the report file. If no location is specified, then the report is produced in the following default location: /tmp/checkhost.log
Mandatory? No No No
-rootdir
-out
-outxml
Used to specify the location for the report file, and that the file is to be in XML format. If no location is specified, then the report is produced in the following location: /tmp/checkhost.log
No
30 September 2011
273
B.2
getmesg
Purpose Use the getmesg tool to obtain database information about a specific message. The tool can be used with the servers running or stopped. Note You cannot use the getmesg tool to retrieve information about a message that was restored from a backup of the Message Archive from Alliance Access Release 6.0.x. Instead, you must use the saa_bankquery tool to retrieve information about the message.
Tool location <Alliance installation directory>/BSS/bin/SunOS Command syntax

getmesg -u "UUMID" -s DATESUFFIX [-o <output file>] [2><errorfile>]
Parameters
Parameter
UUMID
Description The UUMID of the searched message (can be extracted from the Message File). It must be specified between double quotes ("). The concatenation of the message creation date (YYMMDD) and the suffix displayed in the Message File. The location of the path and the filename of a file where the output of the command is redirected. If the option is not specified, then the command output is displayed on the screen. Used to save the returned error in a file.
Mandatory? Yes Yes No
-s DATESUFFIX
-o <output file>
2><errorfile>
No
To run the tool 1. Log on as Alliance Access System Administrator. 2. From the System Administration application select xterm from the OS Configuration menu. 3. In the Xterm window, run the getmesg command with the required parameters. For example:
getmesg -u "IALLIBEAAXXX999ABCD1234" -s 0004062345 -o /temp/getmesg.out 2>/ temp/mesgerror.out
274
Result If the command is run successfully, Alliance Access writes an event to the Event Journal with the following information about the message: the UUMID of the message for which the getmesg tool was run (a concatenation of the message creation date (YYMMDD) and the suffix of the message for which the getmesg tool was run) the date and time at which the getmesg tool was run the operating system account of the operator that launched the tool
B.3
launch MPA EXPORT_TEMPLATES

Purpose Alliance Access provides an export function for MT and MX message templates. For a designated server and database instance, an offline utility prepares a file that provides forward compatibility when migrating templates. You can export the templates that were created with previous releases on any platform (AIX, Oracle Solaris, or Windows) and then import those templates to this release. You can export all templates, or templates only for a specific logical terminal. You can use the export tool as a convenient way to save all your templates. They are stored in a single file, which is useful to have as a backup of this information. During the export, two files are produced: the output file the export.log file Re-running the export overwrites the output file and the log file. Tool location <Alliance installation directory>/BSA/bin/SunOS Command syntax
launch -- -L MPA EXPORT_TEMPLATES --p <pathname> -f <filename> [-l<senderLT>] [-r<replacementLT>]
Parameters
Parameter
-p <pathname> -f <filename> [-l<senderLT>]
Description Indicates where to store the output files (template file and log file) Specifies the name of the output file that contains exported templates BIC12 name of the logical terminal that contains the templates to be exported. Include the terminal code before the 3-character branch code. If this parameter is not included, then all templates are exported. BIC12 name of the logical terminal that receives the exported templates. Include the terminal code before the 3-character branch code. If this parameter is included, then the -l argument must also be included.
Mandatory? Yes Yes No
[-r<replacementLT>]
No
30 September 2011
275
To run the tool 1. Log on as Alliance Access System Administrator. 2. From the System Administration application select xterm from the OS Configuration menu. 3. In the xterm window, run the launch MPA EXPORT_TEMPLATES command with the required parameters. Result The export.log file contains information about the circumstances of running the export. It lists the names of each template considered for export and indicates whether a template was exported successfully. It summarises how many templates were read, how many were exported, and how many were skipped. The log file shows any errors encountered while building the output file. Messages while exporting templates The following messages can appear when you are exporting templates:
Message
Cannot open [%] for export
Meaning The operating system cannot open the file that contains the exported templates. There can be problems with file permission, file ownership, file existence, and so on. There is a syntax error in the BIC12 value keyed as the sender logical terminal There is a syntax error in the BIC12 value keyed as the replacement logical terminal The export started at the date, and time specified Templates are being selected from the logical terminal identified in the BIC12 for the -l argument Templates are being replaced on the logical terminal identified in the BIC12 for the -r argument The template was exported successfully The template could not be exported because it was reserved during the time that the export was running The templates could not be exported because the logical terminal specified is incorrect The template could not be exported because it did not contain a message type The template could not be exported because it did not contain a valid code for banking priority The template could not be exported because the message user reference syntax was incorrect
[-l argument %] is not a BIC12 [-r argument %] is not a BIC12 Template export started [date time] Selecting LT [%]
Replacing with [%]
EXPORTED NOT EXPORTED (RESERVED)
NOT EXPORTED (LT %s)
NOT EXPORTED (MISSING MESSAGE TYPE) NOT EXPORTED (WRONG BANKING PRIORITY) NOT EXPORTED (WRONG M.U.R.)
276
B.4
launch MPA unres_mesg

Purpose Alliance Access provides an offline utility that allows you to unreserve messages that are blocked. Messages can appear to be reserved even if they are not, due to system crashes of applications used in message preparation (MPA). Prerequisites The servers must be running. The instance on which the message must be unreserved must be the active one. Tool location <Alliance installation directory>/BSA/bin/SunOS Command syntax
launch -- -L MPA unres_mesg -<queue> <UUMID> <suffix>]
Parameters
Parameter
<queue> <UUMID>
Description The queue in which the message instance is reserved. Concatenated values of I/O indicator, Correspondent, Message Type, and Reference. If the UUMID contains any spaces, then enclose the entire string in double quotation marks. Suffix of the message to unreserve. System-generated value.
Mandatory? Yes Yes
<suffix>
Yes
To run the tool 1. Log on as Alliance Access System Administrator. 2. From the System Administration application select xterm from the OS Configuration menu. 3. In the xterm window, run the launch MPA unres_mesg command with the required parameters. Result All attempts to unreserve messages are logged in the Event Journal. A message may fail to be unreserved for the following reasons: Message not found Unreserve operation failed No instances found No instances reserved by MPA found
B.5
messageTool
Purpose The messageTool command is used to unreserve or to complete all messages at a particular routing point. The tool can only be used when the Alliance Access servers are stopped. Tool location <Alliance installation directory>/BSS/bin/SunOS Command syntax
messageTool -r <Routing point name> -c | -u
Parameters
Parameter
<Routing point name> -c -u
Description The name of the Routing Point where the messages to process are located. Option to be used if the messages must be completed. Option to be used if the messages must be unreserved.
Mandatory? Yes No No
To run the tool 1. Log on as Alliance Access System Administrator. 2. From the System Administration application select xterm from the OS Configuration menu. 3. In the xterm window, run the messageTool command with the required parameters. Result If the command is run successfully, Alliance Access writes an event in the Event Journal, with the UMID and instance number of the message instance that was completed or unreserved.
B.6
reset_mp
Purpose reset_mp is used to reset and disable a message partner profile. The tool can be used only when the Alliance Access servers are stopped. Tool location <Alliance installation directory>/MXS/bin/SunOS Command syntax
reset_mp <Message partner name>
278
Parameters
Parameter
<Message partner name>
Description The name of the message partner to reset.
Mandatory? Yes
Result If the command is run successfully, Alliance Access writes an event to the Event Journal with the name of the message partner profile that was reset.
B.7
saa_bankquery
Tool location <Alliance installation directory>/bin Command syntax
saa_bankquery
Parameters
Parameter Description Support will provide details of any parameters that need to be entered. Mandatory?
B.8
saa_bootstrap
Purpose The saa_bootstrap tool can be used to: start or stop the Alliance Access Name Service start or stop the Alliance Access Bootstrap Service, and the Alliance Access database. Running the script produces either confirmation or error messages. Logging information is kept in the system log file and in the file saa_bootstrap.out.<x>, where <x> is a value from 0 through 5. This allow for six logs to be kept. This file is created in the log sub-directory of the installation directory (that is, $ALLIANCE/log/). Prerequisites The saa_bootstrap command must be run using the Alliance Access Administrator account. Tool location <Alliance installation directory>/bin Command syntax
saa_bootstrap [-timeout <value>] [-nameservice] start|stop
30 September 2011
279
Parameters
Parameter
-saastart
Description Starts the Alliance Access servers. If this parameter is not given, then the script uses the value of the Startup Mode parameter (set in the System Management application) to decide whether Alliance Access must be started.
Mandatory? No
stop -timeout <value>
Stops the Alliance Access servers. Defines a value, in seconds, after which the script stops if the Alliance Access instance does not start or stop (depending on which is selected). The minimum value is 150 (seconds). The Alliance Access name service to be started or stopped.
No No
-nameservice
No
B.9
saa_configbootstrap
saa_configbootstrap -nameservice -bootstrap
Parameters
Parameter
-nameservice -bootstrap
Description Starts the Alliance Access Name Service at start time. Starts the Alliance Access bootstrap service at start time.
Mandatory? No No
B.10
Use the saa_configconnection tool to perform the following actions: display, add, or delete IP addresses that the SwRPC layer uses to listen for the client connections (Alliance Workstation and ADK-based clients) display, add, or delete IP addresses of SwRPC layer clients that Alliance Access accepts (Alliance Workstation and ADK-based clients) import server SSL certificates and display certificate information Note If the Alliance Access server is running when the command is run, then it must be restarted before your changes become effective.
Purpose
Prerequisites Run this tool from the Alliance Access Administrator account. Use this tool to configure the Alliance Access instance that the command is packaged with.

Parameters
Parameter Description Make your choice from the menu options and provide responses to the prompts. The default response is shown in square brackets in the format [default,
<default_value>]
Mandatory?
B.11
saa_dbconfig
<Alliance installation directory>/bin
Tool location
Command syntax
saa_dbconfig <entity> <command>
Parameters
Entity
memory
Command
-display
Description Displays the amount of memory allocated for the database memory regions. Default value: 1500 MB. Changes the amount of memory allocated for the database memory regions. Displays the current location, allocated size and usage (in megabytes) of all tablespaces or for a specified tablespace <Name>. Move the tablespace <Name> to the location <DestinationDir>. System tablespaces (SYSAUX, SYSTEM) cannot be moved. The -size option is only taken into account when moving the tablespace UNDO or TEMP (the Size is expressed in MB). Re-sizes the tablespace <Name> to the size specified in <Size> (expressed in MB) or to its minimum required size (using -optimal). Although all tablespaces are configured to automatically increase in size, this allows setting or resetting the size of a tablespace.
Mandator y? No
-resize -all <Size>
No No
tablespace
-display [-tablespace <Name>]
-move -tablespace <Name> -location <DestinationDir> [size <Size>]
No
-resize -tablespace <Name> [-size <Size> | -optimal]
No
-reorganise tablespace <Name> location <TempDir>
Re-organises the specified tablespace <Name> to reclaim unused space and re-sizes it to its minimum required size. This requires sufficient free disk space to be available in the <TempDir> location to perform an export of the data.
No
30 September 2011
281
Entity
Command
Description This command only applies to user tablespaces (and not system tablespaces).
Mandator y?
redolog
-display -move -location <DestinationDir> size
Displays the current location and size of the redo log files. Moves all redo log files to a <DestinationDir> location and resizes them to the specified <Size> (expressed in MB). The original redo logs remain in the original directory, and need to be removed manually if required.
No No
B.12
saa_dbinfo
Tool location
Command syntax
saa_dbinfo <repdir> [-startdate <date> -starttime <time> -stopdate <date> -stoptime <time>]
Parameters
Parameter
<repdir>
Description Specifies the directory where the collected information is to be stored (in a ZIP file). The start date, in the format YYYYMMDD. The start time, in the format HH:MM:SS. The stop date, in the format YYYYMMDD. The stop time, in the format HH:MM:SS.
Mandatory? Yes No No No No
-startdate <date> -starttime <time> -stopdate <date> -stoptime <time>
B.13
saa_dbpwdutil
The saa_dbpwdutil command updates the database information in the installation.properties file with the following information: the password of a database account (owner account or user account) the database connection string Use this command for either an embedded or a hosted database.
Purpose
Prerequisites The following prerequisites apply to this command: The command must be run by the software owner account. The database must be running.
282

saa_dbpwdutil -username <Database Username> [-password <Database User Password>] -connect "<Connect String>" -schema <Database Schema Name>
Parameters
Parameter
-username <Database Username> [-password <Database User Password>] -connect <Connect String>
Description Changes database username, where <Database Username> represents the user account for which the password must be changed. Specifies the new password for the user account Changes the connect string, where "<Connect String>" represents the database connection string to be used by the <Database Username> to connect to the database. For example:"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)
(HOST=<hostname_or_IP_address>)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=ORACLE_SID)))"
Mandatory? Yes No Yes
where <hostname_or_IP_address> is the host where the database is located.

-schema <Database Schema Name>
Changes the name of the database schema, where <Database Schema Name> represents the name of the schema.
Yes
B.14
saa_dbrecovery
Tool location
Command syntax
saa_dbrecovery [-m] [-a -p <pathname_recovery_mirror_disk> -q <pathname_recovery_backup_disk> [-f <y|n>] [-i <y|n>]] [-d [-i <y|n>]] [-c] i [-c] f [-e <y|n>] [-r -p <pathname_recovery_mirror_disk> -q <pathname_recovery_backup_disk> [-z <n|s|a>] [-i <y|n>]] [-v -p <pathname_recovery_mirror_disk> -q <pathname_recovery_backup_disk> [-z <n|s|a>] -s <n|c|i> [-i <y|n>]] [-h]
30 September 2011
283
Parameters
Parameter
-m
Description Displays the status of Database Recovery Mode, which can be: Activated Deactivated If the Database Recovery Mode is Activated, then the command also displays the total disk size and the free disk space available in MB for the live disk and each recovery disk.
Mandatory? No
-a
Activates the Database Recovery Mode. You must specify the full path names of the mirror and backup disks. Specifies the full path name of the mirror disk.
No
-p <pathname_recovery_mi rror_disk> -q <pathname_recovery_ba ckup_disk> -d -f <y|n>
No
Specifies the full path name of the backup disk.
No
Deactivates the Database Recovery Mode. Specifies whether a full recovery backup must be created as part of the activation. The default value is y: a full recovery backup is created. Launches the tool in interactive mode when activating, deactivating, or recovering the database: y: launch the tool in interactive mode n: use command-line parameters By default, if you omit this parameter, then the tool prompts you for input.
No No No
-i <y|n>
-c f|i
Launches a backup of the database : f: full database backup i: incremental database backup By default, Alliance Access removes old database backups after creating a new full-database backup successfully. Optionally, you can remove old backups before Alliance Access creates new backup, by specifying the -e parameter.
No
-e <y|n>
Alliance Access removes old backup before it creates a new backup. By default, Alliance Access removes old database backups after creating a new full-database backup successfully. Recovers the database. You must specify the full path names of the mirror and backup disks. Enables or disables connectivity and Alliance Developers Toolkit components: n: enables connectivity. This is the default value. s: disables SWIFT connectivity only a: disables all connectivity
No
-r
No
-z <n|s|a>
No
284
Parameter
-v
Description Recovers the database from an incremental database backup. This is partial database recovery. You must specify the full path name of the mirror and backup disks. If the value of the Message Repair Action security parameter is Prompted, then you can use the -s parameter to specify how to repair messages after the database recovery. The -s parameter can have the following values: n: leaves live message instances in their queue for further routing. A possible duplicate emission is added to outstanding live message instances. c: completes all live message instances. i: routes all live message instances to the _MP_recovery queue, for further investigation. If the value of Message Repair Action is not Prompted, then you cannot specify how messages are repaired after this partial database recovery. The messages will be repaired according to the value specified for the Message Repair Action parameter.
Mandatory? No
-s <n|c|i>
No
-h
Displays help about the command and its parameters.
No
B.15
saa_dbrestore
The saa_dbrestore command enables an Alliance Access Administrator to restore the database either partially or completely.
Purpose

saa_dbrestore -r -c -p <path name of database backup file> -s {a|o|s|r|c|d|w|m} [-e {y|n}] [-o {y|n}] [-w {y|n}] [-z {n|s|a}] [-i {y|n}]
Parameters
Parameters and Options
-r
Description Restores the database. Use either -c or -r. Runs a consistency check. Use either -c or -r.
Mandatory? Yes
-c
Yes
30 September 2011
285
Parameters and Options
Description In case of detected inconsistencies, a log file is generated. The format of the log file is restore_YYYYMMDDTHHMMSS.log, where YYYYMMDDTHHMMSS is the timestamp when the check was done.
Mandatory?
-p <path name of database backup file>
Specifies the path name where the backup of the database is located. In case of hosted database, <path name of database backup file> is the database directory itself (for example, 20101025T104837_SAA_DATA_BACKUP). The set of entities to be checked or restored. Include one of the following:
a: all entities o: Operators only s: SWIFT interface only r: Routing information only c: Correspondents only d: Alliance Developer Kit (ADK) storage only w: SWIFTNet Interface only m: Relationship Management Application (RMA) authorisations, including
Yes
-s [a|o|s|r|c|d|w|m]
Yes No No No No No No No No No
also the configuration)

-e [y|n]
Cleans messages and events. Default value: n. Restores operators even when the set of operators is not identical. You can use this parameter only when you include -s in the command. Default value: y.
-o [y|n]
No
-w [y|n]
Restores the SWIFTNet related information. You can only this parameter only when you include -s [a|s|w] in the command. Default value: y.
No
-z [n|s|a]
Disable connectivity and Alliance Developers Toolkit components. Include one of the following:
n: no (default value) s: SWIFT Connectivity only a: All
No No No No No
-i [y|n]
Run the script in interactive mode. Default value: y.
To perform a full restore saa_dbrestore -p c:\backup\YYYYMMDDTHHMMSS_DAA_DATA_BACKUP -s -a To perform a partial restore saa_dbrestore -p c:\backup\YYYYMMDDTHHMMSS_DAA_DATA_BACKUP -s -m To run a consistency check saa_dbrestore -c -p c:\backup\YYYYMMDDTHHMMSS_DAA_DATA_BACKUP -s -m
286
B.16
saa_export
Tool location
Operator session Your Alliance Access licensing agreement allows only a certain number of operators to use the system concurrently. Running this tool starts an operator session with Alliance Access, and this session is included in the count of concurrent users of the system. Command syntax
saa_export -parameterfile <export_parameter_file> -exportfile <export_file> [-user|-application <username>] [-password <password>] | [-passwordfile <password_file>] [-exportsensitivedata] [-overwrite] [-port <port_number>] [-reportfile <file_pathname>] [-summaryonly]
Parameters
Parameter
-parameterfile <export_parameter_fil e> -exportfile <export_file> -user <username>
Description The name of the export parameter file that contains the list of entities (along with filtering criteria, if specified) that must be exported. The name of the export file that will contain the exported data, as a result of a successful export process. The name of the Alliance Access operator of type Human executing the command. If omitted and no -application argument is specified, then the operator executing the command must be all_adm. The name of the Alliance Access operator of type Application executing the command. If omitted and no -user argument is specified, then the operator executing the command must be all_adm. The password of the Alliance Access operator. You can use one of the options to specify the password: -user|-application <username> -password <password>: Enter the user name and password in the command line. -user|-application <username> -passwordfile <passwordfile>: Specify the password file name, which contains the password. The password included in the password file is not encrypted. Accessing the password depends on the access rights associated to the password file. -user|-application <username>: You are prompted to enter the password when you launch the tool. This is the most secured option.
Mandatory? Yes
Yes No
-application <username>
No
-password <password>
No
-passwordfile <password_file>
The name of a file that contains the password of the Alliance Access operator.
No
30 September 2011
287
Parameter
-exportsensitivedata -overwrite
Description Indicates that sensitive data will be exported and stored in the export file. Indicates whether the data in the existing export file must be overwritten. If you enter this parameter and the export file exists before you launch the export tool, then it indicates that the export file will be overwritten. If you do not enter this parameter but the export file exists, then the export process stops. The port number of the localhost in which the Alliance Access is listening. Default port number: 48200. The name of the report file in which details of the export are logged. If a file with that name already exists, then Alliance Access overwrites it. If specified, then the produced export log contains less information about the entity occurrences exported.
Mandatory? No No
-port <port_number>
No No No
-reportfile <file_pathname> -summaryonly
B.17
saa_import
Tool location
saa_import -exportfile <export_file> [-user|-application <username>] [-password <password>] | [-passwordfile <password_file>] [-overwrite] [-port <port_number>] [-reportfile <file_pathname>] [-summaryonly]
Parameters
Parameter
-exportfile <export_file> -user <username>
Description The name of the export file containing the configuration data to export. The name of the Alliance Access operator of type Human executing the command. If omitted and no -application argument is specified, then the operator executing the command must be all_adm. The name of the Alliance Access operator of type Application executing the command. If omitted and no -user argument is specified, then the operator executing the command must be all_adm. The password of the Alliance Access operator.
Mandatory? Yes No
No
No
288
Parameter
Description You can use one of the options to specify the password: -user|-application <username> -password <password>: Enter the user name and password in the command line. -user|-application <username> -passwordfile <passwordfile>: Specify the password file name, which contains the password. The password included in the password file is not encrypted. Accessing the password depends on the access rights associated to the password file. -user|-application <username>: You are prompted to enter the password when you launch the tool. This is the most secured option.
Mandatory?
-passwordfile <password_file> -overwrite
The name of the password file that contains the password. The import mode. Specify this parameter to update the existing entities. If you do not specify the parameter, then the update is skipped. The port number of the localhost in which the Alliance Access is listening. Default port number: 48200. The name of the report file in which details of the import execution are logged. If a file with that name already exists, then Alliance Access overwrites it. If specified, then the produced import log contains less information about the entity occurrences imported.
No No No No
-port <port_number>
-reportfile <file_pathname>
-summaryonly
No
B.18
saa_import_rmqa
saa_import_rmqa is used to recover RMA Queries/Answers that were not migrated during an upgrade from Alliance Access 6.3 to 7.0. You can extract RMA Queries/Answers from a 6.3 database backup or a backup file for upgrade.
Purpose

saa_import_rmqa <database backup pathname or name of backup file for upgrade>
Parameters
Parameter
<database backup pathname or name of backup file for upgrade>
Description Indicate either: The full pathname of a database backup (for example:
saa_import_rmqa /backup/20110825T043200_SAA_DATA_BACKUP)
Mandatory? Yes
The name of a backup file for upgrade (for example saa_import_rmqa SAA63to7.zip)
30 September 2011
289
B.19
saa_manage
Tool location
saa_manage -manageparameterfile <manage_parameter_file> -manageoutputfile <manage_output_file> -action <action_keyword> <action_parameters> [-user|-application <username>] [-password <password>] | [-passwordfile <password_file>] [-port <port_number>] [-overwrite]
Parameters
Parameter
-manageparameterfile <manage_parameter_fi le>
Description The name of the file containing the entity type and occurrences to be managed. The file can contain all occurrences or a subset of occurrences, identified by their entity identifier fields. If the file is not located in the current directory, then type the path and name of the file. The name and path of the file that will contain the output of the management action (for each occurrence, if the action has been successful or not, as well as any relevant result). The action to perform on the specified entities. For a full list, see "Entities Eligible for Operational Management" on page 228. The action is defined by a keyword and parameters. The parameters that you must include depend on the action keyword and the entity. Parameter keywords are case-sensitive. Action keyword
select_FIN
Mandatory? Yes
-manageoutputfile <manage_output_file>
Yes
-action <action_keyword> <action_parameters>
Yes
Parameters
[-subset <subset_name_1>] [-subset <subset_name_n>] -ltdirqueue y|n -send_receive_mode s|r|sr
Relevant entity logical terminal
Change_mode
-mode manual|automatic
logical terminal emission or reception SWIFTNet profile

(1)
Start_session
-file_location server|userspace -connection_point <connection_point> -dir to|from

(2) (1)
message partner
290
Parameter
-add_PDE
Description
(3)
Mandatory?
-action route|dispose <queue_name> (3) Run_session
Only for File Transfer connection method:

-file_location server|userspace -connection_point <connection_point>
message partner
Disable
-next_signon_allowed enable, or -next_signon_allowed date "DD/MM/ YYYY HH:MM:SS"
operator
-user <username>
The name of the Alliance Access operator of type Human executing the command. If omitted and no -application argument is specified, then the operator executing the command must be all_adm. The name of the Alliance Access operator of type Application executing the command. If omitted and no -user argument is specified, then the operator executing the command must be all_adm. The password of the Alliance Access operator. You can use one of the options to specify the password: -user|-application <username> -password <password>: Enter the user name and password in the command line. -user|-application <username> -passwordfile <passwordfile>: Specify the password file name, which contains the password. The password included in the password file is not encrypted. Accessing the password depends on the access rights associated to the password file. -user|-application <username>: You are prompted to enter the password when you launch the tool. This is the most secured option.
No
No
No
The name of the file that contains the password of the operator. If the file is not located in the current directory, then type the path and name of the file. The port number of the localhost in which the Alliance Access is listening. Default port number: 48200. When this option is specified, and if the file specified by the manageoutputfile parameter exists, then it is overwritten.
No
-port <port_number>
No No
-overwrite
(1) Always use -file_location for the File Transfer, Direct FileAct, and Print (Print-to-file option) connection methods. (2) Always use -dir for the File Transfer and CAS Interactive connection methods when the message partner profile is defined as To & From Message Partner. Use -dir to start either a session to the message partner or a session from message partner. (3) Use the -action, and optionally, the -add_PDE parameter when you start an input session. An input session uses From Message Partner, or To & From Message Partner with the -dir from parameter to specify the input session.
30 September 2011
291
Exit codes The saa_manage tool returns the following exit codes:
Exit code 0 1 The command ran successfully The command ran successfully for some but not all of the entity occurrences in the <manage_parameter_file>. See the <manage_output_file>. The command failed to run successfully. Description
255
B.20
saa_manageasp
Installs the Application Service Profiles that are provided in an Application Service Profile package, that was downloaded from www.swift.com.
Purpose
Prerequisites The Alliance Access server must be running in either Housekeeping or Operational mode. Tool location <Alliance installation directory>/bin Operator session Your Alliance Access licensing agreement allows only a certain number of operators to use the system concurrently. Running this tool starts an operator session with Alliance Access, and this session is included in the count of concurrent users of the system. Permissions To run this command, you must have the permissions Manage ASP in your operator profile Command syntax
saa_manageasp [-user|-application <username>] [-password <password>] [-passwordfile <passwordfile>] [-l <Full ASP Package Filename>] [-port <port number> [-h]
Parameters
Parameter
-user|-application <username>
Description Name of the Alliance Access operator of type Human (-user), or Application (-application) executing the command. The operator must have the Manage ASP function in their profile. Optional. If omitted, then the operator executing the command must be all_adm. Password of the Alliance Access operator. Optional.
292
Parameter
Description If present, then -user must be present too. Must be omitted if -passwordfile is present.
-passwordfile <passwordfile>
Name of the file containing the password of the Alliance Access operator. Allows the password to specified in a file instead of in the command line. Optional. If present, then -user must be present too. Must be omitted if -password is present. Installs all the ASP files included in the ASP package to install (full file name is required). The port number of the localhost in which the Alliance Access is listening. Default port number: 48200. This port number is called <instance_name>.messenger1 in the /etc/services file. Provides a list of the different options and their meaning.
-l <Full ASP Package Filename>
-port <port number>
-h
Log file Error or confirmation messages are recorded in the log directory, underneath your installation directory. The name of the log file has the timestamp (YYYYMMDDTHHMMSS) of when the command was run.
B.21
saa_monitor
Tool location
Command syntax
saa_monitor -monitorparameterfile <monitor_parameter_file> -monitoroutputfile <monitor_output_file> [-user|-application <username>] [-password <password>] | [-passwordfile <password_file>] [-cycle <nnnn_sec>] [-duration <nnnn_h>] [-continue_on_error] [-port <port_number> [-overwrite]
Important
If you specify the -user parameter without the -password or -passwordfile parameters, then do not redirect the screen output to a file (using the > option).
Parameters
Parameter
-monitorparameterfile <monitor_parameter_file>
Description The name of the file that contains the entity types that must be monitored, and the scope of monitoring for each entity type. If the file is not located in the current directory, then type the path and name of the file.
Mandatory ? Yes
30 September 2011
293
Parameter
-monitoroutputfile <monitor_output_file>
Description The name of the file that contains the monitoring information for the entities included in the monitor parameter file. If the file is not located in the current directory, then type the path and name of the file. The name of the Alliance Access operator of type Human executing the command. If omitted and no -application argument is specified, then the operator executing the command must be all_adm. The name of the Alliance Access operator of type Application executing the command. If omitted and no -user argument is specified, then the operator executing the command must be all_adm. The password of the Alliance Access operator. You can use one of the options to specify the password: -user|-application <username>-password <password>: Enter the user name and password in the command line. The user name and password appears when monitoring processes. -user|-application <username> -passwordfile <passwordfile>: Specify the password file name, which contains the password. The password included in the password file is not encrypted. Accessing the password depends on the access rights associated to the password file. -user|-application <username>: You are prompted to enter the password when you launch the tool. This is the most secured option.
Mandatory ? Yes
-user <username>
No
No
No
The name of the file that contains the password of the operator. If the file is not located in the current directory, then type the path and name of the file. The value in seconds of the cycle according to which monitoring must continue. The minimum time is 2 seconds. If you do not provide a value for the -cycle parameter, then the monitoring runs once only. The value in hours of the duration for which cyclic monitoring must run. This value must be specified only if the -cycle parameter is also specified. If this parameter is not specified, then cyclic monitoring runs forever. The process continues even if an error occurs on any entity or entity occurrence. If this parameter is not specified, then the monitoring stops when the first error occurs on any entity or entity occurrence. The port number of the localhost in which the Alliance Access is listening. Default port number: 48200. This port number is called messenger1 in the /etc/services file.
No
-cycle <nnnn_sec>
No
-duration <nnnn_h>
No
-continue_on_error
No
-port <port_number>
No
-overwrite
When this option is specified, and if the file specified by the monitoroutputfile parameter exists, then the output file is overwritten.
No
294
Exit codes The saa_monitor tool returns the following exit codes:
Exit code 0 1 The command ran successfully The command ran successfully for some but not all of the entity occurrences in the <monitor_parameter_file>. See the <monitor_output_file>. The command failed to run successfully. Description
255
B.22
saa_msgrepair
Tool location
Command syntax
saa_msgrepair [option]
Parameters
Parameter
-m
Description Displays the status of the message repair operation. None: no message repair operation is running Ongoing: a message repair operation is running and is not complete
Mandatory? No
-r [n|c|i]
After the partial recovery, the actions performed for the message repair depends on the value of the "Message Repair Action" security parameter. If the value is "Prompted", then the value of the -r parameter is taken into account. n: None. Live message instances are left in their queue for further routing. c: Complete. Live message instances are completed. i: Investigate. Live message instances are routed to the _MP_recovery queue. If the value is different from "Prompted", then the action specified by the "Message Repair Action" security parameter is performed. In all cases, a PDE is added to live outstanding message instances.
No
-h
Provides a list and description of the different options.
No
B.23
saa_query
You can run a query to export the content of events, messages (live or archived), or all the operator details from the database. For messages and events:
Purpose
30 September 2011
295
The query provides the contents of events or messages that were created within a specific time period. The results of the query also indicate whether the information is from live or archived data. The command extracts details only from the Alliance Access instance from which the command is run. For operators: If the operator that launches the command has delegated units, profile, or destinations, then only those allowed units, profiles and destinations are exported. This applies only when running a report on operators. The results are provided in an output file that uses the same XML format as the Alliance Access Web services use. For more information about the XML format that is used in the output file, see the Web Services Developer Guide. Important The description of this command corresponds to release 7.0. This command is not available in release 7.0.0 of Alliance Access. The command is available for messages and events in release 7.0.10, and later releases. For information about further updates to the command in later releases, see the release letter that corresponds to those releases. The command is also available for operators as from release 7.0.30. Prerequisites Before launching the command, check the following conditions: To query events or operators, the Alliance Access server can be running in either operational or housekeeping mode. To query messages, the Alliance Access server must be running in operational mode. If the Alliance Administrator runs the command and the -user or -application parameters are excluded, then the Software Owner Profile security parameter must specify a valid operator profile. To extract the delegation details of an operator, the operator profile of the operator that runs the command must include the System Management entity in the selected permissions. By default, the default operator profile, R7.0_Import_Export includes the required permissions. Note If operator delegations are used, you will only need to have the system management permission
Tool location <Alliance installation directory>/bin Operator session Your Alliance Access licensing agreement allows only a certain number of operators to use the system concurrently. Running this tool starts an operator session with Alliance Access, and this session is included in the count of concurrent users of the system.
296
Command syntax
saa_query [-user|-application <username>] [-password <password>] | [-passwordfile <password_file>] [-overwrite] [-port <port_number>] -outputfile <file_pathname> -message|-event|-operator [-start <yyyymmddThhmmss> -end <yyyymmddThhmmss>]
Parameters
Parameter
-user <username>
Description The name of the Alliance Access operator of type Human that is running the command. If the -user or -application argument is not specified, then the software owner must launch command. In this case, the Software Owner Profile security parameter must be defined. The name of the Alliance Access operator of type Application that is running the command. If the -user or -application argument is not specified, then the software owner must launch command. In this case, the Software Owner Profile security parameter must be defined. The password of the Alliance Access operator. You can use one of the options to specify the password: -user|-application <username> -password <password>: Enter the user name and password in the command line. If you omit the password, then you receive a prompt to enter it. -user|-application <username> -passwordfile <passwordfile>: Specify the password file name, which contains the password. The password included in the password file is not encrypted. The access rights that are associated with the password file control the access to the password.
Mandatory?
No
No
-passwordfile <password_file> -overwrite
The name of the password file that contains the password. Specify this parameter to overwrite the values in an existing output file. If you omit this parameter, then no changes are made to an existing output file. The port number of the local host in which the Alliance Access is listening. Default port number: 48200. The name of the output file in which details of the messages, events, or operators are stored. Specify one of the following parameters: -message: export the content of messages -event: export the content of events -operator (available as of Alliance Access 7.0.30): export the content of operator profile definitions and operator definitions
No No
-port <port_number>
No Yes Yes
-outputfile <file_pathname> -message|-event|operator
30 September 2011
297
Parameter
Description For more information, see also "Results of operator query" on page 298.
Mandatory?
-start <yyyymmddThhmmss> end <yyyymmddThhmmss>
Use with -message or -event: Specify this parameter to indicate a date and time from which to start and end the extraction of messages or events from the database. The time and date are local to the server. If you omit this parameter, then the tool is run on the current day from 00:00 to 23.59.
No
Results of operator query If the operator that launches the saa_query command has delegated privileges, then the results of the query about operators includes only the information that the operator is permitted to access or view. A query about operators provides the following information: Name Description Operator Type (Human or Application) Profiles Enable status Re-enable date Approval status Last changed Last sign-on Last enabled Authentication type LDAP user identifier Units Delegated units (if any) Delegated BICs (if any) Delegated profiles (if any) A query about operators provides the following information about operator profiles: Profile name Application Profiles: Functions (if any)
Permission details (if any)
In the XML output, dates are formatted as: dd/mm/yy hh:mm:ss.

Log file When you run the command, Alliance Access creates a log file, saa_query_<Timestamp>.log, with the details about the time and the date that the tool was used. <Timestamp> is in the format: yyyymmddThhmmss. The log file also provides the name of the output file. For more information about the XML format that is used in the output file, see the Web Services Developer Guide.
B.24
saa_rtfilegetrequest
Use the saa_rtfilegetrequest command to request a payload file from a correspondent over the FileAct service in real time. A real-time SWIFTNet Reception Profile manages the file request, the subsequent reception of the file, and its storage in the Alliance Access database.
Purpose
Tool location $ALLIANCE/bin Operator session Your Alliance Access licensing agreement allows only a certain number of operators to use the system concurrently. Running this tool starts an operator session with Alliance Access, and this session is included in the count of concurrent users of the system. Command syntax
saa_rtfilegetrequest -user|-application <username> -service <service_name> -request <request_type> -requestor <distinguished_name> -responder <distinguished_name> -rprof <real-time_reception_profile> -logicalname <logical_file_name> [-password <password>] [-passwordfile <password_file>] [-authoriser <distinguished_name>] [-nonrepudiation] [-signature none|crypto|list] [-priority <priority>] [-port <port_number>] [-possible_duplicate] [-transferinfo <info_about_the_transfer>] [-transferdesc <description_of_the_transfer>] [-userref <reference_information> [-unit <unit>]
Parameters The saa_rtfilegetrequest command has mandatory and optional parameters, as follows:
Parameter
-user|-application <username> -service <service_name>
Description The name of the Alliance Access operator of type Human (-user) or Application (-application) executing the command. The name of the real-time FileAct service over which the payload file must be transferred.
Mandatory? Yes Yes
30 September 2011
299
Parameter
-request <request_type> -requestor <distinguished_name>
Description The name of the request type to use within the service, to transfer the file. The DN of the institution that is requesting the file from the correspondent. The Requestor DN must have a valid authorisation to receive from the Responder DN. The DN of the correspondent institution, that is being requested to transfer the file. The name of the real-time SWIFTNet Reception Profile that will manage the file request and the reception of the file from the correspondent. The logical name of the file that is requested from the correspondent. This name must be known to the correspondent. The password of the Alliance Access operator specified in the -user or application parameter. The name of the file that contains the password of the Alliance Access operator specified in the -user or -application parameter. The Authoriser DN that Alliance Access must use when requesting a file from the correspondent. The level-2 BIC8 of the Authoriser DN must be the same as the level-2 BIC8 of the Requestor DN. The presence of this parameter indicates that non-repudiation is required for the file transfer from the correspondent. If the business service requires non-repudiation, then the transfer negotiation for that service must be signed, and you must specify both the nonrepudiation and -signature parameters. The type of FileAct signature that is required, if any: none: No signature is required. Default value. crypto: encrypted signature is required list: signature list is required
Mandatory? Yes Yes
-responder <distinguished_name> -rprof <realtime_reception_profil e> -logicalname <logical_file_name> -password <password>
Yes Yes
Yes
(1)
-passwordfile <password_file>] -authoriser <distinguished_name>
(1)
No
-nonrepudiation
No
-signature none| crypto|list
No
-priority <priority>
The SWIFTNet Priority to apply to the File Get Request: urgent normal If you do not specify -priority, then normal priority is applied.
No
-port <port_number>
The port number through which to connect to Alliance Access. If you do not specify -port, then the default port, 48200, is used. Indicates whether the File message might be a duplicate. A string that provides information about a file transfer. Routing rules can be defined to route FileAct messages based on the content of this field. A string that describes the file transfer.
No
[-Possible_duplicate] [-transferinfo <info_about_the_trans fer>] [-transferdesc <description_of_the_t ransfer>]
No No
No
300
Parameter
-unit <unit>
Description The unit that Alliance Access assigns to the File message after Alliance Access has received the associated payload file successfully. A string, which can be used as a reference for the file transfer or the payload file.
Mandatory? No No
[-userref <user_reference>
(1) You can use only one of the optional parameters, -password or -passwordfile, in the command. If you do not specify -password or -passwordfile , then the system prompts you to type the password for the user.
B.25
saa_supportinfo
The saa_supportinfo tool is used to collect a variety of system-related information over a specified period and store it in a Zip file. The Alliance System Administrator sends the Zip file to Support, for the investigation of problems. Alliance Access configuration data, event journal, trace files, and logs are part of the information that is collected. However, secure information is not collected, for example, passwords or keys. Important Some events related to FIN messages contain the full message payload. If you do not want the FIN message payload to be collected with this tool, then use the Journalise Msg Text security parameter.
Purpose
Impact of database operations The Alliance System Administrator can run this tool at any time, regardless of whether the Alliance Access database is running or not. If the database is not running, then the tool tries to start the database. If the database starts successfully, then the collected information is saved in an output file. If the database fails to start, then the tool only collects information that does not require database access, and saves it in an output file. Tool location <Alliance installation directory>/BSS/bin/SunOS Command syntax
saa_supportinfo [-output <output_dir>] [-from <From_datetime>] [-to <To_datetime>] [-hc] [-help]
Parameters
Parameter
-output <output_dir>
Description The directory in which the output file is stored. If you do not use the -output option, then the output file is stored in the support folder, under the installation root folder of the Alliance Access software (that is, \Alliance\Access\support).
Mandatory? No
30 September 2011
301
Parameter
-from <From_datetime> -to <To_datetime>put
Description Specifies the time period, in the format YYYYMMDD[THHMM], during which information is collect. This information includes ( the event journal, trace files, and log directory. If you do not use this option, then the tool collects logging information from the previous 24 hours. If -from and -to are present, then the logging information for the specified day period is retrieved. If the date is specified but not the time, then the default time is 00:00:00 for <From_datetime>, and 23:59:59 for <To_datetime>. If only -from <from_datetime> is present, then the logging information for the specified date is retrieved for a period from the time specified, or, by default, 00:00:00 to 23:59:59. If only -to <To_datetime> is present, then the logging information for the specified date is retrieved for a period from 00:00:00 to the time specified, or, by default, 23:59:59.
Mandatory? No
-hc -help
Checks the integrity of the operating system and resource information. Provides help.
No No
To run the tool 1. Log on as Alliance System Administrator to the host machine where Alliance Access is installed. 2. From the System Administration application window, select xterm from the OS Configuration menu. 3. In the xterm window, run the saa_supportinfo command with the required parameters. Result The syntax of the output file name is saa_supportinfo.<YYYYMMDDTHHMMSS>.zip Where: YYYYMMDD and THHMMSS are the creation date and time of the zip file The zip file contains two directories with the collected information: config, for the configuration information log, for the logging information. Configuration information that is collected The configuration information includes the following: application server information (such as certificate, configuration file) database configuration information (provided by the saa_dbinfo and saa_dbconfig commands) system information (provided by the checkhost tool and the Report utility) software integrity information (provided by the saa_system integrity command) Alliance Access licence information (provided by the Report utility) Alliance Access configuration information (for example, installation.properties)
dump of the following Alliance Access entities: routing information: routing points, routing rules, routing keywords configuration information: calendar definitions, configuration parameters, units message partner configuration and session details SWIFTNet emission and reception profiles details operator profiles and operator definitions logical terminal definitions control tables for the message and event daily table sets Logging information that is collected The logging information includes the following: the installation.log file Installation checkhost report files Alliance Access product events log for the specified time frame database log and alert files log files of the embedded application server (in case of Server-Embedded products). The time-related options (-to and -from) limit, when applicable to the Alliance Access product, the extracted information for: the event journal the database alert and trace files content of the log directory (only files with a last modification date that falls in the [fromto] time frame).
B.26
saa_system
The saa_system command provides a number of commands for administering Alliance Access. This command allows you to: archive messages and events take backups of one archive or several archives of the same type take database backups list archive backups restore an archive backup run database and software integrity checks start and stop the Alliance Access servers
Purpose
30 September 2011
303
get information about the status of the Alliance Access servers and database start and stop tracing list all Alliance Access instances on a host rename Alliance Access instances copy the Event Journal (Event Log) to a text file. The saa_system command is provided in the Alliance Access software and in the Remote API software. Prerequisites The Alliance Access bootstrap must be running. See "saa_bootstrap" on page 279. The saa_system command must be run from the Alliance Access Administrator account. Tool location <Alliance installation directory>/bin Command syntax
saa_system <command> <additional values> <options>
where: <command> must be replaced with one of the commands listed in the following table. <additional values> represents choices for some of the commands. <options> represents an optional part of the command. Parameters
Parameter
archive jrnl|mesg days <NumberOfDays>
Description Archives the specified entity, where: jrnl represents events mesg represents complete messages Use -days to specify the number of days (1 to 999) for which to retain the archives.
Mandatory? No
archive list jrnl| mesg
Lists the archives present in the database for the specified entity where: jrnl represents events mesg represents complete messages
No
archive listtar jrnl| mesg <file_pathname>
Lists the archives present in a backup of the specified entity, in the tar file specified in <file_pathname>. Use only with backups that were created with an earlier version of Alliance Access. This parameter is not available when a hosted database is used instead of an embedded database.
No
304
Parameter
archive remove jrnl| mesg <archive_name>
Description Removes the specified archive, <archive_name>, from the database. You can also remove several archives of the same type, using a comma (,) to separate the names in <archive_name>. Do not include spaces. Performs a backup of the specified archive and stores the created backup under the directory <file_pathname>. You can also back up several archives of the same type, using a comma (,) to separate the names in <archive_name>. Do not include spaces. For the hosted database, do not specify the <file_pathname> parameter because the backup is created in the eja (for events) or mfa (for messages) subdirectory of the shared directory specified by the Location Backups parameter.
Mandatory? No
archive backup jrnl| mesg <archive_name> <file_pathname>
No
archive restore jrnl| mesg <file_pathname>
Restores the specified archive backup <file_pathname>. In case of hosted database, <file_pathname> is the archive directory, which is MEAR_YYYYMMDD, or JRAR_YYYYMMDD for a single archive backup. This directory must be located in the eja or mfa subdirectory of the shared directory specified by the Location Backups parameter. Restores the specified archive from the backup tar file specified in <file_pathname>. Use only with backups that were created with an earlier version of Alliance Access. This parameter is not available when a hosted database is used instead of an embedded database. Performs a complete backup of the database (excluding messages and events). The command stores the backup as a directory under the directory <file_pathname>. In case of hosted database, do not specify the <file_pathname> parameter because the backup is created in the db subdirectory of the shared directory specified by the Location Backups parameter.
No
archive restoretar jrnl|mesg <ArchiveName> <file_pathname>
No
dbbackup <file_pathname>
No
dbintegrity [all| static]
Verifies the integrity of the Alliance Access database by checking that there are no unauthorised updates. all verifies the complete database, including messages and events.
static verifies the complete database, but excludes messages and
No
events.
integrity [short] [<adk_component_names >
Verifies the integrity (absence of unauthorised updates) of the Alliance Access software files. This command launches the Integrity Verification Tool. The tool generates a full integrity report that is compared to the last full integrity report which was produced during installation or upgrade. Specify [short] to run a less-intense check. Specify <adk_component_names>, to check only specific components of the Alliance Developers Toolkit. If you omit this parameter, then all components of the Alliance Developers Toolkit are checked. The security parameter, Software Check at Startup, controls whether the Integrity Verification Tool is run each time that Alliance Access is started. This parameter is available as of Alliance Access 7.0.10.
No
instance list instance rename readlog <file_pathname> [startdate <Date> [starttime <Time>]] [stopdate <Date> [stoptime <Time>]]
Lists the instances that are installed on the host machine. Renames the current instance of Alliance Access. Reads the events that belong to the specified period from the Event Journal and places them in a text file named in file_pathname.
No No No
30 September 2011
305
Parameter Specify dates and time as: Date: YYYYMMDD Time: HH:MM:SS
start housekeeping
Description
Mandatory?
Starts Alliance Access in housekeeping mode. You cannot start the servers while the database is being restored. Starts Alliance Access in operational mode. You cannot start the servers if the database is being restored. Displays the status of the Alliance Access instance server or of the database: Running For the servers, the command also returns the mode: operational or housekeeping. Not running or stopped
No
start operational
No
status [database| server]
No
stop [force]
Stops the Alliance Access server. Use force to stop the Alliance Access server in a forced way. The processes are killed at the operating system level instead of being stopped. Starts a trace using a configuration file <file_pathname> provided by SWIFT. Stops the trace.
No
traceset <file_pathname> tracereset
No No
Example: backup message archives To back up two message archives, 20101231, and 20110101: saa_system archive backup mesg 20101231,20110101 $ALLIANCE/usrdata/ backup/mfa Example: remove message archives To remove two message archives, 20101231, and 20110101: saa_system archive remove mesg 20101231,20110101 Example: restore a message archive To restore a message archive: saa_system archive restore mesg $ALLIANCE/usrdata/backup/mfa/ MEAR_20101231_20110101
B.27
sa_split
The sa_split tool is used to split any large file into chunks. This can be used for outputs of the saa_supportinfo tool, or for any other files that Support may ask you to send on an exceptional basis.
Overview
306
Tool location Solaris: <Alliance installation directory>/bin Command syntax

sa_split [-size <size>] <filename> | -combine <filepath_name>
Parameters
Parameter
<filename> -size
Description The name of the file to be split. Used to specify the size (in MB) of each chunk. If you do not use this option, then each chunk has a default size of 2 MB. The resulting files are named <filename>.xx, where xx is a sequence number (01..99). Combines chunks of a previously split file into a single file. If the file specified already exists, then the tool returns an error.
Mandatory? No No
-combine <filepath_name>
No
To run the tool 1. From the System Administration application select xterm from the OS Configuration menu. 2. In the xterm window, run the sa_split command with the required parameters.
B.28
swrpc_keytool
<Alliance installation directory>/BSS/bin/SunOS
Tool location
Command syntax
swrpc_keytool
Prompts The following table describes the prompts that you will receive. The default response is presented in square brackets in the form [default]:
Step a Prompt
Do you want: 1: a self-signed certificate 2: a certificate request [default, 1]:
Response If you select 1, then a self-signed certificate is generated, which is signed with its corresponding private key. In this case, the CA certificate and the certificate itself are identical. The subject and issuer of a self-signed certificate are the same. If you select 2 to generate a certificate request, then a PKCS-10 file (Request for Certificate) is generated. You must present this file to a CA (Certificate Authority) to receive a certificate. In this case, the subject and issuer of the certificate are different. The subject is the DN you entered in the certificate request and the issuer is the DN of the CA. To use server
307
30 September 2011
Step
Prompt
Response authentication in this case, you must receive both the certificate and the CA certificate.
File name for the new key:
Enter the path and file name for the private key. If you enter only the file name by default, then the file is created in the current directory. The key is password-protected. Select a password that complies with your institution's password policy. Re-enter the password for verification: The new key is now generated. Skip to prompt g. Enter the file name for your certificate. If the file already exists, then you are prompted to overwrite the file. If the file does not exist, then skip to prompt j. Enter Yes (y) to overwrite an existing file, enter No (n) to return to prompt h. You are now prompted to enter the DN. For information about DN, see prompt l. Enter the file name for your certificate request. If the file already exists, then you are prompted to overwrite it. If not, then skip to prompt l. Enter Yes (y) to overwrite an existing file, enter No (n) to return to prompt j. This DN can contain the following attributes: C for country ST for state or province L for location name O for organisation name OU for organisational unit CN for common name EMAIL for the e-mail address. Enter the DN. A check is then performed on the DN. For a certificate request, you are prompted for further input and for the key file and certificate request file.
Enter a password of your choice:
d e
Re-enter the password for verification: File name for the certificate:
Overwrite existing file? [default, n]:
File name for the certificate request:
h i
Overwrite existing file? [default, n]: Enter the distinguished name (DN) to be included in the certificate: Example: cn=SAA1,ou=department1,o=institution1 . This DN will be needed if you want to configure authentication.
Number of days your certificate will be valid [default, 30]:
Enter the number of days the certificate can be used. Default value: 30. Maximum: 3565.
B.29
systeminfo
The systeminfo tool is used to display information about the following items: system
Purpose
308
hardware configuration log files core file network status Tool location <Alliance installation directory>/BSS/bin/SunOS Command syntax
systeminfo [2><error file>]
Parameters
Parameter
2><error file>
Description Used to save the returned error in a file.
Mandatory? No
To run the tool 1. From the System Administration application select xterm from the OS Configuration menu. 2. In the xterm window, run the systeminfo command with the required parameters. Result The resulting file systeminfo.tar is located in $TMPDIR (if defined). The default path is / usr/tmp.
30 September 2011
309
Legal Notices
Copyright SWIFT 2011. All rights reserved. You may copy this publication within your organisation. Any such copy must include these legal notices. Confidentiality This publication may contain SWIFT or third-party confidential information. Do not disclose this publication outside your organisation without the prior written consent of SWIFT. Disclaimer SWIFT supplies this publication for information purposes only. The information in this publication may change from time to time. You must always refer to the latest available version on www.swift.com. Translations The English version of SWIFT documentation is the only official version. Trademarks SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: SWIFT, the SWIFT logo, the Standards Forum logo, 3SKey, Innotribe, Sibos, SWIFTNet, SWIFTReady, and Accord. Other product, service, or company names in this publication are trade names, trademarks, or registered trademarks of their respective owners.
310

7 0 Saa Inst Admin Guide Sol

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

7 0 Saa Inst Admin Guide Sol

Uploaded by

Copyright:

Available Formats

Connectivity

Alliance Access 7.0

Installation and Administration Guide

Alliance Access 7.0 - Solaris

Part A Installation .............................................................................................................................................9

Additional Information ................................................................................................................................ 87

Part B Configuring for SWIFTNet ......................................................................................................97

Defining Alliance Access in Alliance Gateway .............................................................................. 101

Configuring Alliance Access for FIN Messaging .......................................................................... 106

Part C System Administration ...........................................................................................................113

General System Maintenance ................................................................................................................ 123

Managing UNIX Accounts ....................................................................................................................... 128

Alliance Access 7.0 - Solaris

Managing the Alliance Access Servers ............................................................................................ 131

Backing Up Data .......................................................................................................................................... 144

Restoring Data .............................................................................................................................................. 151

Managing Disk Space ................................................................................................................................ 158

Managing the Database ............................................................................................................................ 160

Database Recovery .................................................................................................................................... 165

23.6 The saa_dbrecovery Command ......................................................................................................... 175

Handling System Failures ....................................................................................................................... 181

Replication of Configuration Data ....................................................................................................... 189

Integration of Operational Data with Third-Party Applications .............................................. 217

Using Command Line Tools ................................................................................................................... 230

TCP Configuration for the Alliance Access Server ..................................................................... 243

General Troubleshooting ........................................................................................................................ 246

Part D Appendices .......................................................................................................................................251

. ppendix B Command Line Tool Syntax Reference ...............................................................................273 A

Alliance Access 7.0 - Solaris

. egal Notices .............................................................................................................................................................310 L

Installation and Administration Guide

Alliance Access 7.0 - Solaris

Installation and Administration Guide

Alliance Access 7.0 - Solaris

Installation and Administration Guide

Installation Features Overview

Installation Features Overview

during silent installation, relicensing, or upgrade

Alliance Access 7.0 - Solaris

Installation and Administration Guide

Alliance Access 7.0 - Solaris

Install with hosted database

Installation and Administration Guide

Use silent mode

Related information "Silent Mode" on page 87 "Non-root Installation or Upgrade" on page 87

Prepare the System

Define the Alliance File System

Alliance Access 7.0 - Solaris

Requirements for the Host Name

Alliance Access host machine

Automatic Time Synchronisation

Installation and Administration Guide

System setup checklist

Solaris System Administrator

Solaris System Administrator Solaris System Administrator Solaris System Administrator

Solaris manuals Solaris manuals Solaris manuals

Alliance Access 7.0 - Solaris

Checklist Check the following items:

Software Installation and Licensing

Software installation and licensing checklist

Installation and Administration Guide

Tracking What Happens During Installation

Create the Temporary Installation Directory