Alliance Access 7.0
Installation and Administration Guide
This installation guide explains how to install and administer Alliance Access on AIX, and how to prepare the system
prior to installation. This document is for system administrators and anyone that installs Alliance Access. Knowledge of
AIX is a prerequisite for readers of this document.
31 December 2010
AIX
Connectivity
Alliance Access 7.0 - AIX
Table of Contents
.Preface .............................................................................................................................................................................7
Part A – Installation .............................................................................................................................................9
1
Installation Features Overview ............................................................................................................... 11
2
Preparation ...................................................................................................................................................... 13
3
2.1
2.2
2.3
Getting Started ......................................................................................................................................... 13
Prepare the System ................................................................................................................................ 15
Tracking What Happens During Installation ....................................................................................... 18
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
Create the Temporary Installation Directory ....................................................................................... 19
Prepare for Non-root Installation, Upgrade, Backup, or Removal ................................................... 19
Create the sagsnlg and alliance Group ............................................................................................... 20
Prepare the Licence File ........................................................................................................................ 20
Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal) ............. 21
Protect the Passwords in the Response File ...................................................................................... 22
Prepare for a Hosted Database Installation ........................................................................................ 22
Prepare a Backup File for Upgrade ...................................................................................................... 27
Installation ........................................................................................................................................................ 31
3.1
3.2
3.3
3.4
4
Upgrade ............................................................................................................................................................. 58
4.1
4.2
4.3
4.4
5
Before You Remove ............................................................................................................................... 81
Interactive Removal ................................................................................................................................ 81
Silent Removal ......................................................................................................................................... 82
Patches .............................................................................................................................................................. 83
7.1
7.2
2
Before You Relicense ............................................................................................................................. 75
Interactive Relicensing ........................................................................................................................... 76
Silent Relicensing .................................................................................................................................... 79
Next Steps ................................................................................................................................................ 79
Removal ............................................................................................................................................................ 81
6.1
6.2
6.3
7
Before You Upgrade ............................................................................................................................... 58
Interactive Upgrade ................................................................................................................................. 61
Silent Upgrade ......................................................................................................................................... 69
Next Steps ................................................................................................................................................ 73
Relicensing ...................................................................................................................................................... 75
5.1
5.2
5.3
5.4
6
Before You Install .................................................................................................................................... 31
Interactive Installation ............................................................................................................................. 32
Silent Installation ..................................................................................................................................... 42
Next Steps ................................................................................................................................................ 46
Installation ................................................................................................................................................ 83
Removal .................................................................................................................................................... 84
Installation and Administration Guide
Table of Contents
8
Additional Information ................................................................................................................................ 85
8.1
8.2
8.3
8.4
8.5
Non-root Installation or Upgrade ........................................................................................................... 85
Silent Mode .............................................................................................................................................. 85
Licence Files for Alliance Access ......................................................................................................... 91
Checking Your System Configuration .................................................................................................. 91
The Software Integrity Report ............................................................................................................... 94
Part B – Configuring for SWIFTNet ......................................................................................................95
9
Introduction ..................................................................................................................................................... 97
10
Check Connectivity ...................................................................................................................................... 98
10.1 Configure SWIFT DNS Servers ............................................................................................................ 98
10.2 Confirm Connectivity ............................................................................................................................... 98
11
Defining Alliance Access in Alliance Gateway ................................................................................ 99
11.1
11.2
11.3
11.4
12
Configuring Alliance Access for FIN Messaging .......................................................................... 104
12.1
12.2
12.3
12.4
13
Concepts ................................................................................................................................................... 99
FIN Messaging ......................................................................................................................................... 99
InterAct and FileAct Messaging .......................................................................................................... 101
Data Encryption/Gateway Authentication between Alliance Access and Alliance
Gateway .................................................................................................................................................. 103
Defining a SWIFTNet Connection ...................................................................................................... 104
Assigning a SWIFTNet Connection to a Logical Terminal ............................................................. 105
Sending and Receiving a Test MT Message .................................................................................... 105
Access to the SWIFTNet FIN Test Service (Vendors only) ............................................................ 105
Configuring Alliance Access for InterAct and FileAct Messaging ....................................... 107
13.1
13.2
13.3
13.4
Defining a SWIFTNet Connection ...................................................................................................... 107
Installing Application Service Profiles ................................................................................................ 107
Configuring SWIFTNet Emission and Reception Profiles ............................................................... 107
Sending and Receiving an InterAct or a FileAct Message ............................................................. 108
Part C – System Administration ...........................................................................................................111
14
Introduction to System Administration ............................................................................................. 113
14.1 Overview of the System Administration Application ........................................................................ 113
14.2 System Management Procedures ...................................................................................................... 117
14.3 The Alliance Release Tree .................................................................................................................. 118
15
An Introduction to Dual Configuration Support ............................................................................ 121
15.1
15.2
15.3
15.4
16
Alliance Access Operations ................................................................................................................. 121
HACMP Overview ................................................................................................................................. 122
Alliance Access Dual Hardware Configuration ................................................................................. 122
Important Technical Documentation on Dual Configuration and HACMP ................................... 125
General System Maintenance ................................................................................................................ 128
16.1 System Management Commands ...................................................................................................... 128
31 December 2010
3
Alliance Access 7.0 - AIX
16.2 Essential System Maintenance ........................................................................................................... 130
17
Managing UNIX Accounts ....................................................................................................................... 133
17.1
17.2
17.3
17.4
17.5
18
Managing the Alliance Access Servers ............................................................................................ 136
18.1
18.2
18.3
18.4
19
Starting the Alliance Access Servers ................................................................................................. 136
Stopping the Alliance Access Servers ............................................................................................... 140
Running Selected Program Scripts following Server Start and Stop ............................................ 144
Monitoring Processes ........................................................................................................................... 144
Backing Up Data .......................................................................................................................................... 147
19.1
19.2
19.3
19.4
19.5
19.6
19.7
20
Alliance Administrator Account ........................................................................................................... 133
Security Considerations ....................................................................................................................... 133
The alliance_init File ............................................................................................................................. 134
Workstation IP Address Checking ...................................................................................................... 134
The Instance Registration File ............................................................................................................ 134
Database Backup .................................................................................................................................. 147
Archive Backup ...................................................................................................................................... 148
Temporary Storage Directory for Backup .......................................................................................... 148
Performing a Manual Backup of Archives ......................................................................................... 149
Performing a Manual Backup of the Database ................................................................................. 151
Scheduling Automatic Backups .......................................................................................................... 153
Following a Backup ............................................................................................................................... 153
Restoring Data .............................................................................................................................................. 154
20.1 Restoring an Archive Backup .............................................................................................................. 154
20.2 Restoring the Alliance Access Database .......................................................................................... 156
21
Managing Disk Space ................................................................................................................................ 161
21.1
21.2
21.3
21.4
21.5
22
Managing the Database ............................................................................................................................ 163
22.1
22.2
22.3
22.4
22.5
23
Getting Information about the Alliance Access Database .............................................................. 163
Checking the Alliance Access Database ........................................................................................... 163
Configuring the Embedded Database ................................................................................................ 164
Backing Up the Alliance Access Database ....................................................................................... 165
The saa_bankquery Tool ..................................................................................................................... 166
Database Recovery .................................................................................................................................... 168
23.1
23.2
23.3
23.4
23.5
4
Monitoring Available Disk Space ........................................................................................................ 161
Modifying Disk Space Parameters ..................................................................................................... 161
System Resources ................................................................................................................................ 162
How To Recover Disk Space .............................................................................................................. 162
Backing Up the Instance Registration File ........................................................................................ 162
About Database Recovery ................................................................................................................... 168
Database Configuration for Enhanced Resiliency ........................................................................... 170
Database Recovery Process ............................................................................................................... 172
Database Recovery Backups .............................................................................................................. 174
Repairing Messages ............................................................................................................................. 176
Installation and Administration Guide
Table of Contents
23.6 The saa_dbrecovery Command ......................................................................................................... 178
24
Handling System Failures ....................................................................................................................... 183
24.1
24.2
24.3
24.4
25
Replication of Configuration Data ....................................................................................................... 190
25.1
25.2
25.3
25.4
25.5
25.6
25.7
25.8
25.9
26
Process Failure ...................................................................................................................................... 183
Power Failure ......................................................................................................................................... 184
Disk Failure ............................................................................................................................................ 184
Recovery on a Different Host Using a Cold Backup ........................................................................ 185
Configuration Replication ..................................................................................................................... 190
Handling the Export and Import of Sensitive Data ........................................................................... 192
Entities Eligible for Export and Import ................................................................................................ 193
Status Management of Entities for Import ......................................................................................... 197
Parameter File for Configuration Replication .................................................................................... 199
Exported Fields ...................................................................................................................................... 203
Export Configuration Data ................................................................................................................... 210
Import Configuration Data .................................................................................................................... 210
Report File for Configuration Replication .......................................................................................... 212
Operational Integration ............................................................................................................................ 214
26.1 Overview of Operational Integration ................................................................................................... 214
26.2 Operational Monitoring ......................................................................................................................... 215
26.3 Operational Management .................................................................................................................... 222
27
Using Command Line Tools ................................................................................................................... 226
27.1
27.2
27.3
27.4
27.5
27.6
27.7
27.8
28
saa_manageasp .................................................................................................................................... 226
saa_configconnection ........................................................................................................................... 226
saa_system ............................................................................................................................................ 227
saa_configbootstrap ............................................................................................................................. 233
saa_bootstrap ........................................................................................................................................ 235
Alliance CIFA Export ............................................................................................................................. 236
TCP/IP Service Files ............................................................................................................................. 237
The Reset Message Partners (reset_mp) Script .............................................................................. 237
TCP Configuration for the Alliance Access Server ..................................................................... 239
28.1 Port Configuration ................................................................................................................................. 239
28.2 apply_alliance_ports Tool .................................................................................................................... 240
29
General Troubleshooting ........................................................................................................................ 242
29.1 The Alliance Configuration Report ..................................................................................................... 242
29.2 The JOURNAL_query Facility ............................................................................................................. 244
Part D – Appendices .......................................................................................................................................247
.Appendix A Setup Recommendations ...........................................................................................................249
A.1
A.2
Alliance Access for Service Bureaux ................................................................................................. 249
Alliance Access as Standalone Message Entry and Repair System ............................................ 251
.Appendix B Command Line Tool Syntax Reference ...............................................................................269
31 December 2010
5
Alliance Access 7.0 - AIX
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
checkhost ............................................................................................................................................... 269
reset_mp ................................................................................................................................................. 269
saa_bankquery ...................................................................................................................................... 270
saa_bootstrap ........................................................................................................................................ 270
saa_configbootstrap ............................................................................................................................. 270
saa_configconnection ........................................................................................................................... 271
saa_dbconfig .......................................................................................................................................... 271
saa_dbinfo .............................................................................................................................................. 272
saa_dbrecovery ..................................................................................................................................... 273
saa_dbrestore ........................................................................................................................................ 274
saa_export .............................................................................................................................................. 275
saa_import .............................................................................................................................................. 277
saa_manage .......................................................................................................................................... 278
saa_manageasp .................................................................................................................................... 279
saa_monitor ........................................................................................................................................... 280
saa_msgrepair ....................................................................................................................................... 282
saa_rtfilegetrequest .............................................................................................................................. 283
saa_system ............................................................................................................................................ 284
swrpc_keytool ........................................................................................................................................ 286
.Legal Notices .............................................................................................................................................................288
6
Installation and Administration Guide
Preface
Preface
Purpose
This guide describes how to install, configure, and administer Alliance Access on AIX. The
guide includes an introduction to dual-configuration support and system administration.
Audience
This guide is for anyone who installs Alliance Access. Knowledge of how to use AIX is a
prerequisite for the readers of this document.
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.
31 December 2010
7
Alliance Access 7.0 - AIX
8
Installation and Administration Guide
Part A - Installation
Part A
Installation
31 December 2010
9
Alliance Access 7.0 - AIX
10
Installation and Administration Guide
Installation Features Overview
1
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 22.
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 85.
Options for software licensing
Licence data can be provided either directly on screen, or from a file.
When
Where
How
during an interactive software
installation, relicensing, or
upgrade
in the licensing windows
• Enter licence data on screen.
during silent installation,
relicensing, or upgrade
from a command line
• Provide licence data from a
licence file.
Provide licence data in a licence
file.
For more information about the licensing options, see "Relicensing" on page 75.
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.
31 December 2010
11
Alliance Access 7.0 - AIX
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 86.
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 86.
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 85.
12
Installation and Administration Guide
Preparation
2
Preparation
2.1
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 AIX machine
• Directory on hard disk:
– local disk
– remote disk, that is, a disk on a remote AIX machine
To get started
1.
Read the Alliance Access Release Letter, if you have not already done so.
2.
Determine which task you need to perform, and prepare for that task. See "Preparation
checklist" on page 14.
3.
After you perform the generic preparation tasks, review the prerequisites and checklists in
the sections, "Installation" on page 31 and "Upgrade " on page 58, and complete any
additional preparation tasks described there.
4.
Perform the task required:
• "Installation" on page 31
• "Upgrade " on page 58
• "Relicensing" on page 75
• "Removal" on page 81
• "Patches" on page 83
31 December 2010
13
Alliance Access 7.0 - AIX
5.
Review the Post-Installation or Post-Upgrade sections in the Release Letter, as
appropriate, and complete any additional tasks that are specified there.
6.
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
Upgrade - standard
Upgrade from prepared backup
Relicense
Remove
Patch
✓
✓
✓
✓
✓
✓
✓
"Prepare the System" on
page 15
✓
✓
✓
✓
"Create the Temporary
Installation Directory" on
page 19
✓
✓
✓
✓
Launch operation as non-root
Install with hosted database
Read the release Letter
Use silent mode
Preparation Task
Install with embedded database
The columns in the table are not mutually exclusive. Therefore, you must perform the
preparation tasks that are indicated in the relevant columns:
"Prepare for Non-root
Installation, Upgrade,
Backup, or Removal" on
page 19
✓
"Create the sagsnlg and
alliance Group" on
page 20
✓
"Prepare the Licence File"
on page 20
✓
"Prepare the Response
File (for Silent Installation,
Upgrade, Relicensing, or
Removal)" on page 21
✓
"Protect the Passwords in
the Response File" on
page 22
✓
"Prepare for a Hosted
Database Installation" on
page 22
"Prepare a Backup File for
Upgrade" on page 27
14
✓
✓
Installation and Administration Guide
Preparation
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 91.
2.2.1
Define the Alliance File System
Introduction
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.
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 19.
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 AIX 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 AIX 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.
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.
31 December 2010
15
Alliance Access 7.0 - AIX
2.2.2
Automatic Time Synchronisation
Overview
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.
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.3
System Setup
Introduction
Use this checklist to configure the basic hardware and operating system.
System setup checklist
16
Action
Responsible
Documentation
Install basic system hardware
Hardware Vendor
IBM manuals
Install DVD drive
Hardware Vendor
IBM manuals
Install AIX with supported packages and
components (see "Prerequisites for the
Installation" on page 31)
AIX System Administrator
AIX manuals
Alliance Access
Release Letter
Configure disk partitions and paging space
(see "Prerequisites for the Installation" on
page 31)
AIX System Administrator
AIX manuals
Installation and Administration Guide
Preparation
Action
Responsible
Documentation
Define file systems and logical volumes
AIX System Administrator
AIX manuals
Install and configure LANs and LAN
connections
AIX System Administrator
AIX manuals
For interactive operations:
AIX System Administrator
AIX manuals
Assign a <host name>
AIX System Administrator
AIX manuals
Allocate TCP/IP addresses
AIX System Administrator
AIX manuals
X-terminals and associated ports are
configured and available
2.2.4
Required Information
Purpose
Perform the basic setup of the system, as listed in "System Setup" on page 16. Then, use this
checklist to ensure that you have all the required information at your disposal before installing or
upgrading Alliance Access.
Checklist
Check the following items:
Required information
Responsible
Reference
Release Letter
AIX System Administrator
Release media
Licensing details (as notified by
SWIFT to Security Officers)
Security officers
SWIFT licensing agreement
Part 1 of the Initialisation
Password
Left security officer
SWIFT licensing agreement
Part 2 of the Initialisation
Password
Right security officer
SWIFT licensing agreement
Details of the required software
installation directory
AIX System Administrator
-
For interactive operations:
AIX System Administrator
AIX manuals
AIX System Administrator
AIX manuals
Identity of the display terminal
used for installation
Identity of your DVD drive
2.2.5
Software Installation and Licensing
Checklist
Use this checklist when installing and licensing Alliance Access on your system and for your
destinations.
Software installation and licensing checklist
Action
Responsible
Documentation
Log on to the "root" or Alliance
Administrator account
Alliance Administrator
AIX manuals
31 December 2010
17
Alliance Access 7.0 - AIX
2.3
Action
Responsible
Documentation
Start installation process from
DVD or directory
Alliance Administrator
"Installation" on page 31
Perform licensing procedures
Alliance Administrator and
Security Officers
Follow system configuration
dialogues and check for errors
Alliance Administrator
Wait for files to be copied
Alliance Administrator
Check for successful completion
Alliance Administrator
Log out of the "root" or Alliance
Administrator account
Alliance Administrator
Store release DVD in a safe
place
Alliance Administrator
-
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 46.
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
18
Installation and Administration Guide
Preparation
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.
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.
Log on with the root user account.
2.
Create the sagsnlg and alliance groups.
3.
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 20.
This non-root user will become the owner of the installation.
31 December 2010
19
Alliance Access 7.0 - AIX
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
5.
The user account that will run the installation must have full access to this
directory for example, all_adm.
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.
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.
Select two free group IDs depending on your company policy. The group ID is the value in
the third column.
3.
Create the groups sagsnlg with the selected group IDs by executing the commands:
mkgroup -A id=<group_ID> sagsnlg
mkgroup -A id=<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.
Procedure
20
1.
Insert the Alliance Access product DVD.
2.
On the DVD, in the folder for Alliance Access, navigate to the AIX/installer directory.
3.
Copy the silent.properties.lic.saa file from the Alliance Access product DVD to a directory
of your choice.
Installation and Administration Guide
Preparation
Note
The directory you choose must also contain the appropriate response file
(before launching the installation or upgrade).
4.
Edit the file to incorporate the information obtained in your licensing agreement.
5.
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 86.
• 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.
Insert the Alliance Access product DVD.
2.
On the DVD, in the folder for Alliance Access, navigate to the AIX/installer directory.
3.
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
4.
The directory you choose must also contain the appropriate licence file (before
launching the installation or upgrade).
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 87.
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 22.
31 December 2010
21
Alliance Access 7.0 - AIX
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.
On the Alliance Access product DVD, navigate to the AIX/installer directory.
2.
Run the obfuscator tool, using the -key option if you want to encrypt a password.
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.
4.
2.10
Copy the resultant data displayed to the appropriate parameter in your response file.
Prepare for a Hosted Database Installation
Introduction
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.
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.
22
Installation and Administration Guide
Preparation
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.
• 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,cio,intr,timeo=600,proto=tcp
There are no specific mount option requirements for the Alliance Access system.
31 December 2010
23
Alliance Access 7.0 - AIX
• 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.
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).
24
Installation and Administration Guide
Preparation
– 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.
User Account
Attribute
Value and Comment
SAAOWNER
Account status
Once the installation of Alliance Access is
successful, the account status can be set to
LOCKed (this is optional).
Authentication method
The SAAOWNER must be identified by a
password when connecting to the Alliance
Access database. This setting is mandatory.
Default tablespace
SAA_DATA is the default tablespace where
SAAOWNER will create database objects. This
setting is optional.
SAATEMP
SAAUSER
Must have the same attributes as SAAOWNER.
Account status
UNLOCKed.
Authentication method
The SAAUSER must be identified by a
password when connecting to the Alliance
Access database. This setting is mandatory.
Default tablespace
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.
31 December 2010
25
Alliance Access 7.0 - AIX
SAAOWNER and SAATEMP system privileges
System privilege
Comment
Usage scope
CREATE ANY
DIRECTORY
Used to create directories during backup and restore of
data.
Run time.
CREATE JOB
Used to create jobs during the Alliance Access database
configuration.
Installation or
patch.
CREATE
PROCEDURE
Used to create stored procedures, functions and packages
during the Alliance Access database configuration.
Installation or
patch.
CREATE
SEQUENCE
Used to create sequences during the Alliance Access
database configuration.
Installation or
patch.
CREATE SESSION
Used to connect to Oracle during the Alliance Access
database configuration.
Installation or
patch.
CREATE SYNONYM
Used for synonym creation.
Installation or
patch.
CREATE TABLE
Used to create tables during the Alliance Access database
configuration.
Also used at run time by stored procedures to create daily
tables, search tables.
Installation or
patch.
Run time.
CREATE TRIGGER
Used to create triggers during the Alliance Access
database configuration.
Also used at run time by stored procedures to create
triggers for daily tables.
Installation or
patch.
Run time.
CREATE VIEW
Used to create views during the Alliance Access database
configuration.
Installation or
patch.
UNLIMITED
TABLESPACE
Used for backup and restore operations.
Run time.
SAAOWNER and SAATEMP object privileges
Object privilege
26
Comment
Usage scope
EXECUTE on
DBMS_LOB
Perform certain operations on LOBs.
Run time.
EXECUTE on
DBMS_LOCK
Used for concurrency control of certain database objects.
Run time.
EXECUTE on
DBMS_FLASHBACK
Used during backup.
Run time.
SELECT on
DBA_LOBS
Used for table and tablespace size calculations during the
backup/restore operations.
Run time.
SELECT on
DBA_SEGMENTS
Used for table and tablespace size calculations during the
backup/restore operations.
Run time.
SELECT on
DBA_FREE_SPACE
Used for table and tablespace size calculations during the
backup/restore operations.
Run time.
SELECT on
DBA_DATA_FILES
Used for table and tablespace size calculations during the
backup/restore operations.
Run time.
SELECT on
DBA_TABLESPACE
S
Used for table and tablespace size calculations during the
backup/restore operations.
Run time.
Installation and Administration Guide
Preparation
Object privilege
Comment
Usage scope
SELECT on
DBA_INDEXES
Used for table and tablespace size calculations during the
backup/restore operations.
Run time.
SELECT on V_
$DATABASE
Used to determine OS in stored procedures.
Run time.
SELECT on
DBA_DATAPUMP_J
OBS
Used for backup and restore operations.
Run time.
SAAUSER system privileges
Object privilege
2.11
Comment
Usage scope
ALTER SESSION
Used to set session tracing, current_schema.
Run time.
CREATE SESSION
Used to connect to Oracle.
Run time.
CREATE SYNONYM
Used for synonym creation.
Installation or
patch.
CREATE ANY
DIRECTORY
Used to create directories during backup and restore of
data.
Run time.
Prepare a Backup File for Upgrade
Introduction
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
AIX to AIX).
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).
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.
31 December 2010
27
Alliance Access 7.0 - AIX
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.
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.
2.
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.
3.
From the Application Interface application, select all the message partners and disable
them.
4.
Export RMA authorisations. For details, see "Exporting Authorisations Manually" in the
Relationship Management Application User Guide.
Note
5.
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.
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.
28
Follow the instructions about preparing for upgrade in the Release Letter.
Installation and Administration Guide
Preparation
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 180.
Procedure
1.
Log on with sufficient privileges.
2.
Stop the Alliance Access or Alliance RMA on the host machine.
3.
Insert the Alliance Access installation DVD.
4.
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.
AIX/installer
6.
Double-click the saa-install.exe file.
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.
31 December 2010
29
Alliance Access 7.0 - AIX
Click OK in the Warning box when all Alliance applications are closed.
11. Click Next 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 OK to continue.
12. Click Finish to complete the backup operation.
The following files are created as a result:
30
File created
Details
backup file
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.
installation.log
Contains details about the backup procedure. This file is present in the
installation directory of Alliance Access or Alliance RMA.
Installation and Administration Guide
Installation
3
Installation
Overview
This section describes how to install Alliance Access 7.0.
3.1
Before You Install
3.1.1
Prerequisites for the Installation
Checklist
Before installing Alliance Access, ensure that:
• the IBM system hardware has been installed and tested.
• you 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 20.
– a response file. See "Prepare the Response File (for Silent Installation, Upgrade,
Relicensing, or Removal)" on page 21.
• 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 AIX 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 release DVD and store it in a safe place.
• Log off.
• Seek advice about the problem.
• Restart the complete installation process.
31 December 2010
31
Alliance Access 7.0 - AIX
3.1.2
Mounting the DVD Drive
Procedure
1.
A directory mount point must first be made for the DVD and then the DVD must be
mounted. Log on as 'root' and create a directory, for example MNT:
mkdir /MNT
2.
Mount the DVD:
mount -v cdrfs -r /dev/cd0 /MNT
3.
Insert the Alliance Access release DVD.
3.2
Interactive Installation
3.2.1
Launching the Interactive Installation From DVD
Overview
All commands in this guide assume that you are using the Korn shell (not the Bourne shell).
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.
Check that you are using the Korn shell by looking at the entry for root (or Alliance Access
owner account) in the /etc/passwd file. To invoke the Korn shell, log on as root (or Alliance
Access owner account) and type:
ksh
2.
To start the installation process, log on as root (su root does not work) or the Alliance
Access owner account.
3.
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 installation windows will be displayed.
4.
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.
5.
Insert the Alliance Access release DVD.
6.
Navigate to the following directory in the folder for Alliance Access:
/AIX/installer
7.
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 86 for more information.
32
Installation and Administration Guide
Installation
8.
To proceed with the installation, follow the steps in "Install Alliance Access Interactively" on
page 34.
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.
Set the permissions on the remote machine. You have to edit the following files:
~/.rhosts
/etc/exports
2.
Insert the DVD on the remote machine.
3.
Mount the DVD on the remote machine.
4.
Share/export the mount point of the DVD on the remote machine as an NFS resource.
5.
Create a mount point on the local machine.
6.
Mount the remote directory on the local machine.
7.
Finally, access the DVD from the local machine using the local name <mount_point> for the
remote directory.
8.
Navigate to the following directory in the folder for Alliance Access:
/AIX/installer
9.
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 86 for more information.
3.2.2
Launching the Interactive Installation From a Directory
Introduction
All commands in this guide assume that you are using the Korn shell (NOT the Bourne shell).
To check this, see the entry for root (or Alliance Access owner account) in the /etc/passwd file.
To invoke the Korn shell, log on as root (or Alliance Access owner account) and type:
ksh
To launch the installation program:
1.
Log on as root (or Alliance Access owner account).
2.
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 installation windows will be displayed.
31 December 2010
33
Alliance Access 7.0 - AIX
3.
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.
4.
Copy the DVD contents to an install directory on hard disk by typing:
mkdir <install directory>
cd <install directory>
cp -r /MNT/* .
5.
Unmount the DVD:
cd ~
umount /MNT
6.
Navigate to the following directory in the created install directory:
/AIX/installer
7.
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 86 for more information.
8.
To proceed with an interactive installation, follow the steps in "Install Alliance Access
Interactively" on page 34.
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.
Copy the DVD contents to a directory on the remote machine.
2.
Share/export this file system on the remote machine as an NFS resource.
3.
Mount the directory on the local machine.
4.
Access the directory from the local machine using the local name <mount_point> for the
remote directory.
For example:
cd /<mountpoint>/AIX/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 86 for more information.
3.2.3
Install Alliance Access Interactively
Installation event log
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
34
Installation and Administration Guide
Installation
not yet been entered. In case of installation failure, please check this file for the reasons of the
failure.
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 27.
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.
31 December 2010
35
Alliance Access 7.0 - AIX
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 19.
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.
The host name, if entered, is not case-sensitive, and must meet the following criteria:
– maximum of 31 characters
– can only contain the characters 'a-z', 'A-Z', '.', and '-'
• Port
Enter the port number to be used by Alliance Access to connect to the Oracle instance.
36
Installation and Administration Guide
Installation
• Service
Enter the service ID identifying the Oracle instance.
8.
Click Next .
9.
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.
31 December 2010
37
Alliance Access 7.0 - AIX
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.
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 75.
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 .
38
Installation and Administration Guide
Installation
The Initialisation Password Configuration window appears.
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.
17. Click Next .
If the password verification fails, then an error message appears. Click OK and enter the
correct input.
31 December 2010
39
Alliance Access 7.0 - AIX
18. The Instance Configuration window appears.
Field
Description
Host Name
The host name of the Alliance Access system.
IP Address
The IP address of the Alliance Access system.
Instance Name
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.
Instance Comment
A description of the instance.
It can contain alphanumeric characters and spaces, and must not exceed
30 characters.
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 24).
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.
40
Installation and Administration Guide
Installation
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 Next .
Note
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 25).
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 Install , it
is not possible to abort the software installation. If the details are not correct, click Previous
to return to the previous screen(s) and make your corrections.
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 239.
The window also reminds you to perform SWIFTNet configuration activities.
25. Click Finish to complete the installation.
31 December 2010
41
Alliance Access 7.0 - AIX
Note
Once the installation has completed successfully, if you have installed from
DVD, remove the DVD as follows:
1. Log on as root (or Alliance Access owner account) and unmount the DVD
by typing:
cd ~
umount /MNT
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 unmount the DVD.
2. Log off from the root (or Alliance Access owner account) account.
26. Perform the post-installation steps described in the Release Letter. Then follow the
instructions in "Post-Installation Checklist" on page 46.
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
Silent Installation
3.3.1
Install Alliance Access Silently From DVD
Overview
All commands in this guide assume that you are using the Korn shell (not the Bourne shell).
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.
Check that you are using the Korn shell by looking at the entry for root (or Alliance Access
owner account) in the /etc/passwd file. To invoke the Korn shell, log on as root (or Alliance
Access owner account) and type:
ksh
2.
To start the installation process, log on as root (su root does not work).
3.
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 installation windows will be displayed.
42
Installation and Administration Guide
Installation
4.
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.
5.
A directory mount point must first be made for the DVD and then the DVD must be
mounted. Log on as 'root' (or Alliance Access owner account) and create a directory, for
example MNT:
mkdir /MNT
6.
Mount the DVD:
mount -v cdrfs -r /dev/cd0 /MNT
7.
Insert the Alliance Access release DVD.
8.
Navigate to the following directory in the folder for Alliance Access:
/AIX/installer
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
The licence file must also be present in the same directory.
Note
• -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 46.
Installing from a remote DVD drive
1.
Set the permissions on the remote machine. You have to edit the following files:
~/.rhosts
/etc/exports
2.
Insert the DVD on the remote machine.
3.
Mount the DVD on the remote machine.
4.
Share/export the mount point of the DVD on the remote machine as an NFS resource.
5.
Create a mount point on the local machine.
6.
Mount the remote directory on the local machine.
31 December 2010
43
Alliance Access 7.0 - AIX
7.
Finally, access the DVD from the local machine using the local name <mount_point> for the
remote directory.
8.
Navigate to the following directory in the folder for Alliance Access:
/AIX/installer
9.
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:
/tmp/alliance/silent.properties.install.saa.embedded
• -key <value> specifies the key to be used if the password(s) in the response file have
been encrypted.
10. Perform the post-installation steps described in the Release Letter. Then follow the
instructions in "Next Steps" on page 46.
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
Introduction
All commands in this guide assume that you are using the Korn shell (NOT the Bourne shell).
To check this, see the entry for root (or Alliance Access owner account) in the /etc/passwd file.
To invoke the Korn shell, log on as root (or Alliance Access owner account) and type:
ksh
To start the installation process:
1.
Log on as root (or Alliance Access owner account).
2.
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 installation windows will be displayed.
3.
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.
4.
A directory mount point must first be made for the DVD and then the DVD must be
mounted.
Log on as 'root' (or Alliance Access owner account) and create a directory, for example
MNT:
mkdir /MNT
44
Installation and Administration Guide
Installation
5.
Mount the DVD:
mount -v cdrfs -r /dev/cd0 /MNT
6.
Copy the DVD contents to an install directory on hard disk by typing:
mkdir <install directory>
cd <install directory>
cp -r /MNT/* .
7.
Unmount the DVD:
cd ~
umount /MNT
8.
Navigate to the following directory in the created install directory:
/AIX/installer
9.
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:
/tmp/alliance/silent.properties.install.saa.embedded
• -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.
10. Perform the post-installation steps described in the Release Letter. Then follow the
instructions in "Next Steps" on page 46.
To install from a remote directory:
1.
Copy the DVD contents to a directory on the remote machine.
2.
Share/export this file system on the remote machine as an NFS resource.
3.
Mount the directory on the local machine.
4.
Access the directory from the local machine using the local name <mount_point> for the
remote directory.
For example:
cd /<mountpoint>/AIX/installer
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.
31 December 2010
45
Alliance Access 7.0 - AIX
For example:
/tmp/alliance/silent.properties.install.saa.embedded
• -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 46.
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.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
Authentication of users
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.
Post-installation checklist
Use the following checklist to configure the installed software for live users:
Action
Responsible
Documentation
If you are going to use Alliance Web Platform, install
it and load the packages for Alliance Access
Alliance Administrator
Web Platform documentation
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.
Alliance Administrator
Security Guide
Installation and
Administration Guide
Start the Alliance Access servers
Alliance Administrator
Installation and
Administration Guide
46
Installation and Administration Guide
Installation
Action
Responsible
Documentation
Wait for servers to be ready. Do not quit the System
Administration application.
Alliance Administrator
Installation and
Administration Guide
From Alliance Workstation, sign on as left security
officer using Part 1 of the Master Password.
Update left security officer password.
Left security officer
Security Guide
System Management Guide
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
Right security officer
Security Guide
System Management Guide
Create customised operator profiles (or use the
defaults provided).
Right security officer
Security Guide
Create new operator(s) (with "Supervisor" or
"SuperKey" privileges). Assign SWIFTNet Support
application permissions to other operators if needed.
Right security officer
System Management Guide
Approve new operator(s).
Right security officer
System Management Guide
Display RIGHT part of system password(s) for new
operator(s).
Right security officer
System Management Guide
Sign on to Alliance Access as left security officer
using updated password.
Left security officer
System Management Guide
Approve operator(s).
Left security officer
System Management Guide
Display LEFT part of system password(s) for new
operator(s).
Left security officer
System Management Guide
Sign on to Alliance Access as an operator, using the
system password received from left security officer/
right security officer.
New operator
(with "Supervisor" or
"SuperKey" privileges)
System Management Guide
Update operator password when prompted.
New operator
System Management Guide
Create units (if required).
New operator
System Management Guide
Assign units to operators (if required).
Left security officer / Right
security officer
System Management Guide
Set up your security parameters.
Alliance Administrator
Security Guide
In the System Management application, define and
select the SWIFT destination for alarm generated
messages (MT 999).
New operator
System Management Guide
Not required for standalone Alliance Access:
In the System Management application, start the
SNIS, used for InterAct and FileAct (including RMA
(Relationship Management application))
New operator
System Management Guide
Sign off.
New operator
Daily Operations Guide
Restart Alliance Access in Housekeeping mode.
New operator
System Management Guide
When servers are ready, sign on using updated
password.
New operator
Daily Operations Guide
Install and activate Value Added Service Parameter
Files (if required).
New operator
System Management Guide
Install the Alliance Bank File from the Correspondent
Information File application (if required).
New operator
System Management Guide
31 December 2010
47
Alliance Access 7.0 - AIX
Action
Responsible
Documentation
Install any MX Standards which are to be used (if
required).
New operator
"Installing MX Standards" on
page 50
System Management Guide
To prepare your Destinations, install the Message
Syntax Tables (MSTVs) from the SWIFT Support
application.
New operator
System Management Guide
Still in Housekeeping mode, define the LTs (Logical
Terminals) and assign each to an MST.
New operator
System Management Guide
Restart Alliance Access in Operational mode
New operator
System Management Guide
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
Daily Operations Guide
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.
New operator
Daily Operations Guide
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.
New operator
Daily Operations Guide
Set up the RPC and SSL Security between Alliance
Access and Alliance Workstation (if required).
Alliance Administrator
See "RPC and SSL Security
for Alliance Workstation" on
page 52.
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)
Part B, "Configuring for
SWIFTNet" on page 95
New operator
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))
System Management Guide
Not required for stand-alone Alliance Access:
Check SWIFT communications
Any operator
System Management Guide
Update delivery subsets if they are different from the
defaults (System, Urgent, Normal):
Any operator
System Management Guide
• 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
48
Installation and Administration Guide
Installation
Action
Responsible
Redefine delivery subsets, if the defaults are
insufficient:
Any operator
Documentation
• redefine the subsets by using the SWIFT Interface
application
System Management Guide
• Login with this logical terminal to send the
message
Daily Operations Guide
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.
Alliance Administrator
"Activate the Database
Recovery Mode" on
page 179
Not required for stand-alone Alliance Access:
If you plan to test the connection with SWIFT, then
ensure that the SWIFTNet connection with the
Alliance Gateway is operational.
Alliance Administrator
Part B, "Configuring for
SWIFTNet" on page 95
Install and configure printers (if required)
AIX System Administrator
IBM manuals
System Management Guide
3.4.2
Additional Tasks after a Non-root Installation
Procedure
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.
Log on as root.
2.
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.
31 December 2010
49
Alliance Access 7.0 - AIX
3.4.3
Installing MX Standards
Description
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.
3.4.4
Configuring RMA for Test and Training
Purpose
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.
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 51.
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 107.
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.
50
Installation and Administration Guide
Installation
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
3.4.5
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.
Configuring RMA for the SWIFTNet Integration Testbed
Purpose
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.
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
Purpose
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.
31 December 2010
51
Alliance Access 7.0 - AIX
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.
Launch the Relationship Management application.
2.
From the File menu, select Signing BIC for T&T.
The Define Signing BIC for T&T RMA window appears.
3.4.7
3.
Select a BIC8 to use for signing Test and Training authorisations.
4.
Click OK .
RPC and SSL Security for Alliance Workstation
Introduction
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
52
Installation and Administration Guide
Installation
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 226.
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.
Log on as Alliance Administrator (all_adm).
2.
Open an X-term from the OS Configuration menu in the System Administration window.
3.
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
31 December 2010
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.
2: a certificate
request [default, 1]:
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.
b
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.
c
Enter a password of
your choice:
The key is password-protected. Select a password that
complies with your institution's password policy and the
following rules.
53
Alliance Access 7.0 - AIX
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.
d
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.
e
File name for the
certificate:
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.
f
Overwrite existing
file? [default, n]:
Enter yes (y) to overwrite an existing file: skip to step i, or
enter no (n) to return to step e.
g
File name for the
certificate request:
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.
h
Overwrite existing
file? [default, n]:
Enter yes (y) to overwrite an existing file: skip to step i, or
enter no (n) to return to step g.
i
Enter the
distinguished name
(DN) to be included in
the certificate:
This DN can contain the following attributes:
This DN is needed if
you want to configure
authentication.
• ST for state or province</para>
• C or country<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.
j
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 226.
54
Installation and Administration Guide
Installation
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.
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 226.
3.4.8
LDAP Configuration
Description
If you use LDAP and you want to secure the connection between Alliance Access and an LDAP
authentication server, then the following must be taken into account.
The iKeyman key management utility (gsk7ikm) is used to manage the CMS keystore that
contains SSL certificates. Gsk7ikm is a Java program and requires a JRE to run. Furthermore, it
can handle a CMS keystore format only if the JRE is configured with the IBM CMS security
provider. The user selects the JRE by setting the environment variables JAVA_HOME and PATH:
export JAVA_HOME=<JRE installation directory>
export PATH=$JAVA_HOME/bin:$PATH
The standard JREs provided with AIX v6.1 and installed in /usr/java14 or /usr/java5 are
configured with the IBM CMS security provider.
3.4.9
The Alliance Developers Toolkit
Introduction
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)).
31 December 2010
55
Alliance Access 7.0 - AIX
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.
3.4.9.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.
Both packages are available on AIX.
3.4.9.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.
56
Installation and Administration Guide
Installation
3.4.10 Install Alliance Developers Toolkit Third Party Software
Applications
Introduction
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
Utility
Description
Software
Install a component
Initial installation of the software of a new
component
Upgrade a component
Upgrading the software of an existing component
to a more recent version
Remove a component
Remove all the software of an existing component
Add a patch
Add a patch to an existing component
Remove a patch
Remove the last installed patch from an existing
component
Register a component
Register to SWA services: either for a new
component or for an upgrade
Unregister a component
Unregister the component
Services
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.
31 December 2010
57
Alliance Access 7.0 - AIX
4
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 AIX
to AIX).
Tip
If you are migrating to a new host, then follow the instructions in "Prepare a
Backup File for Upgrade" on page 27 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 31). 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.
2. You must have the necessary AIX patches available. For details, see the Release Letter.
58
Installation and Administration Guide
Upgrade
3. For a silent upgrade, you must prepare the following files:
– a licence file. See "Prepare the Licence File" on page 20.
– a response file. See "Prepare the Response File (for Silent Installation, Upgrade,
Relicensing, or Removal)" on page 21.
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. In the home directories of all_adm (/home/all_adm), check for the presence of
the .swa.<instance-name>.rc file.
If this file is present, comment out the following line if present in the file:
EXPORT NSORDER = local,local,local
Do this by inserting a # character at the beginning of the line, for example:
# EXPORT NSORDER = local,local,local
6. 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.
7. 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.
8. 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.
9. From the Application Interface application, select all the message partners and disable
them.
10. 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.
11. 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.
31 December 2010
59
Alliance Access 7.0 - AIX
12. 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.
13. 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.
14. 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.
15. Prepare the migration from strict to relaxed certificate mode. See the Release Letter for
detailed instructions.
16. Stop the Alliance Access servers.
17. 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.
18. 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.
19. 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.
20. 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 179
for details.
60
Installation and Administration Guide
Upgrade
Checklist
Task
The host satisfies the system requirements.
Reference
"Prepare the System" on
page 15
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
If upgrading to a new host:
The backup file from the previous release is available
"Prepare a Backup File for
Upgrade" on page 27
Prepare the migration from strict to relaxed certificate mode.
Release Letter
4.2
Interactive Upgrade
4.2.1
Starting the Upgrade From DVD
Remote DVD drive
To start the upgrade from a remote DVD drive, see "Upgrading From a Remote DVD Drive" on
page 62.
To start the upgrade from DVD:
1.
Log on as root.
Note
2.
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:
export DISPLAY=<IPaddressComputer>:0.0
where <IPaddressComputer> must be replaced by the IP address for the computer
where the upgrade windows will be displayed.
3.
A directory mount point must first be made for the DVD and then the DVD must be
mounted.
Log on as root and create a mount point directory, for example MNT:
mkdir /MNT
4.
Insert the Alliance Access release DVD and then mount the DVD by typing:
mount -v cdrfs -r /dev/cd0 /MNT
5.
Navigate to the following directory in the folder for Alliance Access:
/AIX/installer
6.
Start the upgrade by typing:
./saa-install
31 December 2010
61
Alliance Access 7.0 - AIX
To record the upgrade details for future use, run the saa-install command with the record option. See "Record input parameters" on page 86 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.
Insert the DVD on the remote machine.
2.
Mount the DVD on the remote machine.
3.
Set the permissions on the remote machine. You have to edit the following files:
~/.rhosts
/etc/exports
4.
Share/export this file system on the remote machine as an NFS resource.
5.
Create a mountpoint on the local machine.
6.
Mount the remote directory on the local machine.
7.
Access the DVD from the local machine using the local name <mountpoint> for the remote
directory.
For example:
cd /<mountpoint>/AIX/installer
8.
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 86 for more information.
4.2.2
Starting the Upgrade From Local Directory
Remote directory
To start the upgrade from a remote directory, see "Upgrading From a Remote Directory" on
page 63.
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:
export DISPLAY=<IPaddressComputer>:0.0
where <IPaddressComputer> must be replaced by the IP address for the computer
where the upgrade windows will be displayed.
3.
A directory mount point must first be made for the DVD and then the DVD must be
mounted. Log on as root and create a mount point directory, for example MNT:
mkdir /MNT
62
Installation and Administration Guide
Upgrade
4.
Insert the DVD and then mount the DVD by typing:
mount -v cdrfs -r /dev/cd0 /MNT
5.
Copy the DVD contents to an install directory on hard disk:
mkdir <install directory>
cd <install directory>
cp -r /MNT/* .
6.
Unmount the DVD:
cd ~
umount /MNT
7.
Navigate to the following directory in the created install directory:
/AIX/installer
8.
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 86 for more information.
9.
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.
Copy the DVD contents to an directory on the remote machine.
2.
Share/export this file system on the remote machine as an NFS resource.
3.
Mount this file system on the local machine.
4.
Access the directory from the local machine using the local name <mountpoint> for the
remote directory.
For example:
cd /<mountpoint>/AIX/installer
5.
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 86 for more information.
31 December 2010
63
Alliance Access 7.0 - AIX
4.2.3
Upgrade Alliance Access Interactively
Installation event log
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.
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.
64
Installation and Administration Guide
Upgrade
5.
Browse to the location of the backup file that you created in "Prepare a Backup File for
Upgrade" on page 27. You cannot use a backup file created with Alliance Access Release
6.x.
6.
Click Next .
The Installation Location window appears.
7.
Verify the user account displayed in the Owner field and type the password for this
account. This user account is the Alliance Access owner.
8.
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:
31 December 2010
65
Alliance Access 7.0 - AIX
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.
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 20.
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 .
66
Installation and Administration Guide
Upgrade
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 75.
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.
31 December 2010
67
Alliance Access 7.0 - AIX
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.
17. Click Next .
If the password verification fails, then an error message appears. Click OK and enter the
correct input.
18. The Instance Configuration window appears.
Field
Description
Host Name
The host name of the Alliance Access system.
IP Address
The IP address of the Alliance Access system.
Instance Name
The name of the Alliance Access instance on the Alliance Access
system.
Instance Comment
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.
68
Installation and Administration Guide
Upgrade
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 239.
23. Click Finish to complete the upgrade.
Note
Once the upgrade has completed successfully, if you have upgraded from
DVD, remove the DVD as follows:
1. Log on as root and unmount the DVD by typing:
cd ~
umount /MNT
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 unmount the DVD.
2. Log off from the root account.
24. Perform the post-upgrade steps described in the Release Letter. Then follow the
instructions in "Post-Upgrade Checklist" on page 73.
4.3
Silent Upgrade
4.3.1
Starting the Upgrade From DVD Drive
Introduction
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 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 70.
31 December 2010
69
Alliance Access 7.0 - AIX
To start the upgrade process from DVD:
1.
Log on as root.
Note
2.
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:
export DISPLAY=<IPaddressComputer>:0.0
where <IPaddressComputer> must be replaced by the IP address for the computer
where the upgrade windows will be displayed.
3.
A directory mount point must first be made for the DVD and then the DVD must be
mounted.
Log on as 'root' and create a mount point directory, for example MNT:
mkdir /MNT
4.
Insert the Alliance Access release DVD and then mount the DVD by typing:
mount -v cdrfs -r /dev/cd0 /MNT
5.
Navigate to the following directory in the folder for Alliance Access:
/AIX/installer
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:
/tmp/alliance/silent.properties.install.saa.embedded
• -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 73.
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.
4.3.1.1 Upgrading From a Remote DVD Drive
To upgrade from a remote DVD drive:
1.
Insert the DVD on the remote machine.
2.
Mount the DVD on the remote machine.
3.
Set the permissions on the remote machine. You have to edit the following files:
~/.rhosts
/etc/exports
70
Installation and Administration Guide
Upgrade
4.
Share/export this file system on the remote machine as an NFS resource.
5.
Create a mountpoint on the local machine.
6.
Mount the remote directory on the local machine.
7.
Finally, access the DVD from the local machine using the local name <mountpoint> for the
remote directory.
For example:
cd /<mountpoint>/AIX/installer
8.
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:
/tmp/alliance/silent.properties.install.saa.embedded
• -key <value> specifies the key to be used if the password(s) in the response file have
been encrypted.
9.
Perform the post-upgrade steps described in the Release Letter. Then follow the
instructions in "Next Steps" on page 73.
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.
4.3.2
Starting the Upgrade From Local Directory
Introduction
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.
Remote directory
To start the upgrade from a remote directory, see "Upgrading From a Remote Directory" on
page 72.
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.
2.
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 upgrade windows will be displayed.
31 December 2010
71
Alliance Access 7.0 - AIX
3.
A directory mount point must first be made for the DVD and then the DVD must be
mounted. Log on as root and create a mount point directory, for example MNT:
mkdir /MNT
4.
Insert the DVD and then mount the DVD by typing:
mount -v cdrfs -r /dev/cd0 /MNT
5.
Copy the DVD contents to an install directory on hard disk:
mkdir <install directory>
cd <install directory>
cp -r /MNT/* .
6.
Unmount the DVD:
cd ~
umount /MNT
7.
Navigate to the following directory in the created install directory:
/AIX/installer
8.
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:
/tmp/alliance/silent.properties.install.saa.embedded
• -key <value> specifies the key to be used if the password(s) in the response file have
been encrypted.
9.
Perform the post-upgrade steps described in the Release Letter. Then follow the
instructions in "Next Steps" on page 73.
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.
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.
To upgrade from a remote directory:
72
1.
Copy the DVD contents to an directory on the remote machine.
2.
Share/export this file system on the remote machine as an NFS resource.
3.
Mount this file system on the local machine.
4.
Access the directory from the local machine using the local name <mountpoint> for the
remote directory.
Installation and Administration Guide
Upgrade
For example:
cd /<mountpoint>/AIX/installer
5.
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:
/tmp/alliance/silent.properties.install.saa.embedded
• -key <value> specifies the key to be used if the password(s) in the response file have
been encrypted.
6.
Perform the post-upgrade steps described in the Release Letter. Then follow the
instructions in "Next Steps" on page 73.
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.
4.4
Next Steps
4.4.1
Post-Upgrade Checklist
Procedure
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.
2.
Log onto UNIX as Alliance Administrator.
3.
Start the Alliance Access servers in Operational mode.
4.
Both Security Officers (LSO and RSO) must sign on using the Master Passwords taken
from the licensing agreement.
5.
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/
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~
31 December 2010
73
Alliance Access 7.0 - AIX
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.
8.
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.
9.
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.
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 95 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 179 for details.
13. For systems with HACMP licensed, see "Upgrade considerations" on page 125.
4.4.2
Additional Tasks after a Non-root Upgrade
Procedure
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.
Log on as root.
2.
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.
• 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.
74
Installation and Administration Guide
Relicensing
5
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 231 and "The Software Integrity Report" on page 94 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 20.
– a response file. See "Prepare the Response File (for Silent Installation, Upgrade,
Relicensing, or Removal)" on page 21.
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
Required task
Licensed destinations
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
31 December 2010
75
Alliance Access 7.0 - AIX
Licensed options
Required task
• routing rules
5.2
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.
Packages
14:DATABASE RECOVERY
Deactivate the database recovery mode.
16:FILE AUTOMATED
No action required. Print message partners
are not affected. Note that automated
message partners are changed to manual.
18:CAS TCP-IP
Remove all message partners that use TCP/
IP. If not removed, then they are disabled.
Interactive Relicensing
Overview
Use this procedure to add new packages and modify existing packages in interactive mode.
Procedure
1.
Log on as Alliance Administrator (all_adm).
2.
Open an X-term from the OS Configuration menu in the System Administration window.
3.
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 86 for more information.
4.
The installation application unpacks the files in the installer.
The Packages Configuration window appears.
76
Installation and Administration Guide
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 20.
Then click Next and proceed to step 11.
6.
Select the licensed components, using the items listed in the Packages section of your
licensing agreement. Then click Next .
7.
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.
31 December 2010
77
Alliance Access 7.0 - AIX
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.
12. Click Next .
If the password verification fails, then an error message appears. Click OK and enter the
correct input.
The Installation Summary window appears.
13. Check that the details displayed are correct, and if so, click Install . Once you click Install , it
is not possible to abort the software relicensing. If the details are not correct, click Previous
to return to the previous screen(s) and make your corrections.
The software relicensing begins.
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 79.
78
Installation and Administration Guide
Relicensing
5.3
Silent Relicensing
Overview
Use this procedure to add new packages and modify existing packages in silent mode.
Procedure
1.
Log on as Alliance Administrator (all_adm).
2.
Open an X-term from the OS Configuration menu in the System Administration window.
3.
Close the System Administration window.
4.
At the command prompt, type:
./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 be used if the password(s) in the response file have
been encrypted.
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
Required task
Licensed Destinations
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.
• remove the emission profiles, reception profiles, input channels,
and output channels related to these destinations.
31 December 2010
79
Alliance Access 7.0 - AIX
Licensed Options
Required task
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.
80
Installation and Administration Guide
Removal
6
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.
Log on as root.
2.
Open a Korn shell.
3.
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.
31 December 2010
Click Next to proceed, or Cancel to terminate the process.
81
Alliance Access 7.0 - AIX
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.
6.3
8.
Click Finish .
9.
Reboot your system.
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 21.
• the Alliance Access servers are stopped.
Procedure
1.
Log on as root.
2.
Open a Korn shell.
3.
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.
82
Reboot your system.
Installation and Administration Guide
Patches
7
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 21.
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
31 December 2010
83
Alliance Access 7.0 - AIX
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 21.
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.
84
Installation and Administration Guide
Additional Information
8
Additional Information
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 19.
2.
A non-root user logs on using the owner account of Alliance Access and launches the
installer to begin the installation.
3.
Complete any post-installation or post-upgrade tasks. For more information, see "Additional
Tasks after a Non-root Installation" on page 49 or "Additional Tasks after a Non-root
Upgrade" on page 74.
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 86.
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.
• 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.
31 December 2010
85
Alliance Access 7.0 - AIX
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 22.
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 86.
• 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 21.
• 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.
86
Installation and Administration Guide
Additional Information
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 20.
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 91.
• 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 22.
31 December 2010
87
Alliance Access 7.0 - AIX
Response file parameters
Patch removal
Patch installation
Upgrade
system.installOption
Install type
Use base (installation), or
delta (upgrade).
M
M
-
-
-
-
system.deinstallOption
Uninstall type
Use base (full system
removal), or delta (patch
removal).
-
-
-
M
-
M
application.key
A keyword that identifies the
product.
Use saa (upgrade from
Alliance Access), or sar
(upgrade from Alliance RMA).
M
M
-
-
M
-
Mandatory.Accept.LicensingTe
rms
Licensing agreement. Must
have the value: Agree
M
M
-
-
M
-
application.installLocation
Installation directory(1)
M
M
-
-
M
-
Parameter name
Description
Removal
Installation
Relicensing
The following table lists the parameters that must be defined in the response file for Alliance
Access:
(2)
application.owner.name
Operating system account that
is the owner of the resulting
instance. For example,
(2)
C
-
-
-
-
-
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
C
C
-
-
-
-
application.instanceName
Instance name
For example: Access
C
-
-
-
-
-
application.instanceComment
Instance comment
C
C
-
-
-
-
licence.left.password
Left Initial password.
You can only use one of the
two parameters in a response
file.
C
C
M
-
-
-
C
C
M
-
-
-
licence.right.password.encry
pted
Right Initial password.
You can only use one of the
two parameters in a response
file.
database.type
Type of database
M
-
-
-
-
-
licence.left.password.encryp
ted
licence.right.password
88
Installation and Administration Guide
installer.delta.tmpdir
upgrade.deleteAuditCards
Temporary directory for the
database upgrade
-
Delete audit cards
Use the value:
true - delete audit cards
-
M
Patch removal
Patch installation
Removal
Relicensing
Description
Upgrade
Parameter name
Installation
Additional Information
-
-
-
-
-
-
-
-
(3)
M
false - cancel the upgrade
(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
Patch removal
Patch installation
Removal
Description
Installation
Parameter name
Relicensing
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:
oracle.listener.host
Host name or IP address of
server which hosts the Oracle
instance.
C
-
-
-
-
oracle.listener.port
Port number used to connect to C
the Oracle instance.
If not defined, then the default
port number is used: 1521
-
-
-
-
oracle.sid
Oracle service ID of the Oracle
instance.
C
-
-
-
-
database.tablespace.data.name
The tablespace from the
database where tables that
hold the Alliance Access
configuration data will be
created.
For example: SAA_DATA
C
-
-
-
-
database.tablespace.event.name
The tablespace from the
database where tables that
hold the Alliance Access
events will be created.
C
-
-
-
-
31 December 2010
89
Patch removal
Patch installation
Description
Removal
Installation
Parameter name
Relicensing
Alliance Access 7.0 - AIX
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
C
-
-
-
-
database.tablespace.file.name
The tablespace from the
database where tables that
hold the Alliance Access
FileAct payloads will be
created.
For example: SAA_FILE
C
-
-
-
-
database.tablespace.temp.name
The tablespace from the
database where tables will be
created to hold the Alliance
Access restored data.
For example: SAA_TEMP
C
-
-
-
-
database.temporary.schema.name
Database temporary schema
owner name
C
-
-
-
-
database.temporary.schema.passwo
rd
Password for the temporary
database schema owner.
You can only use one of the
two parameters in a response
file.
C
-
-
-
-
database.schema.name
Database schema owner name
C
-
-
-
-
database.schema.password
Password for the database
schema owner.
You can only use one of the
two parameters in a response
file.
C
-
-
-
-
database.user.name
Database user name to be
used by the Alliance Access
server to connect to the
database
C
-
-
-
-
database.user.password
Password for the database
user name.
You can only use one of the
two parameters in a response
file.
C
-
-
-
-
database.temporary.schema.passwo
rd.encrypted
database.schema.password.encrypt
ed
database.user.password.encrypted
90
Installation and Administration Guide
Additional Information
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 86.
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 20.
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
Procedure
1.
Log on with the root account.
2.
Open a Korn shell.
3.
Insert the Alliance Access release DVD.
4.
Change to the AIX directory.
31 December 2010
91
Alliance Access 7.0 - AIX
5.
Locate the checkhost tool by typing:
#cd <Mount point CD>/AIX/checkhost
6.
8.4.2
Launch the checkhost tool.
checkhost Syntax and Examples
Syntax
checkhost.ksh [-req <pathname of requirements file>]
[-rootdir <pathname of a directory>]
[-out <pathname of the report file>]
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
To specify
-req
the path to a requirements file
-rootdir
the path to a drive or file system against which the checkhost
tool must perform a disk space validation.
-out
a location for the report file. If not used, then the report is
produced in the following default location:
/tmp/checkhost.log
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
Overview
When running the checkhost tool without specification of a requirements file, the following
report details are produced:
Information
Unit
Checkhost command invoked
CPU type
CPU speed
MHz
Number of CPUs
Memory size(1)
92
MB
Installation and Administration Guide
Additional Information
Information
Unit
OS version
Local hostname
Free disk space
MB
Installed software
Installed patches
Network adapters
IP addresses
File systems
Paging space
MB
OS language
Local time zone
DNS server
Network options(2)
(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
Overview
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.
Requirements file
The access.dat file is found on the release DVD, in the AIX/installer folder. It contains the
base requirements for installing or upgrading to Alliance Access 7.0.
8.4.5
Error Messages and Warnings
Error messages
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.
31 December 2010
93
Alliance Access 7.0 - AIX
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'.
AIX process warnings and errors
There may be cases when the number of processes owned by the Alliance Access
administrator (for example, all_adm) exceeds the value of the maximum number of processes
that are running per user. This may be due to scripts that are running for monitoring, or opening
several Application Interface Message Partner sessions simultaneously.
If the checkhost tool reports a warning or failure against the number of available processes on
AIX, then increase the number of processes from the default setting of 128 to the required
number (for example, 16384) with the command:
chdev -l sys0 -a maxuproc=16384
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 generation of the software integrity report and the result of the software integrity check are
included in the installation log file produced during the installation, upgrade, or patch operation.
The reports can also be generated at any time by using the saa_system integrity command,
as described in "Checking the Alliance Access Software Files" on page 231.
Types of Integrity report
The Integrity Verification Tool can produce the following types of integrity reports:
Report Type
Description
When to Generate and Check
Full
A report is produced for all the software
files of Alliance Access.
• Before software upgrade (from
release 7.0 onwards)
• Before patch installation
• Before relicensing
Partial
94
A report is produced for specific software
files (.exe, .dll) of Alliance Access.
Before starting the Alliance Access
servers.
Installation and Administration Guide
Part B - Configuring for SWIFTNet
Part B
Configuring for SWIFTNet
31 December 2010
95
Alliance Access 7.0 - AIX
96
Installation and Administration Guide
Introduction
9
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 98.
• 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 111.
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.
31 December 2010
97
Alliance Access 7.0 - AIX
10
Check Connectivity
10.1
Configure SWIFT DNS Servers
Description
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
10.2
To configure the DNS, you do not need the SNLOwner Account. You can use the
root account.
Confirm Connectivity
Description
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.
98
Installation and Administration Guide
Defining Alliance Access in Alliance Gateway
11
Defining Alliance Access in Alliance
Gateway
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
Concepts
Message partner 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.
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.
31 December 2010
99
Alliance Access 7.0 - AIX
Note
• Alliance Gateway provides a default message partner called fin_relaxed. This
message partner has the correct settings for connection between Alliance
Access and Alliance Gateway. If you want to use this profile directly, then
change your Alliance Access instance name to relaxed. Otherwise you can
use the settings in the fin_relaxed profile to create a message partner profile. In
this case, remember to give it the same name as your Alliance Access instance,
that is, fin_<your_instance_name>.
This fin_<your_instance_name> message partner must always be defined.
• 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 "Concepts" on
page 99.
2.
In the Type field, select ClientServer.
3.
In the Host Adapter field, select Remote API Host Adapter.
4.
In the Default Message Format for Emission (from Message Partner) field, select
Relaxed SNL Format.
5.
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.
6.
In the Additional Processing section, select Remote API Host Adapter and Local
Authentication, then define the local authentication keys.
7.
Add the Certificates for Relaxed Mode to the message partner details by clicking Add .
8.
Save the message partner details.
9.
Finally, enable the message partner. See the Alliance Gateway Operations Guide,
"Enabling and Disabling a Message Partner".
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.
100
Installation and Administration Guide
Defining Alliance Access in Alliance Gateway
Note
Before you define the Endpoint, you must have defined the message partner to be
used by the Endpoint.
Alliance Gateway provides a default Endpoint called fin_relaxed. You can use the
settings for this endpoint as an example to create your
fin_<your_instance_name> 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 99.
• 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 99, 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 101.
• from the Mode option buttons, select Relaxed.
11.3
3.
Save this configuration.
4.
Finally, enable the Endpoint. See the Alliance Gateway Operations Guide, "Enabling and
Disabling an Endpoint".
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.
31 December 2010
101
Alliance Access 7.0 - AIX
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 "Concepts" on
page 99.
2.
In the Type field, select ClientServer.
3.
In the Host Adapter field, select Remote API Host Adapter.
4.
For the Default Message Format for Emission (from Message Partner) field, select
Relaxed SNL Format.
5.
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.
6.
In the Additional Processing section, select Remote API Host Adapter and Local
Authentication, then define the Local Authentication keys.
7.
Add the Certificates for Relaxed Mode to the message partner details by clicking Add .
8.
Save the message partner details.
9.
Finally, enable the message partner. See the Alliance Gateway Operations Guide,
"Enabling and Disabling a Message Partner".
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 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.
102
Installation and Administration Guide
Defining Alliance Access in Alliance Gateway
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 100.
• from the Mode option buttons, select Relaxed.
11.4
3.
Save this configuration.
4.
Finally, enable the Endpoint. See the Alliance Gateway Operations Guide, "Enabling and
Disabling an Endpoint".
Data Encryption/Gateway Authentication between
Alliance Access and Alliance Gateway
Description
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".
31 December 2010
103
Alliance Access 7.0 - AIX
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).
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.
Associated Alliance Gateway
message partner
fin_<instance>
In other words, such an Authoriser DN is a certified FIN
User.
12.1
Defining a SWIFTNet Connection
Overview
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.
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.
104
Installation and Administration Guide
Configuring Alliance Access for FIN Messaging
12.2
Assigning a SWIFTNet Connection to a Logical
Terminal
Overview
For information about assigning a SWIFTNet connection to a Logical Terminal, see "Assigning
SWIFTNet Connections to a Logical Terminal" in the System Management Guide.
12.3
Sending and Receiving a Test MT Message
Procedure
1.
Ensure that the Alliance Access servers are running in Operational mode.
2.
Sign on through Alliance Workstation as an operator with message processing
entitlements.
3.
Open the Message Creation application.
4.
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.
5.
Route the message to the _SI_to_SWIFT queue.
6.
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.
12.4
Access to the SWIFTNet FIN Test Service
(Vendors only)
Important
This section is to be used only by SWIFT, its partners, and vendors (your BIC must start with
PT).
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.
31 December 2010
105
Alliance Access 7.0 - AIX
Procedure
1.
Log on to UNIX as Alliance administrator.
2.
Using vi or another text editor, open the file $HOME/.swa.$ALLIANCE_INSTANCE.rc.
3.
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 were running while setting the variable, you must do the following:
• Stop theAlliance Access servers and the bootstrap.
• Close the System Administration window, and open it again.
• Start theAlliance Access bootstrap and the servers.
106
Installation and Administration Guide
Configuring Alliance Access for InterAct and FileAct Messaging
13
Configuring Alliance Access for InterAct
and FileAct Messaging
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.
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
13.1
Associated Alliance Gateway
message partner
sni_<instance>
Defining a SWIFTNet Connection
Overview
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 104.
13.2
Installing Application Service Profiles
Overview
You must install the latest Application Service Profiles on Alliance Access to correctly send and
receive traffic for InterAct or FileAct services. For more information, see ''Installing Application
Service Profiles" in the System Management Guide.
13.3
Configuring SWIFTNet Emission and Reception
Profiles
Purpose
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.
31 December 2010
107
Alliance Access 7.0 - AIX
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.
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.
Configure an emission profile for each licensed BIC8. See "Defining Emission Profiles" in
the System Management Guide.
2.
Configure a reception profile for each licensed BIC8. See "Defining Reception Profiles" in
the System Management Guide.
3.
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.
4.
If required, assign an input channel to an emission profile. For more information, see "Set
Up Input Channels" in the System Management Guide.
5.
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.
13.4
Sending and Receiving an InterAct or a FileAct
Message
Note
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.
108
2.
Route the message to the _SI_to_SWIFTNet queue.
3.
Ensure that the Alliance Access servers are running in Operational mode.
4.
Sign on through Alliance Workstation.
5.
Open the SWIFTNet Interface application.
6.
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 107.
Installation and Administration Guide
Configuring Alliance Access for InterAct and FileAct Messaging
7.
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 107.
8.
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.
31 December 2010
109
Alliance Access 7.0 - AIX
110
Installation and Administration Guide
Part C - System Administration
Part C
System Administration
31 December 2010
111
Alliance Access 7.0 - AIX
112
Installation and Administration Guide
Introduction to System Administration
14
Introduction to System Administration
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
Introduction
Alliance Access provides a dedicated application which is used exclusively by the Alliance
administrator.
31 December 2010
113
Alliance Access 7.0 - AIX
14.1.1 Selecting an Instance
Overview
Whenever you log into AIX 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 115.
To select an instance:
1.
Log into AIX as Alliance Administrator and enter the relevant password. The Alliance
Application Instance Selection window appears.
2.
Select an instance by selecting it, and then select Open from the Instance menu.
3.
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 116.
114
Installation and Administration Guide
Introduction to System Administration
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 AIX 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 116. The detailed use of each command is given
later, within the appropriate section (for example, "General System Maintenance").
31 December 2010
115
Alliance Access 7.0 - AIX
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 242for information.
• Print Screen. See "General System Maintenance" on page 128 for information.
• Clear. See "General System Maintenance" on page 128 for information.
• Exit. See "General System Maintenance" on page 128 for information.
116
Installation and Administration Guide
Introduction to System Administration
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 128 for information.
• List Instances. See "General System Maintenance" on page 128 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 128 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 136 for
information.
• Stop Alliance Servers. See "Managing the Alliance Access Servers" on page 136 for
information.
• JOURNAL_Query. See "General Troubleshooting" on page 242for 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 AIX software for Alliance Access
31 December 2010
117
Alliance Access 7.0 - AIX
• 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
Alliance Access software components
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
Base Service
FSS
File Support Services
INS
Installation Service
MAS
Messenger Adapter Service
MXS
Message Exchange Service
RMS
Relationship Management Service
SIS
SWIFT Interface Service
SNIS
SWIFTNet Interface Service
SNSS
SWIFTNet Support Service
SSS
SWIFT Support Service
TRS
Traffic Reconciliation Services
WSS
Web Service Services
XSS
Standards XML Support Services
The application components are:
118
BSA
Base Application
INA
Installation
Installation and Administration Guide
Introduction to System Administration
MPA
SWIFT Message Preparation
MXA
Message Exchange
RMA
Relationship Management
SIA
SWIFT Interface
SNIA
SWIFTNet Interface
SNSA
SWIFTNet Support
SSA
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
Root directory for Alliance Access
Any Service
Component:
BSS, INS, MAS, MXS, RMS, SIS, SNIS,
SNSS, SSS, TRS, XSS
bin/AIX
Executables
lib/AIX
Run-time libraries
data/AIX
Data, configuration files, parameters files for
printing
nls/AIX
Language-dependent catalogues
install
Installation scripts
log
Error and log files
Any Application
Component:
BSA, INA, MPA, MXA, RMA,SIA, SNIA,
SNSA, SSA
bin/AIX
Executables
lib/AIX
Run-time libraries
data/AIX
Data and configuration files
nls/AIX
Language-dependent catalogues
install
Installation scripts
/usr/swa/insts
Instances registration file
/usr/tmp/alliance
Error and log files
_uninst
Uninstallation scripts
usrdata
User data
data/BIC
31 December 2010
Comment
Contains Alliance Access
executables and command
scripts
Contains Alliance Access
executables and command
scripts
Not in release tree, but an
important directory
Dedicated folder for user
data
Directory for full BIC data
files
119
Alliance Access 7.0 - AIX
$ALLIANCE
Root directory for Alliance Access
data/UpdateBIC
Comment
Directory for partial BIC data
files
Core dumps, resulting from process crashes, are located in the bin/AIX 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 {} \;
120
Installation and Administration Guide
An Introduction to Dual Configuration Support
15
An Introduction to Dual Configuration
Support
Introduction
The Dual Configuration Support package (software and manuals) provides Alliance Access
users with dedicated scripts that are used to configure, start, and stop an Alliance Access
system to make use of IBM's High Availability Cluster Multi-Processing facilities (HACMP).
If your site intends running Alliance Access on "high-availability'" systems (that is, machines
running IBM's HACMP software layer), then you must license the Dual Configuration option
provided by SWIFT.
It is assumed that before any Alliance Access instance is configured within HACMP, the
HACMP cluster is installed already and in an operational condition. For details about installing
and configuring an HACMP cluster, and configuring Alliance Access instances there, see the
HACMP Installation and User Guide.
This section describes the facilities offered by the Dual Configuration Support option and
describes the correct system configuration to be used when running in an HACMP environment.
The scripts provided by the Dual Configuration Support option works correctly only if this
configuration is strictly matched at the customer site. In the case where a different configuration
is required, then the scripts supplied by SWIFT must be customised using the appropriate
instructions in the HACMP Installation and User Guide.
The scripts provided by the Dual Configuration Support option ensure the correct configuration
and installation of Alliance Access on HACMP systems. However, it remains the responsibility of
the local UNIX System Administrator (or Network Administrator) to monitor HACMP systems on
a regular basis.
15.1
Alliance Access Operations
Overview
When using Dual Configuration Support, Alliance Access operations are protected as follows:
• In the event of a LAN adapter failure, the system automatically switches to a backup LAN
adapter, after a short service interruption.
• In the event of a processor failure, the backup processor automatically takes over, recovers
the Alliance Access database and restarts the Alliance Access servers. Following the transfer
of external connections, a fully operational system may be up and running within
approximately 15 minutes (depending upon the size of the recovery log files).
31 December 2010
121
Alliance Access 7.0 - AIX
15.2
HACMP Overview
Description
The HACMP concept is based around the "high availability" or "fault resilient" computing model.
It views availability in terms of a set of system-wide shared resources that co-operate to
guarantee essential services. It combines software and hardware to minimise downtime by
quickly restoring services when a system, or an essential component, fails.
This model does not provide continuous availability, as is the case for "fault tolerant" systems.
Fault tolerant systems are designed to offer no service interruption following a component
failure, but require the use of expensive specialised hardware.
To be highly available, a cluster must have no single point of failure. Cluster components that
are potential single-point of failures include:
• Processors (and associated memory)
• Networks (and adapters)
• Disks (and adapters)
Other components, such as power sources, must not be overlooked. All these components must
be duplicated in the cluster to avoid a single point of failure. However, since there is a cost
associated with each item of redundant hardware, HACMP may be configured to meet the
demand, and thus the budget, of users' processing environments. Therefore, HACMP does not
require an exact duplication of each component. For example, a cluster may be configured with
only one network, which then becomes the single point of failure. "Alliance Access Dual
Hardware Configuration" on page 122 describes the standard HACMP configuration supported
in the Alliance Access environment. Customer customisation of the standard HACMP
configuration is described in the HACMP Installation and User Guide.
Disk failure is not supported directly by HACMP systems. There is no dedicated HACMP
subsystem to operate this component.
The availability of any service in the cluster-wide environment is based on "state-of-health" or
"heart beat" messages, exchanged between nodes. If a node stops sending these messages,
then the peer node automatically takes over and drives the recovery process. It also takes the
necessary action to get critical applications up and running, and to ensure that no data has
been corrupted or lost.
When the failed node rejoins the cluster and starts sending heart beat messages once again,
HACMP detects this come-back, and may decide (depending on user specifications) that the
recovered node has to resume its services. It does this by transferring data and applications
from its peer node back into its own environment. This mechanism is used by default by the
Alliance Access dual configuration software.
All of these mechanisms are performed automatically in the HACMP environment, without
requiring human intervention. Any event, action, or decision taken by HACMP is logged into files
and it is important that these files are closely monitored by the system or network administrator.
Information about handling these files is included in the HACMP Installation and User Guide.
15.3
Alliance Access Dual Hardware Configuration
Introduction
The standard Alliance Access dual-hardware configuration is illustrated below. This is a proven
definition of a working dual hardware configuration. If your system is configured according to
these requirements then the scripts supplied by SWIFT work without customisation. If your
122
Installation and Administration Guide
An Introduction to Dual Configuration Support
requirements are different, then the scripts must be modified using the information provided in
the HACMP Installation and User Guide, and in particular the section "Configuring Alliance
Access in HACMP".
SWIFTNet Link
Alliance Access
SCSI
controller
Shared Disk
SCSI
controller
Primary node
Secondary node
AIX
HACMP
Network card
Network card
heartbeat
RS232 serial cable
AIX
HACMP
Network card
Network card
SWIFTNet Link-VPN connectivity
SWIFTNet
Hardware
Security
Module
D0340155
Managed CPE
The minimal requirements for Alliance Access running the standard AIX Cluster configuration
are two systems, each one with:
• one internal disk and one on-board Ethernet adapter (#1)
• Ethernet adapter (#2)
• SCSI-DE Fast/Wide controller
• 8-Port Serial adapter (replaced by graphic adapter if GUI) with:
– serial 1 - local ASCII terminal
– serial 2 - serial connection between the two systems (for "heart beat" signal)
– serial 3 - connection for an HSM
Each system may have its own internal disk and is connected to external shared SCSI-DE fast/
wide disks.
Nodes
The cluster is made up of two AIX systems, connected through:
• a single Ethernet LAN (each through two LAN adapters)
• a serial line
31 December 2010
123
Alliance Access 7.0 - AIX
Disks
The Alliance Access release tree, database, and archives, can each reside in a different logical
volume. However, their respective volume group must fully reside on the external disks (HD1-3).
They may not be stored in the root volume group or in the internal disk of any of the two
systems. The single exception to this rule concerns the Alliance Access instance information
which is stored in the /usr/swa directory.
Note
This restriction does not exist in non-dual system configurations, where the internal
disk is usually configured to store the root volume group of the computer, as well
as the full UNIX operating system, its related software, system spaces and non
critical applications.
The external SCSI disks (HDi) must be shared between the two nodes. They are connected to
the same shared SCSI bus (having a different address on each system) through a SCSI-2
Differential interface. To avoid down-time in the event of failure of a shared SCSI configuration,
it is recommended to attach the three disks to different SCSI buses.
The initial configuration of any volume group of the shared disks must be performed only once
on the source node: then imported through the SMIT interface (using importvg and HACMP
commands cl_scdiskreset) on the second node. This avoids inconsistent definitions of the
same logical volumes on both nodes. This aspect is covered in detail in the HACMP Installation
and User Guide.
Network
Each of the two systems is connected to an Ethernet TCP/IP LAN using two network adapters
(for example, 'en0' and 'en1'). Each of these four adapters is identified by a different adapter
label. These labels and their respective IP addresses are specified in the /etc/hosts files (for
example, '149.134.52.122 N_1_service'). In addition to this, there must be one entry for the
"service" IP address and label in the /etc/hosts files.
In short, each system has two network adapters, requiring in total five entries in it's /etc/hosts
file. For example:
Node 1
Node 2
Adapter 'en0'
IP label
N_1_boot
149.134.52.121
N_1_service
149.134.52.122
Adapter 'en1'
IP label
N_1_standby
149.134.53.181
Adapter 'en0'
IP label
N_2_boot
149.134.52.123
Adapter 'en1'
IP label
N_2_standby
149.134.53.182
The two standby adapters must be on a separate logical subnet of their peer service-boot
adapters. This is done by using a TCP/IP feature, the network mask, which divides a single
physical network into separate logical subnets. A valid network mask for the "52" and "53"
subnets is 255.255.255.0. This logically defines for the "52" network, all the 149.134.52.xxx
addresses (where xxx means any number less than 256). The "53" subnet contains all the
149.134.53.xxx addresses.
124
Installation and Administration Guide
An Introduction to Dual Configuration Support
Upgrade considerations
When you upgrade Alliance Access, the copy of /usr/swa on the shared disk is updated. A side
effect is that after hacmp_start_alliance is run the first time, the previous version of swa on the
shared disk overwrites the upgraded version of /usr/swa. Using the wrong (older) version
of /usr/swa/alliance_init prevents activation of tracing. Also, the version information in insts is
set to the previous version number (for example, 6.0 instead of 7.0).
To resolve this situation, each time a software update (upgrade or patch) affects modules
in /usr/swa (for example, alliance_init), the following post-installation procedure must be
performed by HACMP users to update the shared copy of swa.
1. Log on as root or enter:
su root
2. Enter the appropriate password.
3. In an Xterm session, type:
$ALLIANCE/BSS/bin/AIX/hacmp_report_config
4. From the output file, in the clshowres section of resource_group_name:
– In SWA_RESOURCE, note the first file system on the file systems line.
– Check for the swa directory in that file system.
– Overwrite swa copy with /usr/swa one. For example, if the file system is /alliance, use:
cp -frp /usr/swa /alliance Node 2 Adapter 'en0' IP label N_2_boot
149.134.52.123 N_2_service 149.134.52.124 Adapter 'en1' IP label
N_2_standby 149.134.53.182
Takeover assumptions
For Alliance Access, it is assumed that there are identical devices and external connections on
both systems. During a takeover, the host name in all the necessary Alliance Access database
records is automatically renamed. Following a takeover, users are required to reconnect the
relevant lines and devices onto the working system.
15.4
Important Technical Documentation on Dual
Configuration and HACMP
Introduction
The HACMP Installation and User Guide contains all details about the installation, and
configuration of an HACMP cluster, and the installation and configuration of Alliance Access
instances. The more relevant parts of this guide are reviewed in the following overview.
The whole HACMP configuration and Alliance Access installation in an HACMP cluster is
covered in 11 steps.
31 December 2010
125
Alliance Access 7.0 - AIX
15.4.1 Overview of the Contents of the HACMP Installation
and User Guide
Hardware installation
The hardware installation of an HACMP cluster is the first practical step to be done on-site. It
follows the hardware planning, ordering, and delivery. It is almost always carried out by IBM
Engineers, and requires minimal intervention by the users. The hardware configuration must be
as per Alliance Access Dual Configuration requirements.
AIX installation
The AIX operating system is the most important component in a cluster. It is therefore essential
that AIX is correctly installed and that the version is compliant with both Alliance Access
systems and HACMP. This section describes the steps to validate the AIX operating system. It
confirms to the user that both (dual) systems are up and running, and that they can be used in
subsequent steps. However, it does not guarantee that all Alliance Access and HACMP
requirements are met. This is done later when installing HACMP and Alliance Access.
HACMP system software installation
This section describes the installation of the HACMP system software on the cluster nodes. An
HACMP cluster is a set from 2 to 32 systems, this guide is based on a two-node cluster, but it
can be extended to a larger cluster. This installation of the HACMP system software must be
fulfilled separately on each node. If HACMP is already installed and verified on one or both
systems, then a new HACMP installation must not be carried out. If an obsolete or unknown
HACMP configuration is currently installed, then a new HACMP installation must be performed.
Cluster configuration
In eight steps, this section describes the software configuration of the HACMP cluster. There is
no reference to IBM software application, only to the system configuration tasks required to
make HACMP operational.
Note
This section is complex. The example in this section configures a basic cluster. At
the end, the HACMP cluster can operate successful takeovers and re-integrations.
This is validated by a test application.
Alliance Access installation and configuration
The installation of Alliance Access in an operational HACMP cluster is performed in three steps:
1. install Alliance Access on host_1
2. synchronise files and install Kernel Extensions on host_2
3. configure Alliance Access in HACMP.
126
Installation and Administration Guide
An Introduction to Dual Configuration Support
15.4.2 Checklist
Description
The following list is a chronological summary of the stages required to install, from scratch, an
operational Alliance Access system on an HACMP cluster. The first column is the sequence
number of the step. The second column is a short description of the step, and the third column
indicates where you can find detailed information.
Step
Description
See
1
Install the hardware
IBM manuals
2
Install all the system software (AIX, HACMP,
and so on)
IBM manuals
3
Configure and verify the HACMP cluster
HACMP Installation and User Guide
4
Install Alliance Access instances
See "Launching the Interactive Installation
From DVD" on page 32, and the HACMP
Installation and User Guide
5
Configure Alliance Access instances in
HACMP
HACMP Installation and User Guide
31 December 2010
127
Alliance Access 7.0 - AIX
16
General System Maintenance
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 136
– "The "Start Alliance Servers" Command" on page 136
– "The "Stop Alliance Servers" Command" on page 142
• "General Troubleshooting" on page 242
– "The Alliance Configuration Report" on page 242
– "The JOURNAL_query Facility" on page 244
All other administrative commands are described in this section.
Tip
16.1
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 231.
System Management Commands
Overview
The following commands can be used at any time for system management.
128
Installation and Administration Guide
General System Maintenance
16.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.
16.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.
16.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 AIX 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.
16.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.
31 December 2010
129
Alliance Access 7.0 - AIX
16.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.
16.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 AIX 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
# check your user id
$ su - <admin account name>
# supply a password
$ ^D
# EOF character to stop another
# SAA application appearing
16.2
Essential System Maintenance
Introduction
For Alliance Access to function in an efficient and trouble-free manner, the Alliance
Administrator is required to perform certain essential tasks.
130
Installation and Administration Guide
General System Maintenance
16.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
Tip
Start the Alliance Access servers
From the Alliance menu (in the System
Administration application).
16.2.2 During the Business Day
Description
The Alliance Administrator should carry out these tasks during the day:
Task
Tip
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.
See the System Management Guide
React to any unknown alarms, for example "Disk
Space Too Low".
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.
16.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
Tip
Search the Event Journal for any untreated alarms
and for Security Events. Treat as appropriate.
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).
31 December 2010
131
Alliance Access 7.0 - AIX
16.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.
Task
Tip
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.
See the Daily Operations Guide
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:
See the Daily Operations Guide
• back up and remove the Event Journal archives
• back up and remove the Message archives
• back up the Alliance Access database.
132
Installation and Administration Guide
Managing UNIX Accounts
17
Managing UNIX Accounts
17.1
Alliance Administrator Account
Overview
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.
17.2
Security Considerations
Overview
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
31 December 2010
Owner
Group
File Permission
data files
all_adm
alliance, or the default
primary group
rw- --- ---
executables
all_adm
alliance, or the default
primary group
rwx r-x r-x
133
Alliance Access 7.0 - AIX
17.3
The alliance_init File
Description
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>]}
where:
17.4
-a
specifies that the user is Alliance administrator
-i
specifies the instance name
-x
specifies use X mode for instance selection
-s
specifies to only set the environment variables
-S
outputs to standard output the exports of environment variables
-e
specifies an external command, for example ksh
<cmd>
is an Alliance Access command, for example start_server
<args>
are optional arguments to the command.
Workstation IP Address Checking
Description
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 226.
To enable the change, you have to stop and restart the Alliance Access servers.
17.5
The Instance Registration File
Overview
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
134
Installation and Administration Guide
Managing UNIX Accounts
• instance comment.
31 December 2010
135
Alliance Access 7.0 - AIX
18
Managing the Alliance Access Servers
Introduction
Alliance Access is designed around a client/server architecture. Typically, "servers" are a
collection of processes that access a database and perform the background processing, while
"clients" are applications that communicate with the servers.
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>]
The following commands are used (by the Alliance administrator) to manage the Alliance
Access servers:
• Start Alliance Servers
• Stop Alliance Servers
These two commands have their equivalent UNIX command line scripts:
• saa_system start
• saa_system stop
Note
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 shut down
the servers.
Another related feature is the saa_system stop force script which may be used in extreme
circumstances to force the termination of all Alliance Access server processes. For information,
see "Starting and Stopping the Alliance Access Server" on page 232.
18.1
Starting the Alliance Access Servers
18.1.1 The "Start Alliance Servers" Command
18.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
136
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.
Installation and Administration Guide
Managing the Alliance Access Servers
To start the Alliance Access servers:
1.
Log into UNIX as Alliance Administrator.
2.
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.
3.
Select Start Alliance Servers from the Alliance pull-down menu.
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.
Select Extended Reporting, if required. For more information, see "Extended Reporting at
Server Startup" on page 138.
5.
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.
6.
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.
18.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)
31 December 2010
137
Alliance Access 7.0 - AIX
• 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.
18.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.
18.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.
138
Installation and Administration Guide
Managing the Alliance Access Servers
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
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.
18.1.2 The saa_system start Script
Overview
The saa_system start script is used to start the Alliance Access servers. It succeeds only if the
system is not running already. The Alliance Access servers must be running before any client
application can be started by an Alliance Access user.
The Alliance Access servers may also be started from the UNIX command line, by running
either of the following commands:
saa_system start housekeeping
saa_system start operational
18.1.2.1 Starting the Servers
To start the Alliance Access servers:
1.
Log into UNIX as the Alliance Administrator.
2.
Run the following command:
saa_system start
3.
Log off from the Alliance Administrator account.
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 137.
Related alarms
Following initial software installation, one alarm message per live destination is displayed, like:
********************* ALARM ********************
SUBSET DEFINITION: 'XXXX': INITIALISED TO SYSTEM DEFAULT
31 December 2010
139
Alliance Access 7.0 - AIX
Such alarms, which are logged also 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.
18.1.2.2 Starting the Servers in Operational or Housekeeping Mode
Housekeeping mode
To start the servers in Housekeeping mode (to perform maintenance and security tasks), use
the following command:
saa_system start housekeeping
Operational mode
To start the servers in Operational mode (to perform operational tasks), use the following
command:
saa_system start operational
18.1.3 Checking that the Servers are Running
To determine which Alliance Access processes are currently running:
1.
Log into UNIX as Alliance Administrator. The main window of the System Administration
application is displayed (you may have to select an instance first).
2.
Select Xterm from the OS Configuration pull-down menu.
3.
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
18.2
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.
Stopping the Alliance Access Servers
18.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.
140
Installation and Administration Guide
Managing the Alliance Access Servers
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 233.
The following table details the various disk space parameters that can be set:
Parameter
Description
Default
Frequency
The interval in seconds (in multiples of 60) at
which disk space is checked.
300
Shutdown - MB
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.
1000
Shutdown - Release Dir
Shut down Alliance Access when available
space on the disk of the source tree is less
than this value (in KB).
20000
Warning - MB
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.
5000
Warning - Release Dir
A warning is issued when the available space
(in KB) on the disk of the source tree is less
than this value.
50000
Warning - Printer Spool
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.
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:
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
31 December 2010
141
Alliance Access 7.0 - AIX
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.
18.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.
2.
Select Stop Alliance Servers from the Alliance pull-down menu.
3.
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.
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.
142
Installation and Administration Guide
Managing the Alliance Access Servers
18.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 142.
18.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.
2.
Select the Xterm command from the OS Configuration pull-down menu.
3.
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.
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.
31 December 2010
143
Alliance Access 7.0 - AIX
18.3
Running Selected Program Scripts following
Server Start and Stop
Description
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
18.4
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).
Monitoring Processes
Introduction
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.
18.4.1 Displaying the Processes
To display the processes:
1.
Run the Monitoring application.
2.
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).
144
Installation and Administration Guide
Managing the Alliance Access Servers
18.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.
18.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.
Select the Monitoring application to display a list of all active processes.
2.
Select the process (or processes) that you want to stop.
3.
From the Action menu, select Processes. The default "action" for processes is to stop the
operation of the selected process.
4.
Select Action | Processes | Stop.
18.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.
31 December 2010
145
Alliance Access 7.0 - AIX
• 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.
146
Installation and Administration Guide
Backing Up Data
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 227.
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 historic 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
Description
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
31 December 2010
An Alliance Access database backup does not include messages or events.
147
Alliance Access 7.0 - AIX
19.2
Archive Backup
Description
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.
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
Overview
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"
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.
Open the System Administration window.
2.
Check the name of your Alliance Access instance in the Instance menu.
3.
Open an Xterm window from the OS Configuration menu.
4.
Change to the home directory of all_adm (normally /home/all_adm) with the cd command.
5.
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
148
Installation and Administration Guide
Backing Up Data
Note
7.
19.4
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.
Save the file and quit the System Administration window.
Performing a Manual Backup of Archives
Introduction
You can create a backup of archives manually using the System Management application.
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
Description
Ready
Alliance Access has created an archive successfully, and the archive is
ready to be backed up.
Done
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.
Run the System Management application.
2.
From the File menu, select Backup.
The Backup Alliance window appears.
3.
Click one of the following tabs:
• Journal Archive
• Message Archive
4.
31 December 2010
In the Backup operating mode field, select Manual.
149
Alliance Access 7.0 - AIX
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
9.
An archive must have the status of Ready or Done, before you can create a
backup for it.
Click OK .
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.
150
Installation and Administration Guide
Backing Up Data
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
Introduction
You can create a backup of the Alliance Access database manually using the System
Management application.
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.
Run the System Management application.
2.
From the File menu, select Backup.
The Backup Alliance window appears.
3.
Click the Database tab.
4.
In the Backup operating mode field, select Manual.
5.
Click Backup .
The Alliance Backup window appears.
31 December 2010
151
Alliance Access 7.0 - AIX
6.
The Backup Directory field specifies the location where Alliance Access creates the
directory for the backup. 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.
Click OK .
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.
Examples of directory names:
20070426T120000_SAA_DATA_BACKUP
20070426T220000_SAA_DATA_BACKUP
152
Installation and Administration Guide
Backing Up Data
19.6
Scheduling Automatic Backups
Overview
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.
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
Description
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.
31 December 2010
153
Alliance Access 7.0 - AIX
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 227 to restore archive backups
– "saa_dbrestore" on page 274 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
Overview
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.
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.
154
Installation and Administration Guide
Restoring Data
To restore an archive backup:
1.
Run the System Management application.
2.
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.
The Backup Directory field contains the current path name of the archive to be restored. If
required, select another path by clicking ... .
6.
Click the transfer arrows to move the archives between the Available pane and the
Selected pane.
7.
Click OK to restore the selected archives.
31 December 2010
155
Alliance Access 7.0 - AIX
If the archive is restored successfully, then a confirmation message appears. Click OK .
20.2
Restoring the Alliance Access Database
When to restore
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.
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 158.
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.
156
Installation and Administration Guide
Restoring Data
20.2.1 Overview of Restoration Process
Database restoration
The restoration of the Alliance Access database involves the following tasks:
1.
Run a consistency check on the data that you are restoring.
2.
Stop the Alliance Access servers.
3.
Restore the data from the backup file (that is, importing it into the database).
4.
Run the saa_configconnection tool to import the Certificate and Private Key. For more
information, see "saa_configconnection" on page 226.
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>
31 December 2010
157
Alliance Access 7.0 - AIX
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 274.
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 158.
• If you have database recovery activated, then you must deactivate it, as described in
"Deactivate the Database Recovery Mode" on page 180.
• 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 274.
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.
158
Installation and Administration Guide
Restoring Data
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.
31 December 2010
159
Alliance Access 7.0 - AIX
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.
160
Installation and Administration Guide
Managing Disk Space
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
Description
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.
21.2
Modifying Disk Space Parameters
Introduction
There are a number of disk space parameters set by default.
To modify disk space parameters:
1.
Run the System Management application.
2.
If the Configuration view is not displayed, then select Configuration from the View menu.
3.
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.
31 December 2010
161
Alliance Access 7.0 - AIX
21.3
System Resources
Description
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.
21.4
How To Recover Disk Space
To recover disk space:
21.5
1.
Remove unwanted files from the system (for example: Core dump files, old files held in
print queues, and so on).
2.
Perform regular archiving of the messages and events.
3.
Clean up archives using the Backup and Remove option in the System Management
application.
Backing Up the Instance Registration File
Description
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'.
162
Installation and Administration Guide
Managing the Database
22
Managing the Database
22.1
Getting Information about the Alliance Access
Database
Introduction
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.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_dbinfo command.
For command location and syntax, see "saa_dbinfo" on page 272.
The tool provides, for the period specified, the available hourly diagnostic information generated
by the database engine.
22.2
Checking the Alliance Access Database
Purpose
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.
Procedure
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
31 December 2010
163
Alliance Access 7.0 - AIX
3.
Enter the saa_system dbintegrity command.
For command location and syntax, see "saa_system" on page 284.
22.3
Configuring the Embedded Database
Purpose
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.
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
164
You cannot use the saa_dbconfig command with a hosted database
configuration.
Installation and Administration Guide
Managing the Database
Working with tablespaces
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_dbconfig tablepsace command.
For command location and syntax, see "saa_dbconfig" on page 271.
Working with the redo log files
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_dbconfig redolog command.
For command location and syntax, see "saa_dbconfig" on page 271.
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 "Classes of Configuration Parameters" in the System Management
Guide.
Displaying and changing memory settings
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_dbconfig command.
For command location and syntax, see "saa_dbconfig" on page 271.
22.4
Backing Up the Alliance Access Database
Purpose
The saa_system dbbackup command is used to back up the complete database of Alliance
Access.
Procedure
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_system dbbackup command.
For command location and syntax, see "saa_system" on page 284.
31 December 2010
165
Alliance Access 7.0 - AIX
You must specify the directory where the backup is to be stored.
Note
22.5
Alliance Access removes the oldest backup if more than two backups exist within
the target backup directory.
The saa_bankquery Tool
Purpose
The saa_bankquery tool provides access to the dedicated Alliance Access database enquiry
and repair facility. The tool is used to verify and repair database entities. It can only be run by
the Alliance Administrator.
Prerequisites
Given the powerful nature of this tool, its use is protected by three passwords:
• the first password is the AIX 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.
Note
An operator using One-Time Passwords cannot use the saa_bankquery tool.
22.5.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.
Log on as Alliance Administrator to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_bankquery command.
For command location and syntax, see "saa_bankquery" on page 270.
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.
166
Installation and Administration Guide
Managing the Database
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.
6.
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
This quits saa_bankquery and returns control back to the Xterm window.
31 December 2010
167
Alliance Access 7.0 - AIX
23
Database Recovery
23.1
About Database Recovery
Introduction
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 176.
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
168
Installation and Administration Guide
Database Recovery
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.
31 December 2010
169
Alliance Access 7.0 - AIX
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 176.
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 backups of archives (messages, 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
Description
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.
170
Installation and Administration Guide
Database Recovery
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
REDOM01.LOG
REDO02.LOG
REDOM02.LOG
REDO03.LOG
REDOM03.LOG
ARCHIVED
REDO LOG
DATAFILES
FULL BACKUPS
D0540176
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
31 December 2010
171
Alliance Access 7.0 - AIX
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 179.
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
23.3
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.
Database Recovery Process
Prerequisites
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 172.
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
172
Installation and Administration Guide
Database Recovery
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.
Restore the latest full recovery backup.
2.
Restore the incremental recovery backups, if any.
3.
Restore and replay the archived redo log files, if any.
4.
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 179.
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.
Locate the last valid transaction available in the redo logs present on the mirror disk.
2.
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:
• Produce a report with the outstanding live message instances following the database
recovery.
31 December 2010
173
Alliance Access 7.0 - AIX
• 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 172.
For more information about possible actions on message instances, see "Processing Repaired
Messages" on page 178.
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 273.
23.4.2 Creating Database Backups in Recovery Mode
Introduction
Alliance Access provides functionality to either schedule database recovery backups or to
manually create a full or incremental database recovery backup.
174
Installation and Administration Guide
Database Recovery
Database recovery backups can be taken manually in either of the following ways:
• 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. This tool is used by customers who prefer to
rely on the external scheduling of these backups instead of relying on the internal Alliance
Access scheduler. For command location and syntax, see "saa_dbrecovery" on page 273.
To schedule database recovery backups, use the Manage Recovery Backups command in the
System Management application. For more information, see "Scheduling Database Recovery
Backups" in the System Management Guide.
A database recovery backup includes all the data present in the Alliance Access database.
However, backed up or restored archives can be excluded. A database recovery backup also
includes database and Alliance Access configuration files (stored outside the database) if these
have been changed since the last recovery backup was taken.
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 however not affect
normal Alliance Access operations.
Description
The following occurs when a database recovery backup is created:
•
If the backup type is:
• Full
– A backup of all the datafiles is created on the recovery backup disk. If the Include
Archive Backups option is not selected, then the datafiles associated to archive
backups of messages and events are not included in the recovery backup.
– The existing incremental backups and the archived redo logs are deleted.
If a previous full recovery backup exists, then this is also deleted at this stage. 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.
• Incremental
– A backup of all the datafiles for which changes have occurred since the last backup
(whatever its type) is created on the recovery backup disk. If the Include Archive
Backups option is not selected, then the datafiles associated to archive backups of
messages and events are not included in the recovery backup.
– The existing archived redo logs are deleted.
31 December 2010
175
Alliance Access 7.0 - AIX
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 177.
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.
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.
176
Installation and Administration Guide
Database Recovery
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.
Stop the Alliance Access servers.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_msgrepair command.
For command location and syntax, see "saa_msgrepair" on page 282.
The outstanding live messages are either completed, routed to _MP_recovery for further
investigation, or left in the routing point.
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.
31 December 2010
177
Alliance Access 7.0 - AIX
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
Tool availability
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.
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.
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.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
How do you want to run the saa_dbrecovery tool?
To launch command
with parameters
178
Then
go to step 4
Installation and Administration Guide
Database Recovery
To launch command
without parameters
4.
Then
go to step 5
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 273.
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 170.
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.
Stop the Alliance Access servers.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
How do you want to run the saa_dbrecovery tool?
To launch command
31 December 2010
Then
with parameters
go to step 4
without parameters
go to step 5
179
Alliance Access 7.0 - AIX
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 273.
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.
Stop the Alliance Access servers.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
How do you want to run the saa_dbrecovery tool?
To launch command
with parameters
180
Then
go to step 4
Installation and Administration Guide
Database Recovery
To launch command
without parameters
4.
Then
go to step 5
Run the command:
saa_dbrecovery -d
For more information about the saa_dbrecovery tool, see "saa_dbrecovery" on
page 273.
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 179.
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.
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.
31 December 2010
181
Alliance Access 7.0 - AIX
To create a database recovery backup:
1.
From the System Administration application, select Xterm from the OS Configuration
menu.
2.
How do you want to run the saa_dbrecovery tool?
To launch
command
3.
Create full backup
Create incremental backup
with
parameters
go to step 3
go to step 5
without
parameters
go to step 4
go to step 6
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 273.
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 273.
6.
Run the command:
1. saa_dbrecovery
2. Select Create Incremental Database Backup.
3. Select Quit.
182
Installation and Administration Guide
Handling System Failures
24
Handling System Failures
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 185.
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
Description
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.
31 December 2010
183
Alliance Access 7.0 - AIX
24.2
Power Failure
Description
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 184.
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 183.
24.3
Disk Failure
Overview
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.
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 154.
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 154.
Note
Before attempting a restore of any data files or archives, check that the backup
directories exist. For example,
$echo $ALLIANCE_DB
184
Installation and Administration Guide
Handling System Failures
24.4
Recovery on a Different Host Using a Cold
Backup
Overview
Following a serious hardware failure, you can select to recover the entire Alliance Access
software using a "Cold Backup" system. This involves recovering all the Alliance Access
software and database, and configuring Alliance Access to run on a new host.
Normally, Alliance Access runs on your "active" system from which you can take daily backups.
Upon failure of the active system, you can restore your most recent backups onto the second
system and continue working from there, again taking daily backups.
When the active system is running again, you can apply the procedure in the reverse order, that
is, take the database backup made from the second (backup) system and restore it onto the
active system.
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 168.
This section describes the steps to be performed, in the context of a recovery using a cold
backup, on the active Alliance Access system and on the backup Alliance Access system, and
how to switch from one to the other.
Where relevant, additional information is provided if you have the licence option 14:DATABASE
RECOVERY.
24.4.1 Set Up the Active System
Prerequisites
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 31.
3. Install any required Alliance Access patches. Make a note of what has been loaded, as the
same patches must also be installed on the backup system.
Set up Alliance Access cold backup
1.
Customise your active system installation as required (for example, define operators,
routing, message partners, and import RMA authorisation data).
2.
Configure your active system for SWIFTNet. See Part B, "Configuring for SWIFTNet" on
page 95.
31 December 2010
185
Alliance Access 7.0 - AIX
3.
Back up the Alliance Access database, see "Backing Up Data" on page 147. 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 168.
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).
5.
Continue to work normally with Alliance Access for live operations.
6.
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.
7.
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.
Notes
• For security reasons, the Message File and Event Journal are not backed up by the database
backup utility. This is to prevent a message already processed from being processed a
second time in error, in particular after restoring from an old backup.
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 168.
• 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.
• SWIFT recommends to perform archival and backups 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
186
Installation and Administration Guide
Handling System Failures
– 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.2 Set Up the Backup System
Overview
You must set up your backup system (install the same operating system software and define
paging space, for example) in the same way as your active system.
Set up 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.
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.
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 156.
To disable the startup of the SWIFT connectivity and ADK applications on Alliance Access
when starting the servers in Operational mode, you can also prevent the SWIFT Interface
Services, SWIFTNet Support Services, or any ADK components from starting by following
these steps:
1. Start the Alliance Access servers in Housekeeping mode.
2. Run the System Management application.
31 December 2010
187
Alliance Access 7.0 - AIX
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 Stop . Repeat this
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 156.
4.
Start the Alliance Access servers, to validate the installation.
5.
Stop the Alliance Access servers.
6.
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 226.
7.
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.
Stop the SIS and SNIS components from the System Management application.
9.
Possibly modify the configuration of your backup system for SWIFTNet (see Part B,
"Configuring for SWIFTNet" on page 95). For example, this can be necessary if the Alliance
Gateway to connect to is located on another host.
10. Start the SIS and SNIS components from the System Management application.
Note
Any changes to ports on the active system must also be made on the backup
system.
24.4.3 Perform a Takeover on the Backup System
Procedure
188
1.
Log on to the backup system as Alliance Access administrator.
2.
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.
Installation and Administration Guide
Handling System Failures
3.
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 156.
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 273.
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 226.
5.
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.
6.
Sign on to Alliance Access (as Supervisor - existing passwords apply) and check whether
the correct configuration of Alliance Access has been recovered.
7.
Stop the SIS and SNIS components from the System Management application.
8.
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.
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 95.
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.
31 December 2010
189
Alliance Access 7.0 - AIX
25
Replication of Configuration Data
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
Description
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:
Export tool
Export file
(User modifiable
file - text format)
Access
D0540183
Access
Import tool
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.
190
Installation and Administration Guide
Replication of Configuration Data
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 193.
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 192.
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 193.
In all of the cases below, the user must have the profile R7.0_Import_Export assigned:
User account
Software Owner Profile is
defined?
Specify -user, or -application,
and -password
all_adm
Y
Optional
N
Mandatory
N
Mandatory
Any other OS account (operator)
31 December 2010
191
Alliance Access 7.0 - AIX
25.2
Handling the Export and Import of Sensitive Data
Overview
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.
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
Y
The password information (password digest) is added to
the export file.
Import
Y
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.
192
Installation and Administration Guide
Replication of Configuration Data
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
25.3
exportsensitiveda
ta specified
Result
Export
N
The password information (password digest) is not
exported to the export file.
Import
N
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.
Entities Eligible for Export and Import
Filtering fields
Entity
Permission required for
export
Permission required for import
Configuration
System Management
System Management: Modify Configuration
Parameter
Correspondent
Correspondent Info - Open/
Print Correspondent Details
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 (5)
SWIFTNet Interface:
• Open/Print Emission Profile
• Add Emission Profile, and/or
• Modify Emission Profile
• Schedule Emission Profile, and/or
• Disable Emission Profile auto (6)
• Enable Emission Profile auto
Event Distribution
31 December 2010
System Management
System Management: Modify Event List
193
Alliance Access 7.0 - AIX
Entity
Permission required for
export
Permission required for import
Exit Point
Application Interface: Open/
Print Exit Point (3)
Application Interface:
• Open/Print Exit Point
• Add Exit Point, and/or
• Modify Exit Point
Input Channel
SWIFTNet Interface: Open/
Print Input Channel (8)
SWIFTNet Interface:
• Adopt Input Channel and
• Open/Print Input Channel
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 (9)
SWIFT Interface:
• Modify LT and
• Add Action, and/or
• Modify Action, and/or
• Remove Action, and/or
• Enable / Disable Auto Mode
• Enable / Disable Reconnect and Own
Destination List (9)
Message Partner
Application Interface: Open/
Print Partner (1)
Access Control: Files on
Server
Application Interface:
• Open/Print Partner
• Add Partner, and/or (2)
• Modify Partner
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
194
Installation and Administration Guide
Replication of Configuration Data
Entity
Permission required for
export
Permission required for import
Output Channel
SWIFTNet Interface Open/
Print Output Channel (8)
SWIFTNet Interface:
• Adopt Output Channel and
• Open/Print Output Channel
Reception Profile
SWIFTNet Interface: Open/
Print Reception Profile RT
and Open/Print Reception
Profile SnF (10)
SWIFTNet Interface:
• Open/Print Reception Profile RT, and/or
• Open/Print Reception Profile SnF
• Add Reception Profile, and/or
• Modify Reception Profile and
• Schedule Reception Profile, (6)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(12)
Routing: Open Routing Point
Routing:
(4)
• Open Routing Point
• Add Rule, and/or
• Modify Rule
• Default Rule (11)
Routing Schema
Routing
Routing:
• Add Schema, and/or
• Modify Schema
SWIFTNet Connection
SWIFTNet Support: SNL
Handling (7)
SWIFTNet Support: SNL Handling (7)
System Queue
System Management
System Management: Modify Queue
Unit
Security Definition
Security Definition:
• Add Unit, and/or
• Modify Unit
31 December 2010
195
Alliance Access 7.0 - AIX
Entity
Permission required for
export
Permission required for import
User Queue
System Management
System Management:
• Add Queue, and/or
• Modify Queue
(1) Permission details: Only Message Partners explicitly allowed (or not explicitly prohibited) are exported or imported.
Default R7.0_Import_Export profile is set up with 'Prohibited: None'.
(2) Permission details: No constraint, because the LAU keys are not imported.
(3) Permission details: Only exit points explicitly allowed (or not explicitly prohibited) are exported / imported. Default
R7.0_Import_Export profile is set up with 'Prohibited: None'.
(4) Permission details: Only routing rules related to routing points explicitly allowed (or not explicitly prohibited) are
exported / imported Default R7.0_Import_Export profile is set up with 'Prohibited: None'.
(5) Permission details: Only profiles set up for explicitly allowed (or non explicitly prohibited) services and BICs are
exported / imported Default R7.0_Import_Export profile is set up with 'Prohibited: None'.
(6) Permission details: When scheduled actions have to be imported (added or possibly overwriting existing ones), the
operator must be allowed to add actions and/or modify actions and/or remove actions as required by the specific
import needs, for the import to be successful. Default R7.0_Import_Export profile is set up with 'Add / modify /
remove actions allowed'.
(7) Permission details: The Connection Handling permission detail must be set to 'Y' to export / import. Default
R7.0_Import_Export profile is set up with SNL Handling, Connection Handling set to 'Y'.
(8) Permission details: Only Input (Output) Channel occurrences belonging to the destinations (BIC8) explicitly allowed
(or not explicitly prohibited) and for destinations that are not licensed are exported or imported. Default
R7.0_Import_Export profile is set with 'Prohibited: None'.
(9) Permission details: Only Logical Terminal (Logical Terminal Definition) occurrences belonging to the destinations
(BIC8) explicitly allowed (or not explicitly prohibited) are exported or imported. Default R7.0_Import_Export profile
is set with 'Prohibited: None'.
(10) Permission details: Only SnF reception profiles set up for explicitly allowed (or non explicitly prohibited) BICs are
exported or imported Default R7.0_Import_Export SnF reception profile is set up with 'Prohibited: None'.
(11) The change of the default action for a routing rule is only allowed in housekeeping mode.
(12) Only user-defined routing rules can be exported or imported. Internal or default routing rules are not exported or
imported.
Settings for LAU keys
Action
196
Result
Export
LAU keys are never exported. Therefore, the LAU keys for Message Partner entities and
SWIFTNet Connection entities are not included in the export file.
Import
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.
Existing entity
LAU keys remain as they are defined already in target
instance.
Installation and Administration Guide
Replication of Configuration Data
25.4
Status Management of Entities for Import
Entity dependencies
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:
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.
Any invalid status stops the export or the import process.
31 December 2010
197
Alliance Access 7.0 - AIX
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.
Entity name
198
New
occurrence
in target
instance?
Prerequisites
Configuration
-
Correspondent
Status in target instance
Before import
After import
ADK Storage parameter is readonly (left unchanged during
import)
-
-
Y
Country and Correspondent type
fields are read-only (left
unchanged during import
-
-
Distribution List
Y
Distribution, if equal to Fixed,
then it is read-only (left
unchanged during import)
-
-
Emission Profile
Y
-
Disabled
Disabled
Event Distribution
-
-
-
-
Exit Point
Y
Assigned Message Partner field
is read-only (left unchanged
during import)
-
-
Input Channel
Y
Add or update = input channel
adoption
The import tool skips updates.
-
-
Logical Terminal
Y
The server must be in
housekeeping mode.
-
-
Logical Terminal
Definition
-
Before update: SIS component
must be stopped
-
-
Message Partner
Y
-
Disabled
Disabled
Operator
Y
-
Disabled
Approved
status:
Unapproved
and
Enable status:
disabled
Operator Profile
Y
-
No operator
using that
operator profile
can be logged
on
All operators
using the
updated
operator
profile get
disabled and
unapproved
Output Channel
Y
Add or update = output channel
adoption
The import tool skips updates.
-
-
Reception Profile
Y
-
Disabled
Disabled
Routing Keyword
Y
-
-
-
Routing Keyword
Definition
-
The server must be in
housekeeping mode.
-
-
Installation and Administration Guide
Replication of Configuration Data
Entity name
New
occurrence
in target
instance?
Prerequisites
Status in target instance
Routing Rule
Y
In some cases, user routing rules existing in the target instance are
deleted before adding the
occurrences present in the export
file.(1)
Before add or update, none of the
assigned routing schemes may
be active.
The server must be in
housekeeping mode to modify
the default action.
After add or update, the assigned
routing schemes become
unapproved.
-
Routing Schema
Y
-
Any
Add:
unapproved
Update:
remains
unchanged
SWIFTNet
Connection
Y
Before add or update: SIS and
SNIS components must be
stopped
-
-
System Queue
-
-
-
-
Unit
Y
-
-
Approval
status: unapproved
(add) or
remains
unchanged
(update)
User Queue
Y
-
-
-
Before import
After import
(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
Description
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.
For more information about the entities that you can export and import, see "Entities Eligible
for Export and Import" on page 193.
• For each entity type, you can specify additional filtering criteria to export specific entity
occurrences.
31 December 2010
199
Alliance Access 7.0 - AIX
– The filtering criteria is optional. If no filtering criteria is 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 criteria.
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 193.
Syntax of the parameter file
The following is the syntax to use in the parameter file:
<entities>
<!-- <Entity_name> -->
<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 the AND, or OR, or both logical
operators for one entity occurrence.
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
200
Description
Mandatory?
<entities>
Denotes the start of the parameter
file.
Y
<!-- <Entity_name> -->
Comments about a specific entity.
N
<entity name='<entity_name>'>
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).
Y
<filterset>
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 no two
filters with the same attrib and op
N
Installation and Administration Guide
Replication of Configuration Data
Element
<filter attrib='<Field_name>'
value='<field_value>'
[op='<operator>'] /> >
Description
If you specify multiple <filter>
elements, then a logical AND is
applied when forming the selection
criteria.
Mandatory?
(2)
attrib - a field by which you can filter
value - value of the field(3).
op - SQL operator:
• GT - greater than (>)
• GE - greater than or equal to (>=)
• EQ- equal to (=)
• NE - not equal to (!=)
• LE - less than or equal to (<=)
• LT - less than (<)
• LIKE - like (like)
The default is 'EQ' (equal).
</filterset>
Denotes the end of the filterset
definition.
N
</entity>
Denotes the end of the entity
definition.
Y
</entities>
Denotes the end of the parameter file.
Y
(1) For a list of entities for which you can replicate configuration data, see "Entities Eligible for Export and Import" on
page 193.
(2) If <filterset> is used, then <filterset> must include at least one <filter> element.
(3) Use either single (') or double-quote (") irrespective of the data type. Use a wildcard (such as, % or _) when the
operator is LIKE.
Example of parameter file with filtering criteria
The following shows an example of a parameter file with filtering criteria for two entities, Routing
Rule, and Configuration:
<entities>
<!-- Routing Rule -->
<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>
31 December 2010
201
Alliance Access 7.0 - AIX
<!-- Configuration -->
<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>
Filtering criteria for correspondents
Use the following filtering criteria to export BICs:
To export
Use
BIC8
the BIC11 filter attribute and positions 9 - 11 set to xxx
BIC11
the BIC11 filter attribute and positions 9 - 11 set to ***
Test and Training BICs
the BIC11 filter attribute and position 8 set 0
Internal Correspondents
the Correspondent Definition filter attribute set to
internal
Correspondents that cannot be modified by
the BIC upload
202
the Update on BIC Load filter attribute set to No
Installation and Administration Guide
Replication of Configuration Data
25.6
Exported Fields
Details
The following fields are exported per entity:
Entity name
Exportable fields
Filter on field?
Correspondent
Institution (BIC11)
✓
Correspondent type
Sub-type
Profile
Institution full name
Branch info
City name
Country
Address
Location
POB number
POB location
Update on BIC load
✓
Correspondent definition
✓
Correspondent status
Preferred language
Comment
Selected integrated applications and their details
Configuration
Component
✓
Object
✓
Parameter
✓
Value
Distribution List
Name
✓
Operators
Selected operators
Selected internal correspondents
SNMP server IP address or port number
31 December 2010
203
Alliance Access 7.0 - AIX
Entity name
Exportable fields
Filter on field?
Emission Profile
Name
✓
Service name
Messaging service
Requestor DN
Delivery mode
Window size
Retry limit
Signing required
Non repudiation required
Use input channel
Input channel
Delivery notification required
Delivery notification queue
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]
Calendar
Schedule category
Manual / Automatic mode
ACTIONS = Action id, Day profile, Time, Action
Event Distribution
Component
Event number
✓
Configuration management
Distribution
Alarm
Type
Distribute alarm
To distribution list
204
Installation and Administration Guide
Replication of Configuration Data
Entity name
Exportable fields
Filter on field?
Exit Point
Name
✓
Queue threshold
Assigned to message partner
Processing order
Modify rules allowed
Display rules allowed
Selected Valid Routing Targets
Maximum message age
Input Channel
Name
✓
Logical Terminal
BIC8 = Destination name
✓
LTCode
✓
MstvId
Window Size
Master BIC for T&T (for T&T LTs only)
Logical Terminal
Definition(3)
BIC8 = Destination name
✓
LTCode
✓
Sequence 1: SWIFTNet Connection name, Use specific
Authoriser DN, [Authorizer DN], Use specific CID Signing
DN, [CID Signing DN]
Sequence 2: SWIFTNet Connection name, Use specific
Authoriser DN, [Authorizer DN], Use specific CID Signing
DN, [CID Signing DN]
Sequence 3: SWIFTNet Connection name, Use specific
Authoriser DN, [Authorizer DN], Use specific CID Signing
DN, [CID Signing DN]
Sequence 4: SWIFTNet Connection name, Use specific
Authoriser DN, [Authorizer DN], Use specific CID Signing
DN, [CID Signing DN]
Auto reconnect
Operation mode
Selection mode
Scheduling category, Calendar, Action ID, Day profile,
Time, Action
Delivery subsets
31 December 2010
205
Alliance Access 7.0 - AIX
Entity name
Exportable fields
Filter on field?
Message Partner
Name
✓
Description
Allowed direction
Connection method
Increment sequence number across sessions
Always transfer MAC / PAC
Transfer PKI signature
DETAILS = details of any type of Connection Method
Local authentication required
Selected exit points
Message emission format
Send original message
Format of original message
Routing code transmitted
Validation level
Profile name
Message modification allowed
Unit to be assigned
Batch file validation
Build unique file transfer reference
Disposition
Message in
Reply
Transfer UUMID
Original message
Validation error code
206
Installation and Administration Guide
Replication of Configuration Data
Entity name
Exportable fields
Filter on field?
Operator
Name
✓
Full name
Application
Authentication method
LDAP user identifier
Display password
Selected allowed profiles
Selected assigned units
Selected Delegated Profiles
Selected Delegated Units
Selected Delegated Destinations
Operator Profile
Name
✓
Selected applications
Selected functions
All Permission Details (if any)
Output Channel
Name
✓
Reception Profile
Name
✓
Delivery mode
Queue name
Window size
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]
Calendar
Schedule category
Manual / Automatic mode
ACTIONS = Action id, Day profile, Time, Action
Routing Keyword
Name
✓
Type
Description
31 December 2010
207
Alliance Access 7.0 - AIX
Entity name
Exportable fields
Filter on field?
Routing Keyword
Definition
Name
✓
MstvId
Field tag
Subfield
Line range from
Column range from
Selected messages
Routing Rule(1)
Routing Point Name
✓
SeqNo
✓
Assigned schemes
✓
Description
Condition on
Selected function result
Message
Action on
Source instance type
Source instance notification type
Source instance action
Source instance selected valid target point
Source instance append intervention
Source instance free text intervention
Source instance Unit
Source instance Routing code
Source instance priority
New instance type
New instance notification type
New instance action
New instance addressee
New instance selected valid target point
New instance append intervention
New instance free text intervention
New instance Unit
New instance Routing code
New instance priority
Last update timestamp(2)
208
✓
Installation and Administration Guide
Replication of Configuration Data
Entity name
Exportable fields
Filter on field?
Routing Schema
Name
✓
Description
SWIFTNet Connection
Name
✓
Hostname
Port number
SSL settings
SSL Certificate
SSL CA Certificate
FileAct port number
FileAct SSL
LAU settings
System Queue
Name
✓
Queue Threshold
Modify rules allowed
Display rules allowed
Selected Valid Routing Targets
Maximum message age
Unit
Name
✓
Full description
User Queue
Name
✓
Modify rules allowed
Display rules allowed
Selected Valid Routing Targets
Maximum message age
(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 criteria 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.
31 December 2010
209
Alliance Access 7.0 - AIX
25.7
Export Configuration Data
Prerequisites
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 199.
To export the configuration data
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_export command.
For command location and syntax, see "saa_export" on page 275.
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
If the import fails, check the report file.
Note
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
Prerequisites
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 will depend 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 Management of Entities for Import" on page 197.
• When an Alliance Access operator launches the import tool, that operator must ensure that
the export file does not contain his/her operator profile. To be able to update an operator, it
must be disabled. To be able to update a profile, no operator using that profile can be logged
on.
210
Installation and Administration Guide
Replication of Configuration Data
• The target Alliance Access is licensed according to the entities that you import.
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, 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
Management of Entities for Import" on page 197.
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 192.
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 193.
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.
31 December 2010
211
Alliance Access 7.0 - AIX
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.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_import command.
For command location and syntax, see "saa_import" on page 277.
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.
Note
25.9
If the import fails, check the report file.
Report File for Configuration Replication
Description
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.
212
Installation and Administration Guide
Replication of Configuration Data
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:
export<timestamp>.log
For import:
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.
31 December 2010
213
Alliance Access 7.0 - AIX
26
Operational Integration
26.1
Overview of Operational Integration
Description
The Operational Integration functionality provides the monitoring and management command
line tools to integrate monitoring and management activities in Alliance Access into third-party
applications.
• The monitoring tool extracts the monitoring information from Alliance Access and stores it in
an XML file. The information can be transferred to other monitoring systems or external
customer applications that perform the monitoring operation.
The monitoring tool produces the output in XML format. If you want to transform the output
format, then you can use the XSLT. A common output format is CSV. Sample files are
provided to show you how to transform the XML format into a CSV format or a fixed width
delimited format.
• The management tool performs dedicated actions on Alliance Access entity occurrences
based on the parameters provided in the manage parameter file. A specific exit code returns
the actual execution status of the command.
The tool manages operations such as enabling or disabling a message partner, logging on to
a logical terminal or logging off from the logical terminal. You can launch the tool manually or
from a scheduler application running outside Alliance Access.
Note
The tools must be executed locally on the source or target Alliance Access
instance for managing and monitoring respectively.
If you want to launch the tools remotely, then you are responsible to ensure that
the remote implementation is secure.
Parameter file validation
The parameter file used during the manage or monitor operation is validated against schema
definitions (.xsd files).
These .xsd files are located in the following directory:
<Alliance installation directory>/bin/xsd
Entities
Entities refer to all defined occurrences of a specific entity type. The entities eligible for
monitoring and managing are most of the entities that can be monitored or managed through
the Alliance Workstation or Web Platform screens.
For a list of entities, see "Entities Eligible for Monitoring and Monitored Fields" on page 218 and
"Entities Eligible for Managing" on page 223.
Permissions required to launch or execute the tools
The Alliance Access software owner (all_adm) or any OS account (operator) defined in the
system can launch the tools.
The permissions for the user executing the tools depend on the value of the "Software Owner
Profile" security parameter.
214
Installation and Administration Guide
Operational Integration
If no value is defined for this parameter, then it indicates that all_adm has no profile assigned,
and therefore does not have the required permissions to execute the export or import
command. In this case, Alliance Access user credentials are required.
Command launcher
Security
parameter
"Software
Owner
Profile" is
defined
Specify user, or
application,
name and
password in
command
Command execution
all_adm
Y
Optional
• If user, or application, name and
password are not provided: all_adm
• If user, or application, name and
password are provided: operator
Any other OS account
(operator)
N
Mandatory
The user, or application, name and
password must be provided to execute
the command
N
Mandatory
The user, or application, name and
password must be provided to execute
the command
The following conditions are applicable:
• If the "Software Owner Profile" security parameter is defined for all_adm, then it is optional to
provide the user, or application, name and password.
• If the "Software Owner Profile" security parameter is not defined for all_adm, then it is
mandatory to provide the user, or application, name and password to run the command.
If any other OS 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.
26.2
Operational Monitoring
26.2.1 Monitoring Data
Prerequisites
Before launching the monitor command, ensure that:
• the Alliance Access server is running in Operational mode
• a monitor parameter file is available, specifying the entities to monitor.
Monitor parameter file
The monitor parameter file is an XML file. It contains the entity types and the selection criteria
used to define the monitoring scope.
For each entity type, one of the following options are applicable for the selection of entity
occurrences to monitor:
• All: all occurrences of the entity type will be monitored
• Summary: provides summary information for an entity type
31 December 2010
215
Alliance Access 7.0 - AIX
• Exception: all occurrences in exception state for that entity type
• Selection: all occurrences matching the user criteria for the entity type
A sample monitor parameter file containing all the entities that can be monitored is provided
when you install Alliance Access. You can find this file in the $ALLIANCE/bin directory. You
can copy and update this file to match your own monitoring criteria.
Note
Summary information is applicable when monitoring Operator Sessions only.
Structure of the monitor parameter file
<MonitorEntities>
<!-- Scope can be "All", "Exception", "Selection" or "Summary" -->
<!-- Scope is optional and default value is "All" -->
<!-- If the criteria is mentioned, then scope will be assumed as
"Selection" -->
<!-- We cannot mention a entity more than once -->
<!-- We can mention criteria as either "LT" or "Name" or "Status" or
"SessionStatus"-->
<!-- Logical Terminal with Scope 'All' -->
<entity name="Logical Terminal"></entity>
<!-- Logical Terminal with Scope 'Selection' -->
<entity name="Logical Terminal">
<LT>SAAABEBBB</LT>
<LT>SAABBEBBB</LT>
</entity>
<!-- Logical Terminal with Scope 'Selection' -->
<entity name="Logical Terminal" scope="Selection">
<LT>SAAABEBBB</LT>
<LT>SAABBEBBB</LT>
</entity>
<!-- Logical Terminal with Scope 'Exception' -->
<entity name="Logical Terminal" scope="Exception"></entity>
<!-- Message Partner -->
<entity name="Message Partner">
<Name>FileInput</Name>
</entity>
<!-- Message Partner -->
<entity name="Message Partner">
<Status>ABORTING</Status>
<Status>CLOSED</Status>
</entity>
<!-- Message Partner -->
<entity name="Message Partner" scope="Exception"></entity>
<!-- Queue -->
<entity name="Queue">
<Name>XYZ</Name>
</entity>
<!-- Queue -->
<entity name="Queue" scope="Exception"></entity>
<!-- Emission Profile -->
<entity name="Emission Profile"></entity>
<!-- Emission Profile -->
<entity name="Emission Profile" scope="All"></entity>
<!-- Emission Profile -->
<entity name="Emission Profile" scope="Selection">
<Name>saaabebb_rma</Name>
<Name>saabbebb_rma</Name>
</entity>
<!-- Emission Profile -->
<entity name="Emission Profile" scope="Selection">
<Enabled>true</Enabled>
</entity>
<!-- Emission Profile -->
<entity name="Emission Profile" scope="Selection">
216
Installation and Administration Guide
Operational Integration
<Enabled>false</Enabled>
</entity>
<!-- Emission Profile -->
<entity name="Emission Profile" scope="Selection">
<SessionStatus>ACTIVE</SessionStatus>
<SessionStatus>ACTIVATING</SessionStatus>
<SessionStatus>DEACTIVATING</SessionStatus>
<SessionStatus>INACTIVE</SessionStatus>
<SessionStatus>INTERRUPTED</SessionStatus>
</entity>
<!-- Emission Profile -->
<entity name="Emission Profile" scope="Exception"></entity>
<!-- Reception Profile -->
<!-- Reception Profile selection criteria is similar to Emission Profile -->
<entity name="Reception Profile"></entity>
<!-- Reception Profile -->
<entity name="Reception Profile">
<Name>saaabebb_rma</Name>
<Name>saabbebb_rma</Name>
</entity>
<!-- System Resource -->
<entity name="System Resource"></entity>
<!-- System Resource -->
<entity name="System Resource" scope="Exception"></entity>
<!-- Process -->
<entity name="Process"></entity>
<!-- Operator Session -->
<entity name="Operator Session"></entity>
<!-- Operator Session -->
<entity name="Operator Session" scope="Summary"></entity>
<!-- File Transfer -->
<entity name="File Transfer"></entity>
</MonitorEntities>
To monitor the data
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_monitor command (for details, see "saa_monitor" on page 280).
Note
If the -duration parameter is not specified, then you can use the Enter key
to stop the cyclic monitoring.
The monitoring results are sent to the monitor output file specified when launching the
command. In case any error occurs and this stops the monitoring process, the information is
sent to STDERR.
Note
31 December 2010
The monitoring tool uses minimal Alliance Access resources even in case of
intensive usage of the tool. The performance does not slow down the system and it
is not required to monitor how much of Alliance Access resources the monitoring
tool uses.
217
Alliance Access 7.0 - AIX
26.2.2 Entities Eligible for Monitoring and Monitored Fields
Details
All the monitored fields are described in "Monitoring the Object Windows" in the Daily
Operations Guide, including the values of the fields on which you can filter occurrences (for
example, status, or session).
Entity name
Monitored
occurrences
Fields used for
occurrence
selection
Monitored fields
Logical Terminal
All or Exception or
Selection
LT or Status
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
218
Installation and Administration Guide
Operational Integration
Entity name
Monitored
occurrences
Fields used for
occurrence
selection
Monitored fields
Queue
All or Exception or
Selection
Name
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
31 December 2010
219
Alliance Access 7.0 - AIX
Entity name
Monitored
occurrences
Fields used for
occurrence
selection
Monitored fields
Process
All
NA
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
220
Installation and Administration Guide
Operational Integration
Entity name
Monitored
occurrences
Fields used for
occurrence
selection
Monitored fields
File Transfer
All
NA
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 support customers' statistical needs. For performance reasons, these counters are not updated upon
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
31 December 2010
221
Alliance Access 7.0 - AIX
26.3
Operational Management
26.3.1 Managing Data
Prerequisites
Before you launch the tool, ensure that:
• the server is running and it is in the housekeeping or operational mode as required by the
action to be performed
• a manage parameter file is present, specifying the entities to manage.
Manage parameter file
The manage parameter file is an XML file. It contains the entity types and the selection criteria
used to specify the entity occurrences to manage.
For each entity type, one of the following options are applicable for the selection of entity
occurrences to manage:
• All: all occurrences of the entity type will be managed
• Selection: all occurrences matching the user criteria for the entity type.
A sample manage parameter file containing all the entities that can be managed is provided
when you install Alliance Access. You can find this file in the $ALLIANCE/bin directory. You
can copy and update this sample manage parameter file to match your own managing criteria.
Structure of the manage parameter file
<ManageEntities>
<!-- At a time only one entity can be managed -->
<!-- Occurrence can be "All" or "Selection" -->
<!-- Occurrence is optional and default value is "All" -->
<!-- If the FieldSet is mentioned, then Occurrence will be assumed as
"Selection" -->
<!-- Component with occurrence 'All' -->
<entity type="Component"></entity>
<!-- Component with occurrence 'All' -->
<entity type="Component" occurrence="All"></entity>
<!-- Component with occurrence 'Selection' -->
<entity type="Component">
<FieldSet>
<field name="Name" value="SIS"/>
<field name="Name" value="SNIS"/>
</FieldSet>
</entity>
<!-- Component with occurrence 'Selection' -->
<entity type="Component" occurrence="Selection">
<FieldSet>
<field name="Name" value="SIS"/>
<field name="Name" value="SNIS"/>
</FieldSet>
</entity>
<!-- Logical Terminal with occurrence 'Selection' -->
<entity type="Logical Terminal" occurrence="Selection">
<FieldSet>
<field name="LT" value="SAAABEBBB"/>
</FieldSet>
</entity>
<!-- Emission Profile -->
<entity type="Emission Profile">
222
Installation and Administration Guide
Operational Integration
<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>
<!-- Reception Profile -->
<entity type="Reception Profile">
<FieldSet>
<field name="Name" value="saaabebb_rma"/>
</FieldSet>
</entity>
<!-- Message Partner -->
<entity type="Message Partner">
<FieldSet>
<field name="Name" value="FileInput"/>
</FieldSet>
</entity>
<!-- Queue -->
<entity type="Queue"></entity>
<!-- Operator -->
<entity type="Operator">
<FieldSet>
<field name="Name" value="user1"/>
</FieldSet>
</entity>
</ManageEntities>
To manage the data
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Run the saa_manage command (for details, see "saa_manage" on page 278).
Note
If you run the command on several occurrences of the specified entity, and the
command fails for one or more occurrences, then the action is stopped but the
action is not rolled back for the occurrences on which it is successfully completed.
The saa_manage tool only launches or triggers the action specified when the
command is issued. It does not wait for a successful completion of the action to
return. For example, for LT login, the tool does not wait until the LT is logged in to
return.
26.3.2 Entities Eligible for Managing
Details
Entity name
Occurrence
identification
Possible actions
Permission required
Component
All or Name field
values
Start
System Management, Stop, Start
Component
Stop
System Management, Stop, Start
Component
31 December 2010
223
Alliance Access 7.0 - AIX
Entity name
Occurrence
identification
Possible actions
Permission required
Logical
Terminal
All or LT field
values
Login
SWIFT Interface, Login, Select
select_FIN
SWIFT Interface, Login, Select
Logout
SWIFT Interface, Login, Select
Quit
SWIFT Interface, Login, Select
Change_mode
SWIFT Interface, Enable /
Disable Auto mode
Reset_Sent (1)
Monitoring: Reset LT Counter
Reset_Received (1)
Monitoring: Reset LT Counter
Activate
SWIFTNet Interface, Activate
EProf / Activate RProf
De_activate
SWIFTNet Interface, Deactivate
EProf / Deactivate RProf
Enable
SWIFTNet Interface, Enable
EProf / Enable RProf
Disable
SWIFTNet Interface, Disable
EProf / Disable RProf
Change_mode
SWIFTNet Interface, Enable
EProf auto / Disable EProf auto /
Enable RProf auto / Disable
RProf auto
Reset_Sent (for Emission
Monitoring, Reset EProf Counter
(Emission profile) or Reset RProf
Counter (Reception profile)
Emission /
Reception
SWIFTNet
profile
All or Name field
values
Profile only) (1)
Reset_Received (for
Reception Profile only) (1)
Message
Partner
Queue
224
All or Name field
values
All or Name field
values
Monitoring, Reset EProf Counter
(Emission profile) / Reset RProf
Counter (Reception profile)
Enable
Application Interface, Enable
Message Partner
Run_session
Application Interface, Run
Session
Abort_session
Application Interface, Abort
Session
Start_session
Application Interface, Start
Session
Stop_session
Application Interface, Stop
Session
Reset_Sent (1)
Monitoring, Reset MP Counter
Reset_Received (1)
Monitoring, Reset MP Counter
Hold
System Management, Hold
Queue
Release
System Management, Release
Queue
Installation and Administration Guide
Operational Integration
Entity name
Occurrence
identification
Possible actions
Permission required
Operator
All or Name field
values
Enable
Security Definition, Enable
Operator
Disable
Security Definition, Disable
Operator
(1) When these actions are executed, the value of the counter before the reset is provided in the output.
26.3.3 Action Parameters
Details
Some actions on some entities may require additional parameters.
Entity name
Action keywords
Action parameters
Logical Terminal
select_FIN
-subset [subset name 1]
-subset [subset name n]
-ltdirqueue y / n
-send_receive_mode s / r / sr
[-test_mode_selection full_function /
local_test] (if test and training LT in send
and receive)
Change_mode
-mode manual / automatic
Emission / Reception
SWIFTNet Profile
Change_mode
-mode manual / automatic
Message Partner
Start_session
(If the message partner uses the File Transfer
connection method)
-file_location server / userspace
-connection_point connection_point
-add_PDE y / n
-action route / dispose [queue_name]
Run_session
(If the message partner uses the File Transfer
connection method)
-file_location server / userspace
-connection_point connection_point
Operator
Disable
-next_signon_allowed enable, or a date and
time
-next_signon_allowed enable
-next_signon_allowed date <DD/MM/YYYY
HH:MM:SS>
31 December 2010
225
Alliance Access 7.0 - AIX
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_manageasp
Purpose
You can use the saa_manageasp command to install all the Application Service Profiles
(ASPs) of a provided ASP package.
Prerequisites
• The Alliance Access server must be running.
• The operator must have the "Manage ASP" permission (in the SWIFT Support application) in
their profile.
Results
Error or confirmation messages are logged in the log directory, underneath your installation
directory. The filename has the timestamp (YYYYMMDDTHHMMSS) of when the ASP
management operation was run.
27.2
saa_configconnection
Purpose
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
Prerequisites
• The script must be run from the Alliance Access Administrator account
• The script is used to configure the Alliance Access instance that it is packaged with.
saa_configconnection tool location
<Alliance Access installation directory>/bin/saa_configconnection
Syntax
saa_configconnection
226
Installation and Administration Guide
Using Command Line Tools
Procedure
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_configconnection command.
For command location and syntax, see "saa_configconnection" on page 271.
The configuration program starts.
4.
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>]
Note
27.3
If the Alliance Access servers are running when the command is run, then they
must be restarted before your changes become effective.
saa_system
Introduction
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.
31 December 2010
227
Alliance Access 7.0 - AIX
Prerequisites
• The Alliance Access bootstrap must be running. See "Starting and Stopping the Bootstrap
Service" on page 236.
• 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.3.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.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_system command.
For command location and syntax, see "saa_system" on page 284.
27.3.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.3.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.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_system archive command.
For command location and syntax, see "saa_system" on page 284.
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).
228
Installation and Administration Guide
Using Command Line Tools
27.3.2.2 Listing Archives
Purpose
The saa_system archive list command is used to list archives present in the database.
Procedure
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_system archive list command.
For command location and syntax, see "saa_system" on page 284.
27.3.2.3 Backing Up Archives
Purpose
The saa_system archive backup command is used to back up archives present in the
database. Alternatively, you can use the System Management application.
Procedure
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
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 284.
27.3.2.4 Removing Archives
Purpose
The saa_system archive remove command is used to remove archives from the database.
Procedure
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
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 284.
31 December 2010
229
Alliance Access 7.0 - AIX
27.3.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.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
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 284.
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 284.
27.3.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.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
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 284.
230
Installation and Administration Guide
Using Command Line Tools
27.3.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.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_system integrity command.
For command location and syntax, see "saa_system" on page 284.
27.3.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.
To list instances:
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_system instance list command.
For command location and syntax, see "saa_system" on page 284.
To rename the current instance:
1.
Log on as root to the machine where Alliance Access is installed.
2.
Ensure that the Alliance Access servers are stopped.
3.
From the System Administration application, select Xterm from the OS Configuration
menu.
4.
Enter the saa_system instance rename command.
For command location and syntax, see "saa_system" on page 284.
5.
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 241.
31 December 2010
231
Alliance Access 7.0 - AIX
27.3.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.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_system status command.
For command location and syntax, see "saa_system" on page 284.
You can specify database or server if you just want to check either of these. Without
arguments, results for both are displayed.
If the servers are running, then the mode of operation is displayed.
4.
To check the integrity of the database, enter the saa_system dbintegrity command.
For command syntax, see "saa_system" on page 284.
27.3.6 Starting and Stopping the Alliance Access Server
Purpose
You can use the saa_system command to start the server (in Housekeeping or Operational
mode), and also to stop the server.
You can restart the server by first issuing the saa_system stop command and then the
saa_system start command.
To start in Housekeeping mode
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_system start housekeeping command.
For command location and syntax, see "saa_system" on page 284.
To start in Operational mode
1.
Log on to the machine where Alliance Access is installed.
2.
Open an Xterm window.
3.
Enter the saa_system start operational command.
For command location and syntax, see "saa_system" on page 284.
232
Installation and Administration Guide
Using Command Line Tools
To stop the server
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_system stop command.
For command location and syntax, see "saa_system" on page 284.
27.3.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.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_system traceset command.
For command location and syntax, see "saa_system" on page 284.
You must enter the directory and file name of the configuration file provided by SWIFT.
To stop tracing
1.
Log on to the machine where Alliance Access is installed.
2.
From the System Administration application, select Xterm from the OS Configuration
menu.
3.
Enter the saa_system tracereset command.
For command location and syntax, see "saa_system" on page 284.
27.4
saa_configbootstrap
Purpose
The saa_configbootstrap command is used to configure the Alliance Access Name Service
and Bootstrap Service to start automatically at system boot time.
Prerequisite
The saa_configbootstrap tool must be run using the root account.
31 December 2010
233
Alliance Access 7.0 - AIX
27.4.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.
Enter the appropriate password.
3.
Enter the saa_configbootstrap -nameservice command.
For command location and syntax, see "saa_configbootstrap" on page 270.
Changes are made to the /etc/rc.shutdown file, and the file /etc/rc.d/rc2.d/S999saans is
created.
To revert back to manual startup:
• Remove the changes made to the /etc/rc.shutdown file
• Remove the file /etc/rc.d/rc2.d/S999saans
27.4.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.
Enter the appropriate password.
3.
Enter the saa_configbootstrap -bootstrap command.
For command location and syntax, see "saa_configbootstrap" on page 270.
Changes are made to the /etc/rc.shutdown file.
The following file is added:
234
Installation and Administration Guide
Using Command Line Tools
/etc/rc.d/rc2.d/S999saabootstrap_<instance_name>
Where <instance_name> is the name of the Alliance Access instance for which the
Alliance Access Bootstrap Service is configured.
To revert back to manual startup:
• Remove the changes made to the /etc/rc.shutdown file
• Remove the file /etc/rc.d/rc2.d/S999saabootstrap_<instance_name>
27.5
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/).
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:
31 December 2010
235
Alliance Access 7.0 - AIX
kill -HUP <pid of syslogd>
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.5.1 Starting and Stopping the Name Service
To start the Name Service:
1.
From the System Administration application, select Xterm from the OS Configuration
menu.
2.
Enter the saa_bootstrap -nameservice start command.
For more information about the command and its syntax, see "saa_bootstrap" on page 270.
To stop the Name Service:
1.
From the System Administration application, select Xterm from the OS Configuration
menu.
2.
Enter saa_bootstrap -nameservice stop command.
27.5.2 Starting and Stopping the Bootstrap Service
To start the Bootstrap Service:
1.
From the System Administration application, select Xterm from the OS Configuration
menu.
2.
Enter the saa_bootstrap start command.
For more information about the command and its syntax, see "saa_bootstrap" on page 270.
To stop the Bootstrap Service:
1.
From the System Administration application, select Xterm from the OS Configuration
menu.
2.
Enter the saa_bootstrap stop command.
For more information about the command and its syntax, see "saa_bootstrap" on page 270.
27.6
Alliance CIFA Export
Description
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
236
Installation and Administration Guide
Using Command Line Tools
Where the following is the output of the -h help option:
-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
27.7
:
<corr_X1>
TCP/IP Service Files
Description
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.
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.8
The Reset Message Partners (reset_mp) Script
Overview
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.
31 December 2010
237
Alliance Access 7.0 - AIX
The tool must only be used when the Alliance Access servers are not running.
To start the tool and reset a message partner:
1.
From the System Administration application, select Xterm from the OS Configuration
menu.
2.
Enter the reset_mp command.
For command location and syntax, see "reset_mp" on page 269.
3.
You are then required to enter a user name and password. You must be an Alliance user
that has the Bank Query permission.
4.
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.
238
Installation and Administration Guide
TCP Configuration for the Alliance Access Server
28
TCP Configuration for the Alliance Access
Server
28.1
Port Configuration
Description
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
swa_boot
<swa_boot_port>
server
<instance_name1>
<base_port1>
messenger
<instance_name1>
<base_port1>
server
<instance_nameN>
<base_portN>
messenger
<instance_nameN>
<base_portN>
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
swa_boot
48009
server
SAA_TEST
48100
server
SAA_LIVE
48200
messenger
SAA_LIVE
48300
messenger
SAA_TEST
48400
In this example, the following ports are used by Alliance Access instances:
alliance
swa_boot
48009
server
SAA_TEST
48100
48101
48102
48103
48104
48105
48106
31 December 2010
239
Alliance Access 7.0 - AIX
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
Introduction
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> =
I to update the ports for a specific instance
R to remove the ports for a specific instance
<instance_name>=
240
the instance
Installation and Administration Guide
TCP Configuration for the Alliance Access Server
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.
31 December 2010
241
Alliance Access 7.0 - AIX
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 91.
• 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
Overview
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.
To generate a configuration report:
242
1.
Log on to the Alliance Administrator account, using the current password. The main window
of the System Administration application will appear.
2.
Select the Report command from the File menu.
Installation and Administration Guide
General Troubleshooting
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.
31 December 2010
243
Alliance Access 7.0 - AIX
29.2
The JOURNAL_query Facility
Overview
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.
To monitor the Event Journal:
1.
Log on with the Alliance Administrator account, using the current password. The main
window of the System Administration application will appear.
2.
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.
244
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.
Installation and Administration Guide
General Troubleshooting
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.
7.
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.
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
31 December 2010
This command is not available when Output To is set to 'Screen' or 'Print'.
245
Alliance Access 7.0 - AIX
246
Installation and Administration Guide
Part D - Appendices
Part D
Appendices
31 December 2010
247
Alliance Access 7.0 - AIX
248
Installation and Administration Guide
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.
31 December 2010
249
Alliance Access 7.0 - AIX
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.
250
Installation and Administration Guide
Appendix A - Setup Recommendations
A.2
Alliance Access as Standalone Message Entry
and Repair System
A.2.1
Overview
Systems and licences required
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.
The following figure summarises the supported architecture of such a configuration.
31 December 2010
251
Alliance Access 7.0 - AIX
Figure 1 - Standalone message entry and repair configuration
Standalone
Alliance Access 1
Standalone
Alliance Access 2
TR_REC
TR_REC
MQ Host
Adapter
XMLv2
Back-Office
MQ Host
Adapter
XMLv2
Central Middleware Infrastructure
XMLv2
MQ Host
Adapter
Master Alliance Access
system(s)
D0540167
SWIFT
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
252
Installation and Administration Guide
Appendix A - Setup Recommendations
• 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
Overview
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.
31 December 2010
253
Alliance Access 7.0 - AIX
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.
254
Installation and Administration Guide
Appendix A - Setup Recommendations
A.2.3
Message Flows
Overview
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.
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 259.
The following diagram gives an overview of the steps involved in this scenario for the creation of
an MT or an XML-based message.
31 December 2010
255
Alliance Access 7.0 - AIX
Figure 1 - Message emission flow
Standalone
Alliance Access
Alliance
Workstation
1
1
_OI_to_OTHER
Alliance
Web Platform
Back-Office
Application
2
1
EP1 toMaster
3
_AI_waiting_ack
3
4
MQ Host Adapter
3
4
MQ queue
MQ queue
D0540168
XMLv2
Transmission
Report
XMLv2
Message
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.
256
Installation and Administration Guide
Appendix A - Setup Recommendations
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
See section
Create exit points
"Exit Points" on page 260
Create message partners
"Message Partners" on page 260
Define routing rules associated to the exit points
"Exit Points" on page 260
Update routing of _AI_from_APPLI
"_AI_from_APPLI" on page 262
Update routing of _OI_to_OTHER
"_OI_to_OTHER" on page 265
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
See section
Create message partners
"Message Partners" on page 260
Update routing of _AI_waiting_ack
"_AI_waiting_ack" on page 261
Update routing of _AI_from_APPLI
"_AI_from_APPLI" on page 262
31 December 2010
257
Alliance Access 7.0 - AIX
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
_MP_mod_text
_OI_to_OTHER
2
_AI_waiting_ack
EP1 toMaster
_AI_from_APPLI
1
MQ Host Adapter
1
MQ queue
D0540169
XMLv2
Transmission
Report
XMLv2
Message
MQ queue
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 255.
The required configuration tasks are the same as in "Message Entry Flow" on page 255.
258
Installation and Administration Guide
Appendix A - Setup Recommendations
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
2
_AI_from_APPLI
1
MQ Host Adapter
1
MQ queue
D0540170
XMLv2
Transmission
Report
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
See section
Create message partners
"Message Partners" on page 260
Update routing of _AI_from_APPLI
"_AI_from_APPLI" on page 262
31 December 2010
259
Alliance Access 7.0 - AIX
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
260
Installation and Administration Guide
Appendix A - Setup Recommendations
Define a routing rule like the following one for the EP1ToMaster routing point:
Sequence number
100
Description
Source to _AI_waiting_ack
Condition on
Function
Function Result
Success
Action on
Source
Action
Route to _AI_waiting_ack
Append Intervention
No Intervention
Unit
Keep Current
Routing code
NA
Priority
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
100
Description
positive transm. notification
Condition on
Message
Message
(Network_delivery_status = Network_Acked)
Action on
Source
Action
Complete
Append Intervention
No Intervention
Unit
Keep Current
Routing code
NA
Priority
Keep Current
• Negative transmission notifications
31 December 2010
Sequence number
200
Description
negative transm. notification
261
Alliance Access 7.0 - AIX
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
Source
Action
Route To _MP_mod_text
Append Intervention
No Intervention
Unit
Keep Current
Routing code
NA
Priority
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.
262
Sequence number
30
Description
input to _OI_to_OTHER
Condition on
Message
Installation and Administration Guide
Appendix A - Setup Recommendations
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.
Action on
Source
Action
Route to _OI_to_OTHER
Append Intervention
No Intervention
Unit
Keep Current
Routing code
NA
Priority
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
40
Description
repair to _MP_mod_text
Condition on
Message
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.
Action on
Source
Action
Route to _MP_mod_text
Append Intervention
No Intervention
Unit
Keep Current
Routing code
NA
Priority
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.
31 December 2010
Sequence number
50
Description
MT traffic reconciliation
Condition on
Message
Message
(Mesg_type='010') or (Mesg_type='011') or
(Mesg_type='012') or (Mesg_type='015') or
(Mesg_type='019')
263
Alliance Access 7.0 - AIX
Action on
Source and New Instance
Action on
Source
• Action
• Route to System
• Append Intervention
• No Intervention
• Unit
• Keep Current
• Routing code
• NA
• Priority
• Keep Current
Action on
New Instance
• Type
• Copy
• Action
• Route To _TR_REC
• Append Intervention
• No Intervention
• Unit
• Keep Current
• Routing code
• NA
• Priority
• Keep Current
• The delivery notifications of XML-based messages are routed to _TR_REC to allow
reconciliation with the original input messages.
264
Sequence number
60
Description
MX traffic reconciliation
Condition on
Message
Message
(Nature = NETWORK_MSG) and (Format = 'Internal')
Action on
Source and New Instance
Action on
Source
• Action
• Route to MXSystem
• Append Intervention
• No Intervention
• Unit
• Keep Current
• Routing code
• NA
• Priority
• Keep Current
Action on
New Instance
• Type
• Copy
• Action
• Route To _TR_REC
• Append Intervention
• No Intervention
• Unit
• Keep Current
• Routing code
• NA
• Priority
• Keep Current
Installation and Administration Guide
Appendix A - Setup Recommendations
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
100
Description
always to EP1ToMaster
Condition on
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)
Action
Route to EP1ToMaster
Append Intervention
No Intervention
Unit
Keep Current
Routing code
NA
Priority
Keep Current
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
Introduction
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
31 December 2010
265
Alliance Access 7.0 - AIX
• 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
266
Installation and Administration Guide
Appendix A - Setup Recommendations
Route all transmission notifications related to messages originating from the standalone
Alliance Access system
Sequence number
50
Description
transmission notifications
Condition on
Message: (Src_entity=Message Partner which treated the
input messages coming from the standalone Alliance Access
system)
Action on
Source and New Instance
Action on
Source
• Action
• Complete
• Append Intervention
• No Intervention
• Unit
• Keep Current
• Routing code
• NA
• Priority
• Keep Current
Action on
New Instance
• New instance type
• Notification Transmission
• Action
• Route To TRANStoAloneEP1
• Append Intervention
• No Intervention
• Routing code
• NA
• For _SI_to_SWIFTNet
Route all transmission notifications related to messages originated from the Alliance Access
system.
31 December 2010
Sequence number
50
Description
transmission notifications
Condition on
Message: (Src_entity=Message Partner which treated the
input messages coming from the standalone Alliance Access
system)
Action on
Source and New Instance
Action on
Source
• Action
• Complete
• Append Intervention
• No Intervention
• Unit
• Keep Current
• Routing code
• NA
• Priority
• Keep Current
Action on
New Instance
• New instance type
• Notification Transmission
• Action
• Route To TRANStoAloneEP1
267
Alliance Access 7.0 - AIX
• Append Intervention
• No Intervention
• Routing code
• NA
• For _SI_from_SWIFT
Route all delivery notifications to the standalone Alliance Access system.
Sequence number
50
Description
delivery notifications
Condition on
Message: (Mesg_type='011') or (Mesg_type= '012') or
(Mesg_type='010') or (Mesg_type='015') or
(Mesg_type='019')
Function Result = Success
Action
Route To DLVtoAloneEP1
Append Intervention
No Intervention
Unit
Keep Current
Routing code
NA
Priority
Keep Current
• For _SI_from_SWIFTNet
Route all delivery notifications to the standalone Alliance Access system.
268
Sequence number
50
Description
delivery notifications
Condition on
Message: (Nature = NETWORK_MSG) and (Format =
'Internal')
Function Result = Success
Action
Route To DLVtoAloneEP1
Append Intervention
No Intervention
Unit
Keep Current
Routing code
NA
Priority
Keep Current
Installation and Administration Guide
Appendix B - Command Line Tool Syntax Reference
Appendix B
Command Line Tool Syntax Reference
Running commands
Note that the tool 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 the command.
B.1
checkhost
Tool location
<Alliance installation directory>/AIX/checkhost
Command syntax
checkhost.ksh
[-req <pathname of requirements file]>]
[-rootdir <pathname of a directory>]
[-out <pathname of the report file>]
Parameters
Parameter
Description
-req
Used to specify the Alliance Access base requirements file, for a
comparative analysis report.
-rootdir
Used to specify the path to a drive or file system against which the
checkhost tool must perform a disk space validation.
-out
Used to specify the location for the report file. If no location is specified, the
report is produced in the following default location:
Mandatory?
/tmp/checkhost.log
Used to specify the location for the report file, and that the file is to be in
XML format. If no location is specified, the report is produced in the
following location:
-outxml
/tmp/checkhost.log
B.2
reset_mp
Tool location
<Alliance installation directory>/MXS/bin/AIX
Command syntax
reset_mp
<Message partner name>
31 December 2010
269
Alliance Access 7.0 - AIX
Parameters
Parameter
Description
<Message partner
name>
The name of the message partner to reset.
B.3
Mandatory?
Yes
saa_bankquery
Tool location
<Alliance installation directory>/bin
Command syntax
saa_bankquery
Parameters
Parameter
Description
Mandatory?
Support will provide details of any parameters that need to be entered.
B.4
saa_bootstrap
Tool location
<Alliance installation directory>/bin
Command syntax
saa_bootstrap
[-timeout <value>]
[-nameservice]
start|stop
Parameters
Parameter
Description
Mandatory?
Starts the Alliance Access servers.
-saastart
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.
stop
Stops the Alliance Access servers.
-timeout <value>
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).
-nameservice
The Alliance Access name service to be started or stopped.
B.5
saa_configbootstrap
Tool location
<Alliance installation directory>/bin
270
Installation and Administration Guide
Appendix B - Command Line Tool Syntax Reference
Command syntax
saa_configbootstrap
-nameservice
-bootstrap
Parameters
Parameter
Description
-nameservice
Starts the Alliance Access Name Service at start time.
-bootstrap
Starts the Alliance Access bootstrap service at start time.
B.6
Mandatory?
saa_configconnection
Tool location
<Alliance installation directory>/bin
Command syntax
saa_configconnection
Parameters
Parameter
Description
Mandatory?
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>]
B.7
saa_dbconfig
Tool location
<Alliance installation directory>/bin
Command syntax
saa_dbconfig
<entity>
<command>
Parameters
Entity
memory
tablespace
Command
Description
-display
Displays the amount of memory allocated for the database
memory regions.
Default value: 1500 MB.
-resize -all <Size>
Changes the amount of memory allocated for the database
memory regions.
-display [-tablespace
<Name>]
Displays the current location, allocated size and usage (in
megabytes) of all tablespaces or for a specified tablespace
<Name>.
31 December 2010
Mandator
y?
271
Alliance Access 7.0 - AIX
Entity
Command
Description
Mandator
y?
-move -tablespace
<Name> -location
<DestinationDir> [size <Size>]
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).
-resize -tablespace
<Name> [-size <Size>
| -optimal]
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.
-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.
This command only applies to user tablespaces (and not
system tablespaces).
redolog
B.8
-display
Displays the current location and size of the redo log files.
-move -location
<DestinationDir> size
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.
saa_dbinfo
Tool location
<Alliance installation directory>/bin
Command syntax
saa_dbinfo
<repdir>
[-startdate <date> -starttime <time> -stopdate <date> -stoptime <time>]
Parameters
Parameter
Description
Mandatory?
<repdir>
Specifies the directory where the collected information is to be stored (in a
ZIP file).
Yes
-startdate <date>
The start date, in the format YYYYMMDD.
-starttime <time>
The start time, in the format HH:MM:SS.
-stopdate <date>
The stop date, in the format YYYYMMDD.
-stoptime <time>
The stop time, in the format HH:MM:SS.
272
Installation and Administration Guide
Appendix B - Command Line Tool Syntax Reference
B.9
saa_dbrecovery
Tool location
<Alliance installation directory>/bin
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]
Parameters
Parameter
-m
Description
Mandatory?
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.
-a
Activates the Database Recovery Mode.
You must specify the full path names of the mirror and backup disks.
-p
<pathname_recovery_mi
rror_disk>
Specifies the full path name of the mirror disk.
-q
<pathname_recovery_ba
ckup_disk>
Specifies the full path name of the backup disk.
-d
Deactivates the Database Recovery Mode.
-f <y|n>
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.
-i <y|n>
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.
-c f|i
Launches a backup of the database :
• f: full database backup
• i: incremental database backup
31 December 2010
273
Alliance Access 7.0 - AIX
Parameter
Description
Mandatory?
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.
-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.
-r
Recovers the database.
You must specify the full path names of the mirror and backup disks.
-z <n|s|a>
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
-v
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.
-s <n|c|i>
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.
Displays help about the command and its parameters.
-h
B.10
saa_dbrestore
Tool location
<Alliance installation directory>/bin
Command syntax
saa_dbrestore
-r -p <path name of database backup file> -s [a|o|s|r|c|d|w|m] -e [y|n] -n
[y|n] -o [y|n] -w [y|n] -z [n|s|a] -i [y|n]
-c -p <path name of database backup file> -s [o|s|r|c|d|w|m] -i [y|n]
274
Installation and Administration Guide
Appendix B - Command Line Tool Syntax Reference
Parameters
Parameters and
Options
Description
-r
Restore database.
-c
Consistency check.
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.
-p <path name of
database backup file>
Specifies the path name where the database backup is located.
In case of hosted database, <path name of database backup file> is
the database directory itself (for example,
20101025T104837_SAA_DATA_BACKUP).
-s [a|o|s|r|c|d|w|m]
The entities to be checked or restored:
Mandatory?
• a = all entities
• o = Operators only
• s = SWIFT interface only
• r = Routing information only
• c = Correspondents only
• d = ADK storage only
• w = SWIFTNet Interface only
• m = RMA authorisations only
-e [y|n]
Specifies whether messages and events to be cleaned or not. Default
value: n.
-n [y|n]
Restore database even when no licence found on target system. Default
value: y.
-o [y|n]
Restore Operators even when the set of operators is not identical. Default
value: y.
-w [y|n]
Restore SWIFTNet related information. Default value: y.
-z [n|s|a]
Disable Connectivity and Alliance Developers Toolkit components:
• n = no (default value)
• s = SWIFT Connectivity only
• a = all
Run the script in interactive mode. Default value: y.
-i [y|n]
B.11
saa_export
Tool location
<Alliance installation directory>/bin
31 December 2010
275
Alliance Access 7.0 - AIX
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
Description
Mandatory?
-parameterfile
<export_parameter_fil
e>
The name of the export parameter file that contains the list of entities (along
with filtering criteria, if specified) that must be exported.
Yes
-exportfile
<export_file>
The name of the export file that will contain the exported data, as a result of
a successful export process.
Yes
-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.
-application
<username>
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.
-password <password>
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.
-passwordfile
<password_file>
The name of a file that contains the password of the Alliance Access
operator.
-exportsensitivedata
Indicates that sensitive data will be exported and stored in the export file.
-overwrite
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.
276
Installation and Administration Guide
Appendix B - Command Line Tool Syntax Reference
Parameter
Description
-port <port_number>
The port number of the localhost in which the Alliance Access is listening.
Default port number: 48200.
-reportfile
<file_pathname>
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.
-summaryonly
If specified, the produced export log contains less information about the
entity occurrences exported.
B.12
Mandatory?
saa_import
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.
Command syntax
saa_import
-exportfile <export_file>
[-user|-application <username>]
[-password <password>] | [-passwordfile <password_file>]
[-overwrite]
[-port <port_number>]
[-reportfile <file_pathname>]
[-summaryonly]
Parameters
Parameter
Description
-exportfile
<export_file>
The name of the export file containing the configuration data to export.
-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.
-application
<username>
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.
-password <password>
The password of the Alliance Access operator.
Mandatory?
Yes
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.
31 December 2010
277
Alliance Access 7.0 - AIX
Parameter
Description
Mandatory?
• -user|-application <username>: You are prompted to enter the
password when you launch the tool. This is the most secured option.
-passwordfile
<password_file>
The name of the password file that contains the password.
-overwrite
The import mode. Specify this parameter to update the existing entities. If
you do not specify the parameter, then the update is skipped.
-port <port_number>
The port number of the localhost in which the Alliance Access is listening.
Default port number: 48200.
-reportfile
<file_pathname>
The name of the report file in which details of the export execution are
logged. If a file with that name already exists, then Alliance Access
overwrites it.
-summaryonly
If specified, the produced import log contains less information about the
entity occurrences imported.
B.13
saa_manage
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.
Exit codes
The saa_manage tool returns the following main exit codes:
• 0: the command has been performed successfully
• 255: the command failed
• 1: the command has been performed successfully for some entity occurrences, but not for all
In some cases, other exit codes may be returned. If the exit code is different from 0, then check
the output file generated by saa_manage for further details.
Command syntax
saa_manage
-manageparameterfile <manage_parameter_file>
-manageoutputfile <manage_output_file>
-action <action> <action parameter 1, action parameter 2, ...>
[-user|-application <username>]
[-password <password>] | [-passwordfile <password_file>]
[-port <port_number>]
[-overwrite]
278
Installation and Administration Guide
Appendix B - Command Line Tool Syntax Reference
Parameters
Parameter
Description
Mandatory?
-manageparameterfile
<manage_parameter_fil
e>
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.
Yes
-manageoutputfile
<manage_output_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).
Yes
-action <action>
<action parameter 1,
action parameter
2, ...>
The action that must be performed on the specified occurrences and its
related parameters, if any. These parameters can be either values or
keywords preceded by a - and followed by a value.
Parameter keywords (such as -ltdirqueue are case sensitive.
Yes
For more information, see "Action Parameters" on page 225.
-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.
-application
<username>
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.
-password <password>
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.
-passwordfile
<password_file>
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.
-port <port_number>
The port number of the localhost in which the Alliance Access is listening.
Default port number: 48200.
-overwrite
When this option is specified, if the file specified by the manageoutputfile parameter exists, then it is overwritten.
B.14
saa_manageasp
Tool location
<Alliance installation directory>/bin
31 December 2010
279
Alliance Access 7.0 - AIX
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.
Syntax
saa_manageasp
[-user|-application <username>]
[-password <password>]
[-passwordfile <passwordfile>]
[-l <Full ASP Package Filename>]
[-h]
Parameters
Parameter
B.15
Description
-user|-application <username>
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 <password>
Password of the Alliance Access operator.
Optional.
If present, -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, -user must be present too. Must be omitted if password is present.
-l <Full ASP Package Filename>
Installs all the ASP files included in the ASP package to install
(full file name is required).
-h
Provides a list of the different options and their meaning.
saa_monitor
Tool location
<Alliance installation directory>/bin
Exit codes
The saa_monitor tool returns the following main exit codes:
• 0: the command has been performed successfully
• 255: the command failed
In some cases, other exit codes may be returned. If the exit code is different from 0, then check
the output file generated by saa_monitor for further details.
280
Installation and Administration Guide
Appendix B - Command Line Tool Syntax Reference
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
Description
Mandatory
?
-monitorparameterfile
<monitor_parameter_file>
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.
Yes
-monitoroutputfile
<monitor_output_file>
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.
Yes
-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.
-application <username>
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.
-password <password>
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.
-passwordfile
<password_file>
31 December 2010
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.
281
Alliance Access 7.0 - AIX
Parameter
Description
Mandatory
?
-cycle <nnnn_sec>
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.
-duration <nnnn_h>
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.
-continue_on_error
The process continues in case an error occurs on any particular 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.
-port <port_number>
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.
When this option is specified, and if the file specified by the monitoroutputfile parameter exists, then the output file is
overwritten.
-overwrite
B.16
saa_msgrepair
Tool location
<Alliance installation directory>/bin
Command syntax
saa_msgrepair [option]
Parameters
Parameter
-m
Description
Mandatory?
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
-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.
-h
282
Provides a list and description of the different options.
Installation and Administration Guide
Appendix B - Command Line Tool Syntax Reference
B.17
saa_rtfilegetrequest
Purpose
Use the saa_rtfilegetrequest command to request the download of 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.
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.
Tool location
<Alliance installation directory>/BSS/bin/AIX
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>]
Parameters
The saa_rtfilegetrequest command has mandatory and optional parameters, as follows:
Parameter
Description
Mandatory?
-user|-application
<username>
The name of the Alliance Access operator of type Human (-user) or
Application (-application) executing the command.
Yes
-service
<service_name>
The name of the real-time FileAct service over which the payload file must
be transferred.
Yes
-request
<request_type>
The name of the request type to use within the service, to transfer the file.
Yes
-requestor
<distinguished_name>
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.
Yes
-responder
<distinguished_name>
The DN of the correspondent institution, that is being requested to transfer
the file.
Yes
-rprof <realtime_reception_profil
e>
The name of the real-time SWIFTNet Reception Profile that will manage the
file request and the reception of the file from the correspondent.
Yes
31 December 2010
283
Alliance Access 7.0 - AIX
Parameter
Description
Mandatory?
-logicalname
<logical_file_name>
The logical name of the file that is requested from the correspondent. This
name must be known to the correspondent.
Yes
-password <password>
The password of the Alliance Access operator specified in the -user or application parameter.
(1)
-passwordfile
<password_file>]
The name of the file that contains the password of the Alliance Access
operator specified in the -user or -application parameter.
(1)
-authoriser
<distinguished_name>
The Authoriser DN that Alliance Access must use when downloading the
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.
-nonrepudiation
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.
-signature none|
crypto|list
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
-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.
-port <port_number>
The port number to use to access Alliance Access.
If you do not specify -port, then the default port, 48200, is used.
(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.18
saa_system
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.
284
Installation and Administration Guide
Appendix B - Command Line Tool Syntax Reference
• <options> represents an optional part of the command.
Parameters
Parameter
Description
archive [jrnl|mesg] days <NumberOfDays>
Archives the specified entity: jrnl for events, mesg for complete messages.
archive list [jrnl|
mesg]
Lists the archives present in the database for the specified entity: jrnl for
events, mesg for complete messages.
archive listtar
[jrnl|mesg]
<file_pathname>
Only for use with backups created with an earlier version of Alliance
Access.
Lists the archives present in a backup of the specified entity, in the tar file
specified in <file_pathname>.
archive remove [jrnl|
mesg] <archive_name>
Removes the specified archive <archive_name> from the database: jrnl
for events, mesg for complete messages.
archive backup [jrnl|
mesg] <archive_name>
<file_pathname>
Performs a backup of the specified archive and stores the created backup
under the directory <file_pathname>.
archive restore
[jrnl|mesg]
<file_pathname>
Restores the specified archive backup <file_pathname>.
Mandatory?
Use -days to specify the number of days (1 to 999) for which to retain the
archives.
In case of hosted database, do not specify the <file_pathname>
parameter as the backup is created in the eja (for events) or mfa (for
messages) subdirectory of the shared directory specified by the Location
Backups parameter.
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.
archive restoretar
[jrnl|mesg]
<ArchiveName>
<file_pathname>
Only for use with backups created with an earlier version of Alliance
Access.
Restores the specified archive from the backup tar file specified in
<file_pathname>.
dbbackup
<file_pathname>
Performs a complete backup of the database, and stores it as a directory
under the directory <file_pathname>.
In case of hosted database, do not specify the <file_pathname>
parameter as the backup is created in the db subdirectory of the shared
directory specified by the Location Backups parameter.
dbintegrity [all|
static]
Verifies the integrity (absence of unauthorised updates) of the Alliance
Access database.
all verifies the complete database, including daily tables.
static only verifies non-daily tables.
integrity
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.
instance list
Lists the instances that are available on the host.
instance rename
Renames the current instance.
readlog
<file_pathname> [startdate <StartDate>
[-starttime
<StartTime>]] [-
Reads the events that belong to the specified period from the Event Journal
and places them in a text file named in file_pathname.
31 December 2010
285
Alliance Access 7.0 - AIX
Parameter
Description
Mandatory?
stopdate <StopDate>
[-stoptime
<StopTime>]]
start housekeeping
Starts Alliance Access in housekeeping mode.
You cannot start the servers while the database is being restored.
start operational
Starts Alliance Access in operational mode.
You cannot start the servers if the database is being restored.
status [database|
server]
Gives the status of the Alliance Access instance servers and database:
• Running
For the servers, the command also returns the mode: operational or
housekeeping.
• Not running or stopped
stop [force]
Stops the Alliance Access servers.
Use force to stop the Alliance Access servers in a forced way. The
processes are killed at the operating system level instead of being stopped.
traceset
<file_pathname>
Starts a trace using a configuration file <file_pathname> provided by
SWIFT.
tracereset
Stops the trace.
B.19
swrpc_keytool
Tool location
<Alliance installation directory>/BSS/bin/AIX
Command syntax
swrpc_keytool
Prompts
The following table describes the prompts you will receive. The default response is presented in
square brackets in the form [default]:
286
Step
Prompt
Response
a
Do you want: 1: a self-signed
certificate 2: a certificate request
[default, 1]:
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
authentication in this case, you must receive
both the certificate and the CA certificate.
Installation and Administration Guide
Appendix B - Command Line Tool Syntax Reference
Step
Prompt
Response
b
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, the file
is created in the current directory.
c
Enter a password of your choice:
The key is password-protected. Select a
password that complies with your institution's
password policy.
d
Re-enter the password for
verification:
Re-enter the password for verification: The new
key is now generated. Skip to prompt g.
e
File name for the certificate:
Enter the file name for your certificate. If the file
already exists, you are prompted to overwrite
the file. If the file does not exist, skip to prompt j.
f
Overwrite existing file? [default,
n]:
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.
g
File name for the certificate
request:
Enter the file name for your certificate request. If
the file already exists you are prompted to
overwrite it. If not, skip to prompt l.
h
Overwrite existing file? [default,
n]:
Enter Yes (y) to overwrite an existing file, enter
No (n) to return to prompt j.
i
Enter the distinguished name (DN) to
be included in the certificate:
This DN can contain the following attributes:
Example:
cn=SAA1,ou=department1,o=institution1
.
This DN will be needed if you want to
configure authentication.
• 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.
j
31 December 2010
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.
287
Alliance Access 7.0 - AIX
Legal Notices
Copyright
SWIFT © 2010. 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, 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.
288
Installation and Administration Guide