7 0 Saa Inst Admin Guide Sol

310
Alliance Access 7.0 Installation and Administration Guide This installation guide explains how to install and administer Alliance Access on Oracle Solaris and how to prepare the system prior to installation. This document is for system administrators and anyone that installs Alliance Access. Knowledge of Oracle Solaris is a prerequisite for readers of this document. 30 September 2011 Solaris Connectivity

Transcript of 7 0 Saa Inst Admin Guide Sol

Alliance Access 7.0

Installation and Administration GuideThis installation guide explains how to install and administer Alliance Access on Oracle Solaris and how to prepare thesystem prior to installation. This document is for system administrators and anyone that installs Alliance Access.Knowledge of Oracle Solaris is a prerequisite for readers of this document.

30 September 2011

Sol

aris

Connectivity

Table of Contents

.Preface .............................................................................................................................................................................7

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

1 Installation Features Overview ............................................................................................................... 11

2 Preparation ...................................................................................................................................................... 13

2.1 Getting Started ......................................................................................................................................... 13

2.2 Prepare the System ................................................................................................................................ 15

2.3 Tracking What Happens During Installation ....................................................................................... 19

2.4 Create the Temporary Installation Directory ....................................................................................... 19

2.5 Prepare for Non-root Installation, Upgrade, Backup, or Removal ................................................... 20

2.6 Create the sagsnlg and alliance Group ............................................................................................... 21

2.7 Prepare the Licence File ........................................................................................................................ 21

2.8 Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal) ............. 22

2.9 Protect the Passwords in the Response File ...................................................................................... 23

2.10 Prepare for a Hosted Database Installation ........................................................................................ 24

2.11 Prepare a Backup File for Upgrade ...................................................................................................... 29

3 Installation ........................................................................................................................................................ 32

3.1 Before You Install .................................................................................................................................... 32

3.2 Interactive Installation ............................................................................................................................. 33

3.3 Silent Installation ..................................................................................................................................... 43

3.4 Next Steps ................................................................................................................................................ 47

4 Upgrade ............................................................................................................................................................. 59

4.1 Before You Upgrade ............................................................................................................................... 59

4.2 Interactive Upgrade ................................................................................................................................. 62

4.3 Silent Upgrade ......................................................................................................................................... 70

4.4 Next Steps ................................................................................................................................................ 74

5 Relicensing ...................................................................................................................................................... 77

5.1 Before You Relicense ............................................................................................................................. 77

5.2 Interactive Relicensing ........................................................................................................................... 78

5.3 Silent Relicensing .................................................................................................................................... 81

5.4 Next Steps ................................................................................................................................................ 81

6 Removal ............................................................................................................................................................ 83

6.1 Before You Remove ............................................................................................................................... 83

6.2 Interactive Removal ................................................................................................................................ 83

6.3 Silent Removal ......................................................................................................................................... 84

7 Patches .............................................................................................................................................................. 85

7.1 Installation ................................................................................................................................................ 85

7.2 Removal .................................................................................................................................................... 86

Alliance Access 7.0 - Solaris

2 Installation and Administration Guide

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

8.1 Non-root Installation or Upgrade ........................................................................................................... 87

8.2 Silent Mode .............................................................................................................................................. 87

8.3 Licence Files for Alliance Access ......................................................................................................... 93

8.4 Checking Your System Configuration .................................................................................................. 93

8.5 The Software Integrity Report ............................................................................................................... 96

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

9 Introduction ..................................................................................................................................................... 99

10 Check Connectivity .................................................................................................................................... 100

10.1 Configure SWIFT DNS Servers .......................................................................................................... 100

10.2 Confirm Connectivity ............................................................................................................................. 100

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

11.1 Guidelines for Names ........................................................................................................................... 101

11.2 FIN Messaging ....................................................................................................................................... 101

11.3 InterAct and FileAct Messaging .......................................................................................................... 103

11.4 Data Encryption/Gateway Authentication between Alliance Access and AllianceGateway .................................................................................................................................................. 105

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

12.1 Defining a SWIFTNet Connection ...................................................................................................... 106

12.2 Assigning a SWIFTNet Connection to a Logical Terminal ............................................................. 107

12.3 Sending and Receiving a Test MT Message .................................................................................... 107

12.4 Access to the SWIFTNet FIN Test Service (Vendors only) ............................................................ 108

13 Configuring Alliance Access for InterAct and FileAct Messaging ....................................... 109

13.1 Defining a SWIFTNet Connection ...................................................................................................... 109

13.2 Installing Application Service Profiles ................................................................................................ 109

13.3 Configuring SWIFTNet Emission and Reception Profiles ............................................................... 110

13.4 Sending and Receiving an InterAct or a FileAct Message ............................................................. 110

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

14 Introduction to System Administration ............................................................................................. 115

14.1 Overview of the System Administration Application ........................................................................ 115

14.2 System Management Procedures ...................................................................................................... 119

14.3 The Alliance Release Tree .................................................................................................................. 120

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

15.1 System Management Commands ...................................................................................................... 123

15.2 Essential System Maintenance ........................................................................................................... 125

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

16.1 Alliance Administrator Account ........................................................................................................... 128

16.2 Security Considerations ....................................................................................................................... 128

16.3 The alliance_init File ............................................................................................................................. 129

Table of Contents

30 September 2011 3

16.4 Workstation IP Address Checking ...................................................................................................... 129

16.5 The Instance Registration File ............................................................................................................ 129

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

17.1 Starting the Alliance Access Servers ................................................................................................. 131

17.2 Stopping the Alliance Access Servers ............................................................................................... 134

17.3 Running Selected Program Scripts following Server Start and Stop ............................................ 138

17.4 Monitoring Processes ........................................................................................................................... 138

18 Query the Database for Message, Events, and Operator Details .......................................... 141

18.1 Query the Database to Extract Messages ........................................................................................ 141

18.2 Query the Database to Extract Events .............................................................................................. 142

18.3 Query the Database to Operator Details ........................................................................................... 142

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

19.1 Database Backup .................................................................................................................................. 144

19.2 Archive Backup ...................................................................................................................................... 145

19.3 Temporary Storage Directory for Backup .......................................................................................... 145

19.4 Performing a Manual Backup of Archives ......................................................................................... 146

19.5 Performing a Manual Backup of the Database ................................................................................. 148

19.6 Scheduling Automatic Backups .......................................................................................................... 150

19.7 Following a Backup ............................................................................................................................... 150

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

20.1 Restoring an Archive Backup .............................................................................................................. 151

20.2 Restoring the Alliance Access Database .......................................................................................... 153

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

21.1 Monitoring Available Disk Space ........................................................................................................ 158

21.2 Modifying Disk Space Parameters ..................................................................................................... 158

21.3 System Resources ................................................................................................................................ 159

21.4 How To Recover Disk Space .............................................................................................................. 159

21.5 Backing Up the Instance Registration File ........................................................................................ 159

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

22.1 Getting Information about the Alliance Access Database .............................................................. 160

22.2 Checking the Alliance Access Database ........................................................................................... 160

22.3 Configuring the Embedded Database ................................................................................................ 161

22.4 Backing Up the Alliance Access Database ....................................................................................... 162

22.5 Moving the Database to a New Host ................................................................................................. 163

22.6 The saa_bankquery Tool ..................................................................................................................... 163

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

23.1 About Database Recovery ................................................................................................................... 165

23.2 Database Configuration for Enhanced Resiliency ........................................................................... 167

23.3 Database Recovery Process ............................................................................................................... 169

23.4 Database Recovery Backups .............................................................................................................. 171

23.5 Repairing Messages ............................................................................................................................. 173

Alliance Access 7.0 - Solaris

4 Installation and Administration Guide

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

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

24.1 Process Failure ...................................................................................................................................... 181

24.2 Power Failure ......................................................................................................................................... 182

24.3 Disk Failure ............................................................................................................................................ 182

24.4 Recovery on a Different Host Using a Cold Backup ........................................................................ 183

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

25.1 Configuration Replication ..................................................................................................................... 189

25.2 Handling the Export and Import of Sensitive Data ........................................................................... 191

25.3 Entities Eligible for Export and Import ................................................................................................ 192

25.4 Status of Entities Before and After Import ......................................................................................... 196

25.5 Parameter File for Configuration Replication .................................................................................... 198

25.6 Fields Eligible for Export and Filtering ............................................................................................... 202

25.7 Export Configuration Data ................................................................................................................... 212

25.8 Import Configuration Data .................................................................................................................... 213

25.9 Report File for Configuration Replication .......................................................................................... 215

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

26.1 Overview of Operational Integration ................................................................................................... 217

26.2 Permissions for Launching Operational Integration Tools .............................................................. 217

26.3 Operational Monitoring ......................................................................................................................... 218

26.4 Operational Management .................................................................................................................... 226

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

27.1 saa_configconnection ........................................................................................................................... 230

27.2 saa_system ............................................................................................................................................ 231

27.3 saa_configbootstrap ............................................................................................................................. 237

27.4 saa_bootstrap ........................................................................................................................................ 239

27.5 Alliance CIFA Export ............................................................................................................................. 240

27.6 TCP/IP Service Files ............................................................................................................................. 241

27.7 The Reset Message Partners (reset_mp) Script .............................................................................. 241

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

28.1 Port Configuration ................................................................................................................................. 243

28.2 apply_alliance_ports Tool .................................................................................................................... 244

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

29.1 The Alliance Configuration Report ..................................................................................................... 246

29.2 The JOURNAL_query Facility ............................................................................................................. 248

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

.Appendix A Setup Recommendations ...........................................................................................................253

A.1 Alliance Access for Service Bureaux ................................................................................................. 253

A.2 Alliance Access as Standalone Message Entry and Repair System ............................................ 255

.Appendix B Command Line Tool Syntax Reference ...............................................................................273

Table of Contents

30 September 2011 5

B.1 checkhost ............................................................................................................................................... 273

B.2 getmesg .................................................................................................................................................. 274

B.3 launch MPA EXPORT_TEMPLATES ................................................................................................ 275

B.4 launch MPA unres_mesg ..................................................................................................................... 277

B.5 messageTool ......................................................................................................................................... 278

B.6 reset_mp ................................................................................................................................................. 278

B.7 saa_bankquery ...................................................................................................................................... 279

B.8 saa_bootstrap ........................................................................................................................................ 279

B.9 saa_configbootstrap ............................................................................................................................. 280

B.10 saa_configconnection ........................................................................................................................... 280

B.11 saa_dbconfig .......................................................................................................................................... 281

B.12 saa_dbinfo .............................................................................................................................................. 282

B.13 saa_dbpwdutil ........................................................................................................................................ 282

B.14 saa_dbrecovery ..................................................................................................................................... 283

B.15 saa_dbrestore ........................................................................................................................................ 285

B.16 saa_export .............................................................................................................................................. 287

B.17 saa_import .............................................................................................................................................. 288

B.18 saa_import_rmqa .................................................................................................................................. 289

B.19 saa_manage .......................................................................................................................................... 290

B.20 saa_manageasp .................................................................................................................................... 292

B.21 saa_monitor ........................................................................................................................................... 293

B.22 saa_msgrepair ....................................................................................................................................... 295

B.23 saa_query ............................................................................................................................................... 295

B.24 saa_rtfilegetrequest .............................................................................................................................. 299

B.25 saa_supportinfo ..................................................................................................................................... 301

B.26 saa_system ............................................................................................................................................ 303

B.27 sa_split .................................................................................................................................................... 306

B.28 swrpc_keytool ........................................................................................................................................ 307

B.29 systeminfo .............................................................................................................................................. 308

.Legal Notices .............................................................................................................................................................310

Alliance Access 7.0 - Solaris

6 Installation and Administration Guide

PrefacePurpose

This document describes how to install, configure, and administer Alliance Access on Solaris.The document includes an introduction to dual-configuration support and system administration.

In general, the information provided in this guide is designed for users connecting to SWIFT andthe FIN application. Where appropriate, information is also provided for users connecting toother networks.

Audience

This document is for anyone who installs Alliance Access. Knowledge of how to use Solaris is aprerequisite for the readers of this document.

Preface

30 September 2011 7

Alliance Access 7.0 - Solaris

8 Installation and Administration Guide

Part A

Installation

Part A - Installation

30 September 2011 9

Alliance Access 7.0 - Solaris

10 Installation and Administration Guide

1 Installation Features OverviewIntroduction

This section describes the new installation-related features that are available for AllianceAccess.

Hosted database or embedded database

In an embedded database environment, the product software uses the database supplied withthe product. In a hosted database environment, you install Alliance Access within an existingdatabase.

For information about the configuration of hosted database environments, see "Prepare for aHosted Database Installation" on page 24.

Silent mode

You can perform the installation, upgrade, patch, relicensing, and removal operations in silentmode. The main difference between interactive (GUI-based) operations and operationsperformed in silent mode is the way input data is provided. In a GUI-based procedure a userprovides input through GUI-windows. An operation launched in silent mode does not requireinteractive 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 theoperation, especially if you have a large number of Alliance Access instances. Furthermore, theuse of a response file allows for segregation of duties: operations managers can prepare theresponse files in advance, and the operation itself can be scripted or carried out by other peopleof the organisation. SWIFT provides templates of response files with default values, oralternatively, you can run an interactive installation to generate a response file and a licence file.For more information about using the silent mode, see "Silent Mode" on page 87.

Options for software licensing

Licence data can be provided either directly on screen, or from a file.

When Where How

during an interactive softwareinstallation, relicensing, orupgrade

in the licensing windows • Enter licence data on screen.

• Provide licence data from alicence file.

during silent installation,relicensing, or upgrade

from a command line Provide licence data in a licencefile.

For more information about the licensing options, see "Relicensing" on page 77.

Secure Channel

Secure Channel improves the way Alliance software licence data is distributed. Previously, theAlliance Left Security Officer (LSO) and Right Security Officer (RSO) received the licence datafor the Alliance products on paper. With Secure Channel, licence data is no longer distributedon 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 appropriateaccess rights defined in your user profile.

For more information, see Secure Channel on www.swift.com.

Installation Features Overview

30 September 2011 11

Recording the installation

The interactive installation features the option to record the input information provided duringthe installation into a response file. A command-line based silent installation procedure can usethis response file to provide the same installation information in subsequent installations. Thisreduces the risk of human error from manual intervention. For more information about recordingthe installation, see "Response Files" on page 88.

Recording the licence information

The interactive installation features the option to record the licence information (except licencekeys 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 relicensingtasks.

For more information about recording the licence information, see "Response Files" onpage 88.

Performing actions as a non-root user

It is possible to install, patch, remove, or upgrade the Alliance Access software with a non-rootuser 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 usermust prepare the system for the action that the non-root user will perform.

To complete the installation, the root user must perform some post-installation tasks.

For more information, see "Non-root Installation or Upgrade" on page 87.

Alliance Access 7.0 - Solaris

12 Installation and Administration Guide

2 Preparation

2.1 Getting StartedRelease Letter

A Release Letter for Alliance Access 7.0, provides essential information about the AllianceAccess software that you are about to install or upgrade. For example, it provides additionalchecks, instructions, or tips that you need to know before you install, upgrade, or relicense thesoftware.

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, aDVD, or a file downloaded from www.swift.com.

The release media provides an installation program (called an installer) which allows you toinstall or upgrade Alliance Access easily. You can launch the installation program directly from aDVD or from a hard disk.

You can install or upgrade Alliance Access from the following locations:

• DVD:

– local

– remote DVD drive, that is, a drive on a remote Solaris machine

• Directory on hard disk:

– local disk

– remote disk, that is, a disk on a remote Solaris machine

To get started

1. 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 "Preparationchecklist" on page 14.

3. After you perform the generic preparation tasks, review the prerequisites and checklists inthe sections, "Installation" on page 32 and "Upgrade " on page 59, and complete anyadditional preparation tasks described there.

4. Perform the task required:

• "Installation" on page 32

• "Upgrade " on page 59

• "Relicensing" on page 77

• "Removal" on page 83

• "Patches" on page 85

Preparation

30 September 2011 13

5. Review the Post-Installation or Post-Upgrade sections in the Release Letter, asappropriate, and complete any additional tasks that are specified there.

6. Complete the Next Steps in the relevant sections, which describe the configuration tasksthat are required to make your system operational.

Review also the Additional Configuration section in the Release Letter, and complete anyadditional tasks that are specified there.

Preparation checklist

The columns in the table are not mutually exclusive. Therefore, you must perform thepreparation tasks that are indicated in the relevant columns:

Preparation Task Inst

all w

ith

em

bed

ded

dat

abas

e

Inst

all w

ith

ho

sted

dat

abas

e

Up

gra

de

- st

and

ard

Up

gra

de

fro

m p

rep

ared

bac

kup

Rel

icen

se

Rem

ove

Pat

ch

Use

sile

nt

mo

de

Lau

nch

op

erat

ion

as

no

n-r

oo

t

Read the release Letter ✓ ✓ ✓ ✓ ✓ ✓ ✓

"Prepare the System" onpage 15

✓ ✓ ✓ ✓

"Create the TemporaryInstallation Directory" onpage 19

✓ ✓ ✓ ✓

"Prepare for Non-rootInstallation, Upgrade,Backup, or Removal" onpage 20

"Create the sagsnlg andalliance Group" onpage 21

"Prepare the Licence File"on page 21

"Prepare the ResponseFile (for Silent Installation,Upgrade, Relicensing, orRemoval)" on page 22

"Protect the Passwords inthe Response File" onpage 23

"Prepare for a HostedDatabase Installation" onpage 24

"Prepare a Backup File forUpgrade" on page 29

Alliance Access 7.0 - Solaris

14 Installation and Administration Guide

Related information

"Silent Mode" on page 87

"Non-root Installation or Upgrade" on page 87

2.2 Prepare the SystemIntroduction

Review each of the topics in this section to identify the actions that you need to take to prepareyour 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 AllianceAccess, you can also use the checkhost tool to verify that the system meets the minimumrequirements. This tool is provided on the release media. If any problems are detected, thenyou must resolve them before starting the installation. For instructions on how to use this tool,see "Checking Your System Configuration" on page 93.

2.2.1 Define the Alliance File System

Introduction

It is important to consider carefully the size and location of the file system in which AllianceAccess is installed, before you start the installation process. Otherwise, if changes have to bemade 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 ensurethat the user who runs the installation (by default, all_adm) has full read and writeaccess to this directory. For more information about setting permissions on theinstallation directory, see "Prepare for Non-root Installation, Upgrade, Backup, orRemoval" on page 20.

Alliance Access can be installed on a UNIX File System (UFS), if the minimum systemrequirements are met. This file system must have read-write permission. Your Solaris systemadministrator must decide exactly where to install Alliance Access.

Disk space

Before purchasing Alliance Access, SWIFT advised your organisation of the minimum amountof disk space required for the expected level of operations. This figure must be taken as aminimum requirement. The exact amount of space needed for operational data depends on thetraffic processed, number of operators, the frequency with which archives are backed up andremoved, and so on. Clearly, there are advantages in allocating as much space as possible tothe file system in which Solaris is installed. For more information about disk spacerequirements, see the Release Letter.

By default, the software and the database are installed on the same file system. To increaseperformance, the database can be split over several disks. In this case, the configuration of thedatabase is done using dedicated tools (saa_dbinfo, saa_dbconfig), after installation.

Preparation

30 September 2011 15

Mounting local file systems

If the Alliance Access file system is mounted locally, then it is important that no "mount options"are used, particularly nosuid. If nosuid is used, then problems can occur when an AllianceAdministrator logs on.

2.2.2 Requirements for the Host Name

Alliance Access host machine

The host name of the machine on which Alliance Access is installed must meet the followingrequirements:

• maximum of 31 characters

• can only contain the characters 'a-z', 'A-Z', '.', and '-', and the numbers 0 through 9Otherwise, if you use an embedded database, then the database will not start.

Hosted database

The host name of the machine where the hosted database will be installed on Oracle has thefollowing requirements:

• maximum of 31 characters

• can only contain the characters 'a-z', 'A-Z', '.', and '-', and the numbers 0 through 9

Tip The characters are not case-sensitive.

2.2.3 Automatic Time Synchronisation

Overview

When automatic time synchronisation is performed, the time is checked periodically on anumber of machines and compared with a reference time. This is generally done using theNetwork 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 surethat the slewing mode is implemented.

Automatic time synchronisation must be switched off while the Alliance Access servers arerunning because Alliance Access makes extensive use of date and time in its processing. Amanual synchronisation can be done when the servers are stopped (for instance, using a poststop 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.

Alliance Access 7.0 - Solaris

16 Installation and Administration Guide

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 theAlliance 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 theCPU to match the reference time. By doing so, there is no jump in the system's time; italways moves forward.

The implementation of the slewing mode can be considered as acceptable as it does notdeviate from the fact that time only goes forward. However, we have already experiencedproblems on systems where slewing mode was not working as expected due to incorrectfunctioning of the complete time server system. In those cases we did see in the logfiles that thetime moved backwards resulting in Alliance Access restarts.

2.2.4 System Setup

Introduction

Use this checklist to configure the basic hardware and operating system.

System setup checklist

Action Responsible Documentation

Install basic system hardware Hardware Vendor Oracle Solaris manuals

Install DVD drive Hardware Vendor Oracle Solaris manuals

Install Oracle Solaris with supportedpackages and components (see"Prerequisites for the Installation" onpage 32)

Solaris System Administrator Solaris manuals

Alliance AccessRelease Letter

Configure disk partitions and paging space(see "Prerequisites for the Installation" onpage 32)

Solaris System Administrator Solaris manuals

Define file systems and logical volumes Solaris System Administrator Solaris manuals

Install and configure LANs and LANconnections

Solaris System Administrator Solaris manuals

For interactive operations:

X-terminals and associated ports areconfigured and available

Solaris System Administrator Solaris manuals

Assign a <host name> Solaris System Administrator Solaris manuals

Allocate TCP/IP addresses Solaris System Administrator Solaris manuals

2.2.5 Required Information

Purpose

Perform the basic setup of the system, as listed in "System Setup" on page 17. Then, use thischecklist to ensure that you have all the required information at your disposal before installing orupgrading Alliance Access.

Preparation

30 September 2011 17

Checklist

Check the following items:

Required information Responsible Reference

Release Letter Solaris System Administrator Release media

Licensing details (as notified bySWIFT to Security Officers)

Security officers SWIFT licensing agreement

Part 1 of the InitialisationPassword

Left security officer SWIFT licensing agreement

Part 2 of the InitialisationPassword

Right security officer SWIFT licensing agreement

Details of the required softwareinstallation directory

Solaris System Administrator -

For interactive operations:

Identity of the display terminalused for installation

Solaris System Administrator Solaris manuals

Identity of your DVD drive Solaris System Administrator Solaris manuals

2.2.6 Software Installation and Licensing

Checklist

Use this checklist when installing and licensing Alliance Access on your system and for yourdestinations.

Software installation and licensing checklist

Action Responsible Documentation

Log on to the "root" or AllianceAdministrator account

Alliance Administrator Solaris manuals

Start installation process fromDVD or directory

Alliance Administrator "Installation" on page 32

Perform licensing procedures Alliance Administrator andSecurity Officers

Follow system configurationdialogues 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 AllianceAdministrator account

Alliance Administrator

Store release DVD in a safeplace

Alliance Administrator -

Alliance Access 7.0 - Solaris

18 Installation and Administration Guide

2.3 Tracking What Happens During InstallationOverview

The installation process consists of various steps. Some steps are automatic whereas othersrequire that you enter particular values or make choices from a range of options. In general, ifyou complete a particular step successfully, the next window appears automatically.

Having installed Alliance Access software, and performed any additional hardware-relatedconfiguration activities, initial configuration activities must also be performed within AllianceAccess, as described in "Post-Installation Checklist" on page 47.

Following the installation, additional configuration activities may have to be performed,depending on the Alliance options used by your installation.

When Alliance Access software is installed and fully operational, your Alliance Accessadministrator can reconfigure parts of your system and perform various administrative tasks tomaintain 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, theevents that occur during the installation are recorded in the installation.log, and in theinstallation_systemcheck_yymmdd_hhmmss.html file.

These files are found in the Alliance Access installation directory, or else, in the temporaryinstallation directory. For more information about the temporary directory, see "Create theTemporary Installation Directory" on page 19.

The log is stored in the temporary directory until you successfully provide the path and name ofthe installation directory during the installation. After you provide the installation directorysuccessfully, 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, describingthe nature of the error, as well as giving the full text of the actual error message reported byyour 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 theinstallation if a problem occurs. However, if an error is easily resolved (for example, you enteredthe 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 installationprocedure. 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 DirectoryDescription

You must ensure that a temporary directory is available before launching product installation orupgrade, or patch installation. This is so that information relating to the installation/upgrade canbe logged somewhere before the actual installation directory is known by the system.

Preparation

30 September 2011 19

This temporary directory is specified in either of the following ways:

• When launching the installation or upgrade command, by appending the -tempdir option tothe 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 Accessinstance. To prepare for a backup, installation, upgrade, or removal operation of AllianceAccess with an account that does not have root privileges, the UNIX root account must performspecific tasks before and after the operation.

The non-root user account must be the same operating system account that owns theSWIFTNet 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 thefollowing:

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 21.

This non-root user will become the owner of the installation.

4. If you are installing, then create the installation directory with the correct ownership andprotections (750). The default directory path is:

/Alliance/Access

Important The user account that will run the installation must have full access to thisdirectory for example, all_adm.

5. If you are upgrading Alliance Access or Alliance RMA from release 6.3, then change thepermissions of the central registry location. Type:

/usr/bin/chmod 644 /var/opt/swift/*.swiftBefore you upgrade 6.3 to 7.0 on a UNIX cluster with a non-root user, ensure that theversion file (/saa.<date>. swift for Access, /sar.<date>. swift for RMA) in /var/opt/swift/ isreadable for the non-root user.

6. a. Create a directory named root under your installation directory (either created in step 4or, for an upgrade, the directory created during the previous installation) with sufficientpermissions (700). The root directory must be owned by the SWIFTNet Link owner.

Alliance Access 7.0 - Solaris

20 Installation and Administration Guide

b. Grant access to the root directory to the owner of the installation. Type:

/usr/bin/chown <alliance access owner account>:sagsnlg <install_dir>/root

c. Copy the oradism executable from the Alliance Access DVD to the root directory thatyou created. The oradism executable is located in the same directory as the softwareinstaller.

Oracle uses the oradism tool to lock and unlock shared memory.

d. Change the ownership of the oradism executable to root:sagsnlg. Type:

/usr/bin/chown root:sagsnlg <install_dir>/root/oradism where <install_dir> must be replaced with the path to the installation directory.

Important The user account that will run the installation must have read access tothis directory (for example, all_adm).

e. Change the permissions of the oradism executable. Type:

/usr/bin/chmod 4755 <install_dir>/root/oradismwhere <install_dir> must be replaced with the path to the installation directory.

2.6 Create the sagsnlg and alliance GroupIntroduction

Before installing Alliance Access, create the sagsnlg and alliance groups by completing thesteps 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 inthe third column.

3. Create the groups sagsnlg with the selected group IDs by executing the commands:

groupadd -g <group_ID> sagsnlggroupadd -g <group_ID> alliance

2.7 Prepare the Licence FileApplicability

This procedure explains how to prepare the licence file. Once prepared, the file can be used asan 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.

Preparation

30 September 2011 21

Procedure

1. Insert the Alliance Access product DVD.

2. On the DVD, in the folder for Alliance Access, navigate to the SunOS/installerdirectory.

3. Copy the silent.properties.lic.saa file from the Alliance Access product DVD to a directoryof your choice.

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 canbe 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 moreinformation, see "Record input parameters" on page 88.

• Modify the sample response file provided on the Alliance Access product DVD, as describedin 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 SunOS/installerdirectory.

3. Copy the appropriate response file from the Alliance Access product DVD to a directory ofyour choice:

• silent.properties.install.saa.embedded, if you are installing the supplied database

• silent.properties.install.saa.hosted, if you are installing into your own database

• silent.properties.relicensing, if you are relicensing

• silent.properties.uninstall, if you are removing Alliance Access.

Note The directory you choose must also contain the appropriate licence file (beforelaunching the installation or upgrade).

Alliance Access 7.0 - Solaris

22 Installation and Administration Guide

4. Edit the file to incorporate the required information. The file contains information aboutwhich parameters are required.

For more information, see "Response File Parameters" on page 89.

5. Obfuscate or encrypt the system, Left and Right initialisation passwords or any other databy using the obfuscation tool provided on the Alliance Access product DVD.

For more information, see "Protect the Passwords in the Response File" on page 23.

6. Save the file.

If you intend to perform a non-root installation or upgrade, then save the file so that it canbe read by the user account that performs the non-root installation or upgrade.

2.9 Protect the Passwords in the Response FilePrinciple

Silent installation or upgrade operations require that the system account password and Left andRight 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 orany other data.

Run the obfuscation tool

1. On the Alliance Access product DVD, navigate to the SunOS/installer directory.

2. Run the obfuscator tool, which creates a digest that hides the password.

To encrypyt a password with a key that you provide, run the obfuscator tool with the -keyoption.

If you use the -key option, you will be prompted to enter the key to be used. The same keymust 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, andone numeral.

• The number of occurrences of the same character must not exceed half the length of thekey.

3. You are prompted to enter the data (password) to be obfuscated or encrypted.

The result is displayed.

The digest value starts with ----.

4. Copy the resultant data displayed to the appropriate parameter in your response file.

Preparation

30 September 2011 23

2.10 Prepare for a Hosted Database InstallationIntroduction

With release 7.0, Alliance Access introduces a new installation model where the AllianceAccess database schema is created in an existing Oracle instance instead of in an Oracleinstance created by the Alliance Access installer.

Note You can only use the hosted database option when installing Alliance Access. Youcannot upgrade an existing version of Alliance Access to use this option.

Before launching this type of Alliance Access installation, the database administrator (DBA) onthe customer Oracle instance must check that the prerequisites have been met. This sectionprovides the detail of these database prerequisites.

In this section, the default tablespace names (SAA_DATA, ...) and user names(SAAOWNER, ...) are used. However, these are configurable during the installation.

2.10.1 Important Information

In the context of an Alliance Access database installed in an Oracle instance provided by thecustomer, 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 arerequired for the generation and restoration of Alliance Access backups of configuration dataand of archives. If several Alliance Access databases are installed on the same Oracleinstance, then these database directory objects must be different per Alliance Accessdatabase. Changing the names of these objects is possible through the Alliance Accessconfiguration screens.

• Creating other objects (such as tables or indexes) in the Alliance Access databaseschema(s) should not be done. These objects may be deleted by Alliance Access (duringinstallation or at run time), or they may prevent the Alliance Access software from workingproperly.

• Installing multiple Alliance Access instances using the same Oracle instance requires thattablespaces, users and directory objects are different between the different Alliance Accessinstances.

• Monitoring the disk space usage of the tablespaces is performed regularly to avoid a crash ofAlliance Access because of unavailable disk space.

• Oracle and its storage infrastructure are configured for protection against media failures, forexample, 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_systemdbbackup.

• Before stopping the Oracle instance and the listener, the Alliance Access servers must bestopped.

• Network connectivity between the Alliance Access host and the Oracle host is reliable.

Alliance Access 7.0 - Solaris

24 Installation and Administration Guide

• After removing Alliance Access, the tablespaces, schemas, and directories listed in thisdocument can be removed from the Oracle instance.

• The Alliance Access backup/restore functionality comprises the backup of archives ofmessages and events, and backup of Alliance Access configuration data. This functionalityrequires a shared file system that is readable and writable from the Oracle system and theAlliance Access system with their owner credentials (for example, an NFS mount). Theshared directory can be set using Alliance Access configuration screens.

• For the Oracle system, the following mount options are required:

rw,bg,hard,rsize=32768,wsize=32768,vers=3,[forcedirectio or llock],nointr,proto=tcp,suidThere are no specific mount option requirements for the Alliance Access system.

• User accounts, group memberships, and permissions must be configured to enable thefollowing:

– for the backup, Alliance Access creates the backup directory. Oracle writes one or moredatapump files and a log file. Alliance Access reads the datapump file(s) and writes aninformation file.

– for the restore, Alliance Access reads the information file and the datapump files from thebackup 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 becreated 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 beset through the memory_target parameter, by setting: memory_target = 1500M.

Preparation

30 September 2011 25

2.10.3 Database User Accounts

Accounts required

Before launching the Alliance Access software installer to install Alliance Access within anOracle instance provided by the customer, the customer must have performed the followingprerequisites:

• The following three Oracle database users (and their associated passwords) are created andavailable for use. These are logical names that will be mapped to physical names atinstallation time:

– SAAOWNER

A database schema owner user: this Oracle user will be used to create the databaseschema (tables, views, indexes, stored procedures, functions, scheduled jobs, ...) ofAlliance Access.

– SAATEMP

A database temporary schema owner user: this Oracle user will be used to managetemporary data when required by Alliance Access (for example, during restore of messagebackups).

– SAAUSER

A database run time user: this Oracle user will be used by Alliance Access to connect tothe installed Alliance Access database whenever Alliance Access requires access to thedatabase.

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 issuccessful, the account status can be set toLOCKed (this is optional).

Authentication method The SAAOWNER must be identified by apassword when connecting to the AllianceAccess database. This setting is mandatory.

Default tablespace SAA_DATA is the default tablespace whereSAAOWNER will create database objects. Thissetting is optional.

SAATEMP Must have the same attributes as SAAOWNER.

SAAUSER Account status UNLOCKed.

Authentication method The SAAUSER must be identified by apassword when connecting to the AllianceAccess database. This setting is mandatory.

Alliance Access 7.0 - Solaris

26 Installation and Administration Guide

User Account Attribute Value and Comment

Default tablespace SAA_DATA is the default tablespace whereSAAUSER will create database objects. Thissetting 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 CRCis 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 andobject privileges as described in the following tables.

SAAOWNER and SAATEMP system privileges

System privilege Comment Usage scope

CREATE ANYDIRECTORY

Used to create directories during backup and restore ofdata.

Run time.

CREATE JOB Used to create jobs during the Alliance Access databaseconfiguration.

Installation orpatch.

CREATEPROCEDURE

Used to create stored procedures, functions and packagesduring the Alliance Access database configuration.

Installation orpatch.

CREATESEQUENCE

Used to create sequences during the Alliance Accessdatabase configuration.

Installation orpatch.

CREATE SESSION Used to connect to Oracle during the Alliance Accessdatabase configuration.

Installation orpatch.

CREATE SYNONYM Used for synonym creation. Installation orpatch.

CREATE TABLE Used to create tables during the Alliance Access databaseconfiguration.

Also used at run time by stored procedures to create dailytables, search tables.

Installation orpatch.

Run time.

CREATE TRIGGER Used to create triggers during the Alliance Accessdatabase configuration.

Also used at run time by stored procedures to createtriggers for daily tables.

Installation orpatch.

Run time.

Preparation

30 September 2011 27

System privilege Comment Usage scope

CREATE VIEW Used to create views during the Alliance Access databaseconfiguration.

Installation orpatch.

UNLIMITEDTABLESPACE

Used for backup and restore operations. Run time.

SAAOWNER and SAATEMP object privileges

Object privilege Comment Usage scope

EXECUTE onDBMS_LOB

Perform certain operations on LOBs. Run time.

EXECUTE onDBMS_LOCK

Used for concurrency control of certain database objects. Run time.

EXECUTE onDBMS_FLASHBACK

Used during backup. Run time.

SELECT onDBA_LOBS

Used for table and tablespace size calculations during thebackup/restore operations.

Run time.

SELECT onDBA_SEGMENTS

Used for table and tablespace size calculations during thebackup/restore operations.

Run time.

SELECT onDBA_FREE_SPACE

Used for table and tablespace size calculations during thebackup/restore operations.

Run time.

SELECT onDBA_DATA_FILES

Used for table and tablespace size calculations during thebackup/restore operations.

Run time.

SELECT onDBA_TABLESPACES

Used for table and tablespace size calculations during thebackup/restore operations.

Run time.

SELECT onDBA_INDEXES

Used for table and tablespace size calculations during thebackup/restore operations.

Run time.

SELECT on V_$DATABASE

Used to determine OS in stored procedures. Run time.

SELECT onDBA_DATAPUMP_JOBS

Used for backup and restore operations. Run time.

SAAUSER system privileges

Object privilege 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 orpatch.

CREATE ANYDIRECTORY

Used to create directories during backup and restore ofdata.

Run time.

Alliance Access 7.0 - Solaris

28 Installation and Administration Guide

2.11 Prepare a Backup File for UpgradeIntroduction

You can use backed up configuration data from a compatible earlier release of Alliance Accessor 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 fromOracle Solaris to Oracle Solaris).

Note The backup file does not include:

• the usrdata directory and content therein. The data contained in this directory isstill available on the host where the backup was generated, even if the AllianceAccess software is uninstalled. The data can safely be copied manually to thenew 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 inthe $ALLIANCE/mig directory.

This report can be looked at to identify any pre-requisites related to routing rules, routingkeywords 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 beupdated or removed in advance.

Compatibility

Regardless of installed patches, the backup files of the following releases of Alliance Access arecompatible 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 youperform the following actions:

1. From the SWIFT Interface application, Quit and Logout all logical terminals and switch themall to Manual mode. For details, see the Daily Operations Guide.

2. From the SWIFT Support application, ensure that all logical terminals in use are assignedthe latest Message Syntax Table. For details, see the System Management Guide.

3. From the Application Interface application, select all the message partners and disablethem.

Preparation

30 September 2011 29

4. Export RMA authorisations. For details, see "Exporting Authorisations Manually" in theRelationship Management Application User Guide.

Note During the upgrade, RMA authorisations are automatically migrated to the newrelease. This step is only to provide you with a backup in case of problemswith RMA migration during the upgrade process.

5. Ensure that all message templates have the latest message syntax table assigned andexport 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 withtemplate migration during the upgrade.

If, after the upgrade, message templates cannot be opened or modifiedbecause they are assigned to an earlier message syntax table, then you canexport the message templates and assign the latest message syntax table tothem during the import.

6. Follow the instructions about preparing for upgrade in the Release Letter.

2.11.2 Create a Backup File for Upgrade

Prerequisites

1. Ensure that Alliance Access or Alliance RMA is not running.

2. Verify that the server for which a backup will be taken is not running, and that the SystemAdministration window is not open.

3. If you are running Alliance Access 6.3.x or Alliance RMA 6.3.x, and database recovery isactivated, then deactivate it before starting the upgrade. For more information, see"Deactivate the Database Recovery Mode" on page 177.

Procedure

1. Log on with sufficient privileges.

2. Stop Alliance Access or Alliance RMA on the host machine.

3. Insert the Alliance Access product 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.0where <IPaddressComputer> must be replaced by the IP address for the computerwhere the installation windows will be displayed.

5. Navigate to the folder that contains the Alliance Access installation program.

SunOS/installer

6. Double-click the saa-install file.

Alliance Access 7.0 - Solaris

30 Installation and Administration Guide

7. The installation program inspects your system and the Welcome to the Alliance AccessInstaller window appears. This window might appear in the background, so you may haveto close or minimise other windows to find it.

If the installation program detects a compatible previous release of Alliance Access orAlliance RMA on your host system, then the Prepare Backup File for Upgrade option isthe 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, theneither type the full physical path or click Browse to provide the location. You cannot providea symbolic link as a valid path.

If the directory specified already contains a backup file, then a warning message appearsasking you to provide a suitable directory.

10. Click Next .

A message appears that prompts you to close any open Alliance applications (for example,the Alliance Command Prompt) before you proceed with the backup.

Click 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 remainpresent in the database, and that the backup file does not include these. Completedmessages, events, and audit cards must be archived and backed up before they can berestored to the other system.

Click OK to continue.

12. Click Finish to complete the backup operation.

The following files are created as a result:

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 wasbacked up.

installation.log Contains details about the backup procedure. This file is present in theinstallation directory of Alliance Access or Alliance RMA.

Preparation

30 September 2011 31

3 InstallationOverview

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 Sun server hardware has been installed and tested.

• your system has been prepared according to the instructions in the section "Preparation" onpage 13.

• for an interactive installation:

– both Alliance Access Security Officers (or their deputies) are present

– X-terminals have been installed and tested

• for a silent installation, you have prepared the following files:

– a licence file. See "Prepare the Licence File" on page 21.

– a response file. See "Prepare the Response File (for Silent Installation, Upgrade,Relicensing, or Removal)" on page 22.

• the Alliance Access Administrator account has been created on the system.

Additional information

Before you begin the installation, you also need the following:

• access to the root or Alliance Access Administrator account of your system (this may requirethe presence of your local Solaris system administrator, or the issuing of a temporarypassword 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 installationand perform the following:

• Remove the product DVD and store it in a safe place.

• Log off.

• Seek advice about the problem.

• Restart the complete installation process.

Alliance Access 7.0 - Solaris

32 Installation and Administration Guide

3.1.2 Mounting the DVD Drive

Procedure

• Insert the Alliance Access product DVD.

3.2 Interactive Installation

3.2.1 Launching the Interactive Installation From DVD

Overview

Before starting an installation, ensure that the machine is reserved for your use for the durationof the installation.

To launch the installation program:

1. Log on as root (or Alliance Access owner account).

Note: it is assumed that the root (or Alliance Access owner account) account will use theKorn shell. See the entry for root (or Alliance Access owner account) in the /etc/passwdfile. The entry should end with the following shell invocation:

..:/bin/ksh

2. If you are working remotely, then export the display to your local machine by typing:

export DISPLAY=<IPaddressComputer>:0.0where <IPaddressComputer> must be replaced by the IP address for the computerwhere the installation windows will be displayed.

3. Ensure that the SunOS directory where the Alliance Access software will be installed hasbeen created by the Solaris system administrator. Ask your system administrator for thename of this directory. During the installation, you are prompted to supply this directory aspart of the release tree path name.

4. If the disk space requirements for the temporary files for the install program cannot besatisfied, then you can use the installer option -tempdir <TMPDIR> to specify analternate temporary directory.

5. If you are using the standard /tmp directory, then remove all sh* files from the directory bytyping:

rm /tmp/sh*

6. Check that the volume manager vold is running by typing:

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

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

/etc/init.d/volmgt start

7. Insert the Alliance Access release DVD.

8. Navigate to the following directory in the folder for Alliance Access:

/SunOS/installer

Installation

30 September 2011 33

9. Start the installation process by typing:

./saa-installTo record the installation details for future use, run the saa-install command with the -record option. See "Record input parameters" on page 88 for more information.

10. To proceed with the installation, follow the steps in "Install Alliance Access Interactively" onpage 35.

During installation, you specify the UNIX account name used by the Alliance administrator forthis 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 youleave the Alliance Access release DVD in its respective drive until the installation is complete.

To launch the program from a remote DVD drive

1. Mount the DVD on the remote system.

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 DVD from the local machine using the local name.

5. Navigate to the following directory in the folder for Alliance Access:

/SunOS/installer

6. Type the command:

./saa-installTo record the installation details for future use, run the saa-install command with the -record option. See "Record input parameters" on page 88 for more information.

3.2.2 Launching the Interactive Installation From a Directory

Introduction

The following procedure describes how to start the installation from a directory.

To launch the installation program:

1. If the disk space requirements for the temporary files for the install program cannot besatisfied, then you can use the installer option -tempdir <TMPDIR> to specify analternate temporary directory.

2. Check that the volume manager vold is running, by typing:

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

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

/etc/init.d/volmgt start

3. Insert the Alliance Access release DVD.

Alliance Access 7.0 - Solaris

34 Installation and Administration Guide

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

mkdir <install directory>cd <install directory>cp -r /cdrom/<mount point>/* .

5. Navigate to the following directory in the created install directory:

/SunOS/installer

6. Type the following command:

./saa-installTo record the installation details for future use, run the saa-install command with the -record option. See "Record input parameters" on page 88 for more information.

7. To proceed with an interactive installation, follow the steps in "Install Alliance AccessInteractively" on page 35.

During installation, you specify the UNIX account name used by the Alliance administrator forthis installed instance of Alliance Access.

Throughout the installation, the install program periodically accesses the install directory tocopy, 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 example:

cd /<mountpoint>/SunOS/installer

5. Type the following command:

./saa-installTo record the installation details for future use, run the saa-install command with the -record option. See "Record input parameters" on page 88 for more information.

3.2.3 Install Alliance Access Interactively

Installation event log

Events that occur during installation are recorded in the installation.log file, found in theAlliance Access installation path or in the default temp directory if the installation directory hasnot yet been entered. In case of installation failure, please check this file for the reasons of thefailure.

Installation

30 September 2011 35

To install Alliance Access interactively:

1. When the installation program starts, it unpacks the files required.

Once all the files are unpacked, the Welcome window is displayed:

Note The options available vary according to your current installation (if any).

2. 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 fromPrepared Backup File. For more information, see "Prepare a Backup File for Upgrade" onpage 29.

3. Click Next .

The End-user Licence window appears.

4. Accept the terms, and click Next .

If you are installing from a backup file, then the Backup File Location window appears.Browse for the location of your backup file.

If you are installing for the first time, then the Installation Location window appears.

Alliance Access 7.0 - Solaris

36 Installation and Administration Guide

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 newdirectory in Directory Name field. For more information about settingpermissions on the installation directory, see "Prepare for Non-root Installation,Upgrade, Backup, or Removal" on page 20.

6. In the Owner field, specify the user that will own the installation files.

The owner cannot be root because the installed files are restricted to owner account.

7. In the Database field, select whether you want to install Alliance Access with the Oracledatabase 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 usedis installed.

For more information about the host name requirements, see "Requirements for the HostName " on page 16.

• Port

Enter the port number to be used by Alliance Access to connect to the Oracle instance.

• Service

Enter the service ID identifying the Oracle instance.

Installation

30 September 2011 37

Tip If the database is Embedded the hostname must meet the same criteria.

8. Click Next .

9. The checkhost command is run to validate whether your system meets the minimumoperating system requirements. The test results are saved in the software installationdirectory, 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 windowappears.

This window is used to license the packages and features that your institution haspurchased from SWIFT. The pre-selected packages are part of the base licence and cannotbe deselected.

Note If your system does not meet all the requirements, then the SystemConfiguration Test Results window displays information about the problemsthat were detected.

The Result column specifies the severity of a reported problem:

• Problems reported as Warning do not prevent you from continuing theinstallation, but you may encounter unexpected results.

• Problems reported as Blocking prevent you from continuing theinstallation. Fix the problem and start the installation again.

10. Decide how you want to provide licence-related data.

Manually: proceed to step 11.

From a licence file: click Load from File and browse to the location of the licence file. Thenclick Next and proceed to step 16.

Alliance Access 7.0 - Solaris

38 Installation and Administration Guide

11. Select the licensed components, using the items listed in the Packages section of yourlicensing agreement. Then click Next .

Note You may want to license additional component packages or 'disable' selectedcomponent packages after the installation is finished. To do this, you canrelicense Alliance Access using a new licensing agreement. You do not haveto reinstall. For more information, see "Relicensing" on page 77.

12. The Servers Configuration window appears.

13. Select the licensed components, using the items listed in the Servers section of yourlicensing 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 yourlicensing agreement.

• the 8-character training destinations. The eighth character is a 0 (zero), to denote testand training. Although the test and training destination does not appear on your licensingagreement, 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 yourlicensing agreement.

Each message type must be on a separate line. Once you have typed all your messagetypes, click Next .

The Initialisation Password Configuration window appears.

Installation

30 September 2011 39

16. Enter the initialisation passwords as follows:

• The Security Officer who received the INITIALISATION PASSWORD provided in Part 1of 2 of the licensing agreement must type this password in the First initialisationpassword field.

• The Security Officer who received the INITIALISATION PASSWORD provided in Part 2of 2 of the licensing agreement must type this password in the Second initialisationpassword field.

Note Do not confuse the Initialisation Passwords with the Master Passwords. TheMaster Passwords are used by the two Security Officers when they first signon to Alliance Access.

17. Click Next .

If the password verification fails, then an error message appears. Click OK and enter thecorrect input.

Alliance Access 7.0 - Solaris

40 Installation and Administration Guide

18. The Instance Configuration window appears.

Field Description

Host Name The host name of the Alliance Access system. For more information aboutthe host name requirements, see "Requirements for the Host Name " onpage 16.

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 muststart with an alphabetical character. It can contain the "_" character.

If several instances are installed, each one must have a unique instancename.

Instance Comment A description of the instance.

It can contain alphanumeric characters and spaces, and must not exceed30 characters.

19. If necessary, change the default values in the IP Address, Instance Name, and InstanceComment fields.

20. Click Next .

If you have selected the embedded database option, the Installation Summary windowappears. Go to step 24.

If you have selected the hosted database option, the Database User Names andPasswords window appears. Go to step 21.

21. Enter the names and passwords of the Oracle database users required (as set up duringthe preparation phase as described in "Database User Accounts" on page 26).

Schema Owner and password: this is the user that will be used by the Alliance Accesssoftware 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 connectto the installed Alliance Access database.

Installation

30 September 2011 41

Temp Schema Owner and password: this is the user that will be used by the AllianceAccess software when temporary data are to be managed (for example during restore ofbackups).

Click Next .

Note These user names and passwords cannot exceed 30 characters and mustcomply with the Oracle user name and password specifications.

22. Enter the names of the tablespaces that Alliance Access should use (as set up during thepreparation phase as described in "Tablespaces" on page 27).

In the Data Tablespace field, enter the name of the tablespace containing the AllianceAccess configuration data (SAA_DATA).

In the File Tablespace field, enter the name of the tablespace containing the AllianceAccess FileAct payloads (SAA_FILE).

In the Event Tablespace field, enter the name of the tablespace containing the AllianceAccess events (SAA_JRNL).

In the Message Tablespace field, enter the name of the tablespace containing the AllianceAccess messages (SAA_MESG).

In the Temporary Tablespace field, enter the name of the tablespace used by AllianceAccess 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 , itis 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 throughvarious 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 aboutport configuration, see "TCP Configuration for the Alliance Access Server" on page 243.

The window also reminds you to perform SWIFTNet configuration activities.

25. Click Finish to complete the installation.

Alliance Access 7.0 - Solaris

42 Installation and Administration Guide

Note Once the installation has completed successfully, if you have installed fromDVD, remove the DVD as follows:

1. Check if the volume manager vold is running by typing:

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

root 342 1 80 Oct 16 ? 0:01 /usr/sbin/voldIf vold is not running, restart it by typing:

/etc/init.d/volmgt start

2. To remove the DVD, type:

cd ~ejectIf this command returns the error Device is busy, this means thatthere is some process still using the DVD software. This is probably theSystem Administration application itself. Quit the System Administrationwindow and run the following in the controlling x-term:

cd /Try again to eject the DVD.

26. Perform the post-installation steps described in the Release Letter. Then follow theinstructions in "Post-Installation Checklist" on page 47.

27. Following initial software installation, when the servers are first started, one alarmmessage, per live destination, is displayed, similar to:

********************* ALARM ********************SUBSET DEFINITION: 'XXXX': INITIALISED TO SYSTEM DEFAULTSuch alarms, which are also logged in the Event Journal as 'severe' events, result from thefact that the licensed destinations do not yet have delivery subsets defined for them inAlliance Access. These alarms are normal.

3.3 Silent Installation

3.3.1 Install Alliance Access Silently From DVD

Overview

Before starting an installation, ensure that the machine is reserved for your use for the durationof the installation.

To install Alliance Access silently from DVD

1. Log on as root (or Alliance Access owner account).

Note: it is assumed that the root account (or Alliance Access owner account) will use theKorn shell. See the entry for root (or Alliance Access owner account) in the /etc/passwdfile. The entry should end with the following shell invocation:

..:/bin/ksh

Installation

30 September 2011 43

2. If you are working remotely, then export the display to your local machine by typing:

export DISPLAY=<IPaddressComputer>:0.0where <IPaddressComputer> must be replaced by the IP address for the computerwhere the installation windows will be displayed.

3. Ensure that the SunOS directory where the Alliance Access software will be installed hasbeen created by the Solaris system administrator. Ask your system administrator for thename of this directory. During the installation, you are prompted to supply this directory aspart of the release tree path name.

4. If the disk space requirements for the temporary files for the install program cannot besatisfied, then you can use the installer option -tempdir <TMPDIR> to specify analternate temporary directory.

5. If you are using the standard /tmp directory, then remove all sh* files from the directory bytyping:

rm /tmp/sh*

6. Check that the volume manager vold is running by typing:

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

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

/etc/init.d/volmgt start

7. Insert the Alliance Access release DVD.

8. Navigate to the following directory in the folder for Alliance Access:

/SunOS/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

Note The licence file must also be present in the same directory.

• -key <value> specifies the key to be used if the password(s) in the response file havebeen encrypted.

Important Throughout the installation, the install program periodically accesses the installdrive to copy, install, and license the various components of Alliance Access. Itis therefore important that you leave the Alliance Access release DVD in itsrespective drive until the installation is complete.

10. Perform the post-installation steps described in the Release Letter. Then follow theinstructions in "Next Steps" on page 47.

Alliance Access 7.0 - Solaris

44 Installation and Administration Guide

Installing from a remote DVD drive

1. Mount the DVD on the remote system.

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 DVD from the local machine using the local name.

5. Navigate to the following directory in the folder for Alliance Access:

/SunOS/installer

6. Type:

./saa-install -silent <response file> [-key <value>]Where:

• <response file> identifies the path to and name of the properties file to be used.

For example:

/tmp/alliance/silent.properties.install.saa.embedded

• -key <value> specifies the key to be used if the password(s) in the response file havebeen encrypted.

7. Perform the post-installation steps described in the Release Letter. Then follow theinstructions in "Next Steps" on page 47.

Viewing the silent installation progress or result

The installation log file is updated during a silent installation. You can view the log to see theprogress 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

The following procedure describes how to start the installation from a directory.

To start the installation process:

1. If the disk space requirements for the temporary files for the install program cannot besatisfied, then you can use the installer option -tempdir <TMPDIR> to specify analternate temporary directory.

2. Check that the volume manager vold is running, by typing:

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

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

/etc/init.d/volmgt start

3. Insert the Alliance Access release DVD.

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

mkdir <install directory>

Installation

30 September 2011 45

cd <install directory>cp -r /cdrom/<mount point>/* .

5. Navigate to the following directory in the created install directory:

/SunOS/installer

6. Type:

./saa-install -silent <response file> [-key <value>]Where:

• <response file> identifies the path to and name of the properties file to be used.

For example:

/tmp/alliance/silent.properties.install.saa.embedded

• -key <value> specifies the key to be used if the password(s) in the response file havebeen encrypted.

Important Throughout the installation, the install program periodically accesses the installdirectory to copy, install, and license the various components of AllianceAccess.

7. Perform the post-installation steps described in the Release Letter. Then follow theinstructions in "Next Steps" on page 47.

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 example:

cd /<mountpoint>/SunOS/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.

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 havebeen encrypted.

6. Perform the post-installation steps described in the Release Letter. Then follow theinstructions in "Next Steps" on page 47.

Viewing the silent installation progress or result

The installation log file is updated during a silent installation. You can view the log to see theprogress of the silent installation, or the result if the silent installation operation has ended.

Alliance Access 7.0 - Solaris

46 Installation and Administration Guide

3.4 Next StepsHow to use this section

After installing Alliance Access, you must perform a number of software tasks before it is readyfor 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 notsure what is required of you, then go to the other SWIFT documentation that is referred to in thetask. Also, remember that there is an online Help system installed with Alliance Access. If, aftercareful reading of all the documentation, you are still not sure how to proceed, then contactSupport.

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 authenticateusers, then make sure that an authentication server has been provided and deployed. For moreinformation about one-time passwords and authentication servers, see the Security Guide andthe 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, installit and load the packages for Alliance Access

Alliance Administrator Web Platform documentation

Log on to Alliance Access using the administratoraccount. Enter a new password when prompted.

This must be done from the console to avoid any$DISPLAY problems.

Alliance Administrator Security Guide

Installation andAdministration Guide

Start the Alliance Access servers Alliance Administrator Installation andAdministration Guide

Wait for servers to be ready. Do not quit the SystemAdministration application.

Alliance Administrator Installation andAdministration Guide

From Alliance Workstation, sign on as left securityofficer 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 securityofficer 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 thedefaults provided).

Right security officer Security Guide

Create new operator(s) (with "Supervisor" or"SuperKey" privileges). Assign SWIFTNet Supportapplication permissions to other operators if needed.

Right security officer System Management Guide

Installation

30 September 2011 47

Action Responsible Documentation

Approve new operator(s). Right security officer System Management Guide

Display RIGHT part of system password(s) for newoperator(s).

Right security officer System Management Guide

Sign on to Alliance Access as left security officerusing 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 newoperator(s).

Left security officer System Management Guide

Sign on to Alliance Access as an operator, using thesystem 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 / Rightsecurity officer

System Management Guide

Set up your security parameters. Alliance Administrator Security Guide

In the System Management application, define andselect the SWIFT destination for alarm generatedmessages (MT 999).

New operator System Management Guide

Not required for standalone Alliance Access:

In the System Management application, start theSNIS, 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 updatedpassword.

New operator Daily Operations Guide

Install and activate Value Added Service ParameterFiles (if required).

New operator System Management Guide

Install the Alliance Bank File from the CorrespondentInformation File application (if required).

New operator System Management Guide

Install any MX Standards which are to be used (ifrequired).

New operator "Installing MX Standards" onpage 50

System Management Guide

To prepare your Destinations, install the MessageSyntax Tables (MSTVs) from the SWIFT Supportapplication.

New operator System Management Guide

Still in Housekeeping mode, define the LTs (LogicalTerminals) 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 CorrespondentInformation File application and in the SearchCriteria window, click Cancel .

New operator Daily Operations Guide

Alliance Access 7.0 - Solaris

48 Installation and Administration Guide

Action Responsible Documentation

From the Correspondent menu, select New, and inthe Institution field, enter your BIC-11 Test &Training code, for example ALIBBEB0XXX. Add thedetails fields, if required.

New operator Daily Operations Guide

Click the Other tab and change the CorrespondentDefinition to Internal. Click the IntegratedApplication tab. In the Preferred Networks list,transfer "SWIFT" from Available to Selected. Fromthe Correspondent menu, select Add.

New operator Daily Operations Guide

Set up the RPC and SSL Security between AllianceAccess and Alliance Workstation (if required).

Alliance Administrator See "RPC and SSL Securityfor Alliance Workstation" onpage 53.

Not required for stand-alone Alliance Access:

Define a SWIFTNet connection and assign a logicalterminal to it, and then send and receive a testmessage.

To test the connection, you need the details of theAlliance Gateway instances that you plan to use.

Part B, "Configuring forSWIFTNet" on page 97

Define new message partners (if required) New operator System Management Guide

Not required for stand-alone Alliance Access:

In the System Management application, start SNIS,used for InterAct and FileAct activities (including RMA(Relationship Management application))

New operator 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 thedefaults (System, Urgent, Normal):

• generate MT 035 in Message Creation application

• Login/Select (I/O without delivery subsetsselected) the logical terminal used to send the MT035

• wait for MT 055 response (handled automaticallyby Alliance Access). Subsets are updated.

• perform QUIT for this logical terminal

Any operator System Management Guide

Redefine delivery subsets, if the defaults areinsufficient:

Any operator

• redefine the subsets by using the SWIFT Interfaceapplication

System Management Guide

• Login with this logical terminal to send themessage

Daily Operations Guide

If you have installed from a backup file and theDatabase Recovery option is licensed, you mustmanually activate database recovery by using thesaa_dbrecovery tool.

Alliance Administrator "Activate the DatabaseRecovery Mode" onpage 176

Not required for stand-alone Alliance Access: Alliance Administrator Part B, "Configuring forSWIFTNet" on page 97

Installation

30 September 2011 49

Action Responsible Documentation

If you plan to test the connection with SWIFT, thenensure that the SWIFTNet connection with theAlliance Gateway is operational.

Install and configure printers (if required) Solaris System Administrator Oracle Solaris 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 followingtasks 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. Forexample:

<Install_directory>/install/saa_rootpostinstall.kshThe script:

• runs the RPCConfiguration.ksh script which delivers the new version of the files inthe /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 duringinstallation) 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 highestrelease number.

3.4.3 Installing MX Standards

Description

To allow MX keyword extraction on Alliance Access from messages exchanged over SWIFTNetservice or services to which you subscribed, the corresponding MX standard(s) must beinstalled on Alliance Access and on the Messenger package of Alliance Web Platform. You candownload the appropriate message standards deployment package(s) and accompanying coverletter(s) from the Download Centre on www.swift.com > Support > Download Centre.

Note • Using the Messenger 6.3 package to install a message standards deploymentpackage on Alliance Access 7.0 is not supported.

• Support for System Messages related to SWIFTNet 7.0 requires the installationof the SWIFTNet 7.0 System Messages Deployment Package.

Alliance Access 7.0 - Solaris

50 Installation and Administration Guide

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 authorisationmessages for FIN Test and Training. You must configure a licensed BIC as the destination forall FIN Test and Training authorisation messages. That BIC is referred to as the Signing BIC forTest and Training.

RMA service for FIN Test and Training

The authorisations for the pilot service and FIN Test and Training are exchanged overswift.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 andTraining authorisation messages. The Signing BIC for Test and Training must be the BIC8for which you will create the emission and reception profile.

For more information, see "Defining the Signing BIC for Test and Training Authorisations"on page 52.

2. For FIN Test and Training destinations, define a SWIFTNet Emission profile and aReception profile for each Signing BIC for Test and Training.

For more information, see "Configuring SWIFTNet Emission and Reception Profiles" onpage 110.

3. If necessary, change the operator profiles and assign them to the users that will operateand administer the RMA. You can use or adapt the default operator profiles, RMA_Adminand RMA_Oper, or create profiles for your own use.

For more information about the default operator permissions, see the System ManagementGuide.

For details about default operator profiles, and for instructions on modifying or assigning aprofile to a user, see "Managing Alliance Access Security" in the System ManagementGuide.

4. If you do not want to confirm the authorisations that your correspondent revokes or rejects,then set the Needs Status Confirmation security parameter.

For more information, see "Security Parameters" in the System Management Guide.

Note The confirmation is for information purposes only. The revocation and rejectionof the authorisation always takes effect regardless of whether the action isconfirmed or not.

3.4.5 Configuring RMA for the SWIFTNet Integration Testbed

Purpose

This procedure provides additional instructions for configuring RMA for the SWIFTNetIntegration Testbed.

Perform these instructions on the Alliance Access server, and on each Alliance workstation.

Installation

30 September 2011 51

Important Only SWIFT, and its partners and vendors that have a BIC starting with PT, mustperform 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 exchangedover 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 Administrationwindow.

3.4.6 Defining the Signing BIC for Test and TrainingAuthorisations

Purpose

FIN Test and Training authorisations are exchanged as InterAct messages over theswift.rma!p service over SWIFTNet, and are signed by an Authoriser DN. Therefore, youmust define a licensed live BIC, the Signing BIC for Test and Training, as the signing BIC8destination of all FIN Test and Training authorisation messages.

This procedure provides instructions for setting the value of the Signing BIC for Test andTraining, which must be a BIC8 for which an emission profile and a reception profile is definedfor the service swift.rma!p.

Users and permissions

You can define the Signing BIC for Test and Training when the Def Signing BIC T&Tfunction 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.

Alliance Access 7.0 - Solaris

52 Installation and Administration Guide

3. Select a BIC8 to use for signing Test and Training authorisations.

4. Click OK .

3.4.7 RPC and SSL Security for Alliance Workstation

Introduction

Security between the Alliance Access servers and an Alliance Workstation is defined by the RPCAuthentication configuration parameter. After a new installation, the default setting isProcess Authentication. Security officers can change this setting from the SecurityDefinition application.

If you upgrade to release 7.0, then the upgrade process migrates your current setting for theparameter.

Secure Socket Layer (SSL) is also available for the encryption of the data for thecommunication between the Alliance Access server and an Alliance Workstation. This can be asfollows:

• If Off or Process Authentication is selected, then Alliance Access does not use SSLfor communication with the Alliance Workstation.

• If Data Integrity or Data Confidentiality is selected, then Alliance Accessinitialises 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 AllianceAccess server authentication is required.

The following security options are available for process communication with the AllianceWorkstation:

• SSL

• SSL and Server Authentication

• No SSL

If SSL is used, then the ssl.p12 file contains the self-signed certificate and private key. ForAlliance Access, this file is stored in the $ALLIANCE_DB directory. A self-signed certificate isgenerated and imported during installation or migration. The default certificate is contained inthe cacert.crt file in the $ALLIANCE_DB directory. This default certificate expires after 730days. The DN of the default certificate has the value cn=saa_<instance name>. It iscontained 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 ofthe 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 thedisaster backup system.

If Server Authentication is used, then it is the responsibility of the Alliance Administrator tomaintain the CA Certificate and Private Key. The CA Certificate can be generated or a requestcreated using the swrpc_keytool tool.

The CA Certificate must then be imported into Alliance Access using thesaa_configconnection tool. For details, see "saa_configconnection" on page 230.

Installation

30 September 2011 53

3.4.7.1 Certificate Generation for Server Authentication (swrpc_keytool)

Overview

If Server Authentication is used, then it is the responsibility of the Alliance Administrator togenerate a CA Certificate and Private Key. A self-signed Certificate or CA Certificate request iscreated using the swrpc_keytool tool. This tool is located in $ALLIANCE/ BSS/bin/$ARCHand 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 certificaterequest.

a Do you want: 1: aself-signedcertificate

If you select 1, then a self-signed certificate is generated,which is signed with its corresponding private key. In thiscase the CA certificate and the certificate itself are identical.The subject and issuer of a self-signed certificate are thesame.

2: a certificaterequest [default, 1]:

If you select 2 to generate a certificate request, then a PKCS-10 file (Request for Certificate), is generated. You mustpresent this file to a CA (Certificate Authority) to receive acertificate. In this case, the subject and issuer of thecertificate are different. The subject is the DN you entered inthe certificate request, and the issuer is the DN of the CA. Touse server authentication in this case, you must receive boththe certificate and the CA certificate.

b File name for the newkey:

Enter the path and file name for the private key. If you enteronly the file name by default, then the file is created in thecurrent directory.

c Enter a password ofyour choice:

The key is password-protected. Select a password thatcomplies with your institution's password policy and thefollowing rules.

The password must have:

• min. 8 and max. 30 alphanumeric characters

• at least 1 uppercase, 1 lowercase, and 1 number

Repeating consecutive characters may not exceed half thepassword: and may not be equal to the protected file name.

d Re-enter the passwordfor verification:

Re-enter the password for verification: The new key is nowgenerated. If you selected option 2 in step a, then skip to stepg.

e File name for thecertificate:

Enter the file name for your certificate. If the file exists, thenyou are prompted to overwrite the file. If the file does notexist, then skip to step i.

Alliance Access 7.0 - Solaris

54 Installation and Administration Guide

f Overwrite existingfile? [default, n]:

Enter yes (y) to overwrite an existing file: skip to step i, orenter no (n) to return to step e.

g File name for thecertificate request:

Enter the file name for your certificate request. If the fileexists then you are prompted to overwrite it. If not, skip tostep i.

h Overwrite existingfile? [default, n]:

Enter yes (y) to overwrite an existing file: skip to step i, orenter no (n) to return to step g.

i Enter thedistinguished name(DN) to be included inthe certificate:This DN is needed ifyou want to configureauthentication.

This DN can contain the following attributes:

• C or country<para>

• ST for state or province</para>

• L or location name</para>

• O for organisation name

• OU for organisational unit

• CN for common name

• EMAIL for the e-mail address

Example: CN=SAA1,OU=department1,O=institution1.

Enter the DN. A check is then performed on the DN.

For a certificate request, this is the last step and now the toolterminates.

j Number of days yourcertificate is valid[default, 30]:

Enter the number of days the certificate can be used. Bydefault 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 thesaa_configconnection tool. For details, see "saa_configconnection" on page 230.

Warning Applying this procedure requires the new certificate to be distributed to the Allianceworkstations configured to use Server Authentication and to Alliance Web Platform.A restart of the Alliance Access server after running the saa_configconnectiontool activates the changes on the server. Clients using Server Authentication (forexample, Alliance Workstation or Alliance Web Platform) must use the oldcertificate until the server restart and the new certificate after the server restart.

Installation

30 September 2011 55

3.4.7.3 Certificate Expiry Management

Description

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

3.4.8 The Alliance Developers Toolkit

Introduction

To enable third parties to develop their own proprietary applications, SWIFT provides a suite ofsoftware known collectively as the Alliance Developers Toolkit.

The objective of the Alliance Developers Toolkit is to make the Alliance Access base servicefacilities 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 thenumber of Alliance Access products available to customers.

This is done by:

• taking advantage of the Alliance Developers Toolkit facilities provided by Alliance Access todevelop new components

• re-using and interacting with existing Alliance Access components (for example, ApplicationInterface (AI), SWIFT Interface (SIA)).

Contents

The Alliance Developers Toolkit contains:

• documented APIs to access the services offered by these facilities. These APIs guaranteeindependence with respect to Alliance Access internal applications.

• a procedure to install components and configure these facilities so that they fit theapplication'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 Accessby:

• 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 likeoperator profiles) to the set of services which they officially claim to require.

Alliance Access 7.0 - Solaris

56 Installation and Administration Guide

3.4.8.1 Delivery Packages

Description

The Alliance Developers Toolkit is delivered as two packages to be installed on top of a versionof Alliance Access supporting the Alliance Developers Toolkit. This is a runtime packageinstalled at customer sites to support components developed with the Alliance DevelopersToolkit, plus a development package used to develop new components with the AllianceDevelopers 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 AllianceDevelopers Toolkit, with the required type definitions, return statuses, and so on.

• a tracing package for debugging purposes

• a tool to create an installation medium (adk_mk_medium)

• example application(s) and example makefiles.

3.4.8.2 Alliance Developers Toolkit Documentation

Description

In-depth documentation on creating an installation medium and the installation of AllianceDevelopers Toolkit components is supplied with the Alliance Developers Toolkit developmentlicense.

3.4.9 Install Alliance Developers Toolkit Third Party SoftwareApplications

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 (forexample, downloading or upgrading, patching, and so on), while the registration procedureintroduces the component to Alliance. This identification is required to allow the component touse the Alliance services.

The following table shows each installation utility:

Domain Utility Description

Software Install a component Initial installation of the software of a newcomponent

Upgrade a component Upgrading the software of an existing componentto a more recent version

Installation

30 September 2011 57

Domain Utility Description

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 existingcomponent

Services Register a component Register to SWA services: either for a newcomponent or for an upgrade

Unregister a component Unregister the component

Note For more information about how to install components, refer to the documentationof your third-party vendor.

Unit assignment to Alliance Developers Toolkit components

When installing Alliance Access with optional package 99:TOOLKIT RUN-TIME licensed, a unitnamed "_ALL_" is defined and is available in the Component view of the Security Definitionapplication (SDA). This unit is assigned by default to the Alliance Developers Toolkitcomponent. When the _ALL_ unit is assigned to a component, no unit restrictions exist for thatAlliance Developers Toolkit component.

Alliance Access 7.0 - Solaris

58 Installation and Administration Guide

4 UpgradeOverview

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 beforeupgrading to 7.0.

If you have Alliance Access 6.2 installed, then you must upgrade to release 6.3 beforeupgrading 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 UpgradeTwo 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 (fromOracle Solaris to Oracle Solaris).

Tip If you are migrating to a new host, then follow the instructions in "Prepare aBackup File for Upgrade" on page 29 before you check the prerequisites in thissection and launch the upgrade.

Important

Ensure that you complete all the upgrade prerequisites. During the upgrade, any prerequisitesthat 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 whichhave not been archived, then the upgrade will quit. In this case, you must start the servers,archive and back up the messages or events, stop the servers, and then restart the upgrade.

Prerequisites

The prerequisites for an upgrade are the same as for a standard installation (for details, see"Prerequisites for the Installation" on page 32). However, there are a number of additionalrequirements:

1. Alliance Access release 6.0 or 6.3 (with latest mandatory patches) must already beinstalled on your system.

Upgrade

30 September 2011 59

2. You must have the necessary Solaris patches available. For details, see the ReleaseLetter.

3. For a silent upgrade, you must prepare the following files:

– a licence file. See "Prepare the Licence File" on page 21.

– a response file. See "Prepare the Response File (for Silent Installation, Upgrade,Relicensing, or Removal)" on page 22.

4. To allow immediate connection of your Alliance Workstations to your Alliance Access 7.0server, we strongly recommend that you ensure that all workstations are installed withAlliance Workstation release 7.0. You cannot connect previous releases of AllianceWorkstation to an Alliance Access 7.0 server.

5. During the upgrade, a copy of your database folder is made in a mig directory in therelease tree. Ensure that the drive where the Alliance release tree is currently installedcontains enough free space for this database copy.

Note After a successful upgrade and after making a backup of your upgradedsystem, you can delete the mig folder to save disk space.

6. From the SWIFT Interface application, Quit and Logout all logical terminals and switch themall to Manual Mode. For details, see the Daily Operations Guide.

7. From the SWIFT Support application, ensure that the latest Message Syntax Table isassigned to the logical terminals that are in use. For details, see the System ManagementGuide.

8. From the Application Interface application, select all the message partners and disablethem.

9. Export RMA authorisations. For details, see "Exporting Authorisations Manually" in theRelationship Management Application User Guide.

Note During the upgrade, RMA authorisations are automatically migrated to the newrelease. This step is only to provide you with a backup in case of problemswith key migration during the upgrade process.

10. Ensure that all message templates have the latest message syntax table assigned andexport 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 withtemplate migration during the upgrade.

If, after the upgrade, message templates cannot be opened or modifiedbecause they are assigned to an earlier message syntax table, then you canexport the message templates and assign the latest message syntax table tothem during the import.

11. Check that no alarms are formatted as MT 999 and generated from event distributions forinternal correspondents. If this is the case, such alarms can generate new live messages inAlliance Access causing the upgrade process to fail as no live messages are allowed inAlliance Access when upgrading. These alarms must be removed before upgrading.

Alliance Access 7.0 - Solaris

60 Installation and Administration Guide

12. To be able to perform the upgrade, it is mandatory to archive:

– all messages from the Message File, if you upgrade from release 6.0. You may have tocomplete some messages manually before you can archive them.

– all messages from the Message File up to the previous day, if you upgrade from release6.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 thecurrent day are migrated.

all Audit Cards.

13. Back up the message archives, journal archives, and any Audit Cards, from the SystemAdministration window. This is mandatory if you want to access your archives on theupgraded system.

Note If you upgrade from release 6.3, then you must back up and remove thearchives of the previous days.

14. Prepare the migration from strict to relaxed certificate mode. See the Release Letter fordetailed instructions.

15. Stop the Alliance Access servers.

16. Before starting the upgrade, it is strongly advised that any existing Alliance Access andassociated database files and archives, are backed up. It is also advisable to back up theoperating system. In addition, it is recommended that you make a backup of the /usr/swainstances registration data.

If the upgrade fails, then you can restore the original software and database, but rememberto restore the original /usr/swa directory (including insts) before you attempt to restart thesystem.

Important If you are upgrading from 6.3, then you should also back up the /var/opt/swiftdirectory before starting the upgrade.

17. Make a note of the $ALLIANCE and $ALLIANCE_DB variables. You may need access tothis information if the upgrade fails. In such a case, you have to re-export these variablesbefore restoring the previous software and database.

Note Ensure that the path to the database is not a symbolic link. You may have toupdate the /usr/swa/insts file temporarily to point to the real directories.

18. During the upgrade, Alliance Access overwrites the existing user environment file .profilefor the Alliance Access administrator account. The existing .profile is saved as .profile.baksuffixed by an incremental number in case it exists.

19. After the upgrade, database recovery is not automatically restarted. If you have activatedthis option, you must deactivate it before the upgrade starts, and reactivate it once theupgrade has been completed. See "Activate the Database Recovery Mode" on page 176for details.

Upgrade

30 September 2011 61

Checklist

Task Reference

The host satisfies the system requirements. "Prepare the System" onpage 15

If upgrading to a new host:

The software owner system account has been created.

The default temp directory has been created. "Create the TemporaryInstallation Directory" onpage 19

If upgrading to a new host:

The backup file from the previous release is available

"Prepare a Backup File forUpgrade" on page 29

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" onpage 63.

To start the upgrade from DVD:

1. Log on as root.

Note It is assumed that the root account will use the Korn shell. See the entry forroot 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.0where <IPaddressComputer> must be replaced by the IP address for the computerwhere the upgrade windows will be displayed.

3. Check that the volume manager vold is running, by typing:

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

root 342 1 80 Oct 16 ? 0:01 /usr/sbin/voldIf this line is not displayed, then start the volume manager by typing:

/etc/init.d/volmgt start

4. Insert the Alliance Access release DVD.

5. Navigate to the following directory in the folder for Alliance Access:

/SunOS/installer

6. Start the upgrade by typing:

./saa-install

Alliance Access 7.0 - Solaris

62 Installation and Administration Guide

To record the upgrade details for future use, run the saa-install command with the -record option. See "Record input parameters" on page 88 for more information.

7. To proceed with the upgrade, follow the steps in "Upgrade Alliance Access Interactively" onpage 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. Share/export this file system on the remote machine as an NFS resource.

4. Mount the remote directory on the local machine.

5. Access the DVD from the local machine using the local name <mountpoint> for the remotedirectory.

For example:

cd /<mountpoint>/SunOS/installer

6. Start the upgrade by typing the following command:

./saa-installTo record the upgrade details for future use, run the saa-install command with the -record option. See "Record input parameters" on page 88 for more information.

4.2.2 Starting the Upgrade From Local Directory

Remote directory

To start the upgrade from a remote directory, see "Upgrading From a Remote Directory" onpage 64.

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 forroot 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.0where <IPaddressComputer> must be replaced by the IP address for the computerwhere the upgrade windows will be displayed.

3. Check that the volume manager vold is running, by typing:

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

root 342 1 80 Oct 16 ? 0:01 /usr/sbin/voldIf this line is not displayed, then start the volume manager by typing:

/etc/init.d/volmgt start

Upgrade

30 September 2011 63

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

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

5. Eject the DVD:

eject

6. Navigate to the following directory in the created install directory:

/SunOS/installer

7. Start the upgrade by typing the following command:

./saa-installTo record the upgrade details for future use, run the saa-install command with the -record option. See "Record input parameters" on page 88 for more information.

8. To proceed with the upgrade, follow the steps in "Upgrade Alliance Access Interactively" onpage 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 mountedcorrectly on the local system. Otherwise, the upgrade fails.

To upgrade from a remote directory:

1. Copy the DVD contents to an NFS directory on the remote machine.

2. Mount this file system on the local machine.

3. Access the directory from the local machine using the local name <mountpoint> for theremote directory.

For example:

cd /<mountpoint>/SunOS/installer

4. Start the upgrade by typing the following command:

./saa-installTo record the upgrade details for future use, run the saa-install command with the -record option. See "Record input parameters" on page 88 for more information.

4.2.3 Upgrade Alliance Access Interactively

Installation event log

Events that occur during upgrade are recorded in the installation.log file, found in the AllianceAccess installation path. In case of upgrade failure, please check this file for the reasons of thefailure.

Alliance Access 7.0 - Solaris

64 Installation and Administration Guide

To upgrade Alliance Access:

1. When the upgrade program starts, it unpacks the files required. Once all the files areunpacked, 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 PreparedBackup 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 FileLocation window appears.

Upgrade

30 September 2011 65

5. Browse to the location of the backup file that you created in "Prepare a Backup File forUpgrade" on page 29. You cannot use a backup file created with Alliance Access Release6.x.

6. Click Next .

The Installation Location window appears.

7. Verify the user account displayed in the Owner field and type the password for thisaccount. 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 allthe 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 minimumoperating system requirements. The test results are saved in the software installationdirectory, in the file:

installation_systemcheck_yymmdd_hhmmss.html

where yymmdd and hhmmss are the date and time of the upgrade.

If you selected the Upgrade option, then a message appears, reminding you to takeAlliance Access environment (software, database, and archives) and system backups.

If you have taken these backups, then click Next . Otherwise, click Cancel to quit theupgrade process. Take the necessary backups, and then repeat this procedure.

The Packages Configuration window appears.

Alliance Access 7.0 - Solaris

66 Installation and Administration Guide

This window is used to license the packages and features that your institution haspurchased from SWIFT. The pre-selected packages are part of the base licence andinclude 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 SystemConfiguration Test Results window displays information about the problemsthat were detected.

• Problems reported as Warning do not prevent you from continuing theupgrade, 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. Thisis the licence file that you prepared in "Prepare the Licence File" on page 21.

Then click Next and proceed to step 16.

11. Verify that all the items listed in the Packages section of your licensing agreement areselected. Then click Next .

Note You may want to license additional component packages or 'disable' selectedcomponent packages after the upgrade is finished. To do this, you canrelicense Alliance Access using a new licensing agreement. You do not haveto reinstall. For more information, see "Relicensing" on page 77.

Upgrade

30 September 2011 67

12. The Servers Configuration window appears.

Verify that all the items listed in the Servers section of your licensing agreement areselected. Then click Next .

13. The Licensed Destinations Configuration window appears, showing the destinationsalready 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 andtraining. Although the test and training destination does not appear on your licensingagreement, 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 alreadylicensed 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 messagetypes, click Next .

The Initialisation Password Configuration window appears.

Alliance Access 7.0 - Solaris

68 Installation and Administration Guide

16. Enter the initialisation passwords as follows:

• The Security Officer who received the INITIALISATION PASSWORD provided in Part 1of 2 of the licensing agreement must type this password in the First initialisationpassword field.

• The Security Officer who received the INITIALISATION PASSWORD provided in Part 2of 2 of the licensing agreement must type this password in the Second initialisationpassword field.

Note Do not confuse the Initialisation Passwords with the Master Passwords. TheMaster Passwords are used by the two Security Officers when they first signon to Alliance Access.

17. Click Next .

If the password verification fails, then an error message appears. Click OK and enter thecorrect 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 Accesssystem.

Instance Comment The description of the instance.

19. Click Next .

If you upgrade from Alliance Access or Alliance RMA 6.3, then the Temporary locationwindow appears. This window shows the default temporary directory that will be usedduring 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 theDirectory Name field. Type the directory name or click Browse to select a directory.

Upgrade

30 September 2011 69

21. Click Next .

The Installation Summary window appears.

22. Check that the details displayed are correct, and if so, click Install . Once you click Install , itis not possible to abort the software upgrade. If the details are not correct, click Previous toreturn to the previous screen(s) and make your corrections.

The software upgrade begins. You can monitor the progress of the upgrade throughvarious windows, for instance while Alliance Access copies files.

At the end of the software upgrade, the Installation Complete window appears, confirminga successful upgrade.

The window provides information about the port configuration. For more information aboutport configuration, see "TCP Configuration for the Alliance Access Server" on page 243.

23. Click Finish to complete the upgrade.

Note Once the upgrade has completed successfully, if you have upgraded fromDVD, remove the DVD as follows:

1. Check if the volume manager vold is running by typing:

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

root 342 1 80 Oct 16 ? 0:01 /usr/sbin/voldIf vold is not running, restart it by typing:

/etc/init.d/volmgt start

2. To remove the DVD, type:

cd ~ejectIf this command returns the error Device is busy, this means thatthere is some process still using the DVD software. This is probably theSystem Administration application itself. Quit the System Administrationwindow and run the following in the controlling x-term:

cd /Try again to eject the DVD.

24. Perform the post-upgrade steps described in the Release Letter. Then follow theinstructions in "Post-Upgrade Checklist" on page 74.

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 prerequisitesthat have not been fulfilled (and would make the upgrade fail), are reported one by one.

Alliance Access 7.0 - Solaris

70 Installation and Administration Guide

For example, the upgrade would be interrupted because there are still live messages in thedatabase. You will have to start the servers, archive and back up the messages, stop theservers and restart the upgrade. Then it could be interrupted because there are still events fromyesterday 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" onpage 72.

To start the upgrade process from DVD:

1. Log on as root.

Note It is assumed that the root account will use the Korn shell. See the entry forroot 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.0where <IPaddressComputer> must be replaced by the IP address for the computerwhere the upgrade windows will be displayed.

3. Check that the volume manager vold is running, by typing:

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

root 342 1 80 Oct 16 ? 0:01 /usr/sbin/voldIf this line is not displayed, then start the volume manager by typing:

/etc/init.d/volmgt start

4. Insert the Alliance Access release DVD.

5. Navigate to the following directory in the folder for Alliance Access:

/SunOS/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 havebeen encrypted.

7. Perform the post-upgrade steps described in the Release Letter. Then follow theinstructions in "Next Steps" on page 74.

Viewing the silent upgrade progress or result

The installation log file is updated during a silent upgrade. You can view the log to see theprogress of the silent upgrade, or the result if the silent upgrade operation has ended.

Upgrade

30 September 2011 71

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. Share/export this file system on the remote machine as an NFS resource.

4. Mount the remote directory on the local machine.

5. Finally, access the DVD from the local machine using the local name <mountpoint> for theremote directory.

For example:

cd /<mountpoint>/SunOS/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 havebeen encrypted.

7. Perform the post-upgrade steps described in the Release Letter. Then follow theinstructions in "Next Steps" on page 74.

Viewing the silent upgrade progress or result

The installation log file is updated during a silent upgrade. You can view the log to see theprogress 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 prerequisitesthat 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 thedatabase. You have to start the servers, archive and back up the messages, stop the serversand restart the upgrade. Then it could be interrupted because the latest Message Syntax Tablehas 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" onpage 73.

To start the upgrade process:

1. Log on as root. It is assumed that the root account will use the Korn shell. See the entry forroot in the /etc/passwd file.

Alliance Access 7.0 - Solaris

72 Installation and Administration Guide

2. If you are working remotely, then export the display to your local machine by typing:

export DISPLAY=<IPaddressComputer>:0.0where <IPaddressComputer> must be replaced by the IP address for the computerwhere the upgrade windows will be displayed.

3. Check that the volume manager vold is running, by typing:

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

root 342 1 80 Oct 16 ? 0:01 /usr/sbin/voldIf this line is not displayed, then start the volume manager by typing:

/etc/init.d/volmgt start

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

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

5. Eject the DVD:

eject

6. Navigate to the following directory in the created install directory:

/SunOS/installer

7. 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 havebeen encrypted.

8. Perform the post-upgrade steps described in the Release Letter. Then follow theinstructions in "Next Steps" on page 74.

Viewing the silent upgrade progress or result

The installation log file is updated during a silent upgrade. You can view the log to see theprogress 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 mountedcorrectly on the local system. Otherwise, the upgrade fails.

Upgrade

30 September 2011 73

To upgrade from a remote directory:

1. Copy the DVD contents to an NFS directory on the remote machine.

2. Mount this file system on the local machine.

3. Access the directory from the local machine using the local name <mountpoint> for theremote directory.

For example:

cd /<mountpoint>/SunOS/installer

4. 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 havebeen encrypted.

5. Perform the post-upgrade steps described in the Release Letter. Then follow theinstructions in "Next Steps" on page 74.

Viewing the silent upgrade progress or result

The installation log file is updated during a silent upgrade. You can view the log to see theprogress 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 performedon Alliance Gateway by the Alliance Gateway instance owner. See the Release Letter fordetailed 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 takenfrom 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 ofreconnecting (following an interrupted session) when Alliance Access was stoppedbefore the upgrade, then it is possible that messages will be missed at the next login/

Alliance Access 7.0 - Solaris

74 Installation and Administration Guide

select attempt. In such a case, events relating to OSN gaps are present in the eventjournal.

6. The previous Alliance Administrator account environment file .profile is savedas .profile.bak.

If you want to reinstate it, then log on as system administrator, start an X-term window fromAlliance Access and type:

cd~mv .profile .profile.inst (saves the new profile)mv .profile.bak .profile (re-installs the old profile)exit

7. Open the Application Interface application and check and enable each required messagepartner. For details, see "Managing Message Partner Profiles" in the System ManagementGuide.

8. Alliance Developers Toolkit (ADK) licence only: all ADK applications used with AllianceAccess 6.0, 6.2, or 6.3 have to be recompiled, rebuilt and re-installed before they can beused 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 defaultprofiles are created with an "R7.0" prefix. The user can select to use the new profiles orkeep the migrated ones. The new applications and/or functions are not added to themigrated profiles.

10. If you have to access your old message archives and journal archives, then restore abackup of the previously backed up archives from the System Management application. Asarchives are part of the database, this is the only way to access archives from previousreleases.

11. Not required for stand-alone Alliance Access:

Check Part B, "Configuring for SWIFTNet" on page 97 and follow any procedures that areapplicable to your upgraded system (for example MX Messaging).

12. If you deactivated database recovery before the upgrade, then reactivate it now. See"Activate the Database Recovery Mode" on page 176 for details.

4.4.2 Additional Tasks after a Non-root Upgrade

Procedure

After the upgrade of Alliance Access by a UNIX account without root privileges, the followingtasks 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.kshThe script:

• runs the RPCConfiguration.ksh script which creates the /usr/swa directory, and addsfiles to it.

• updates the Alliance Access instances in /usr/swa/insts.

Upgrade

30 September 2011 75

• runs the apply_alliance_ports script which configures the Alliance ports in /etc/services.

• copies the installation registry entry (a file generated in the installation directory duringinstallation) 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 highestrelease number.

Alliance Access 7.0 - Solaris

76 Installation and Administration Guide

5 RelicensingIntroduction

This section explains how to add or remove packages and features that your institution canpurchase from SWIFT.

5.1 Before You RelicenseCommon prerequisites

Before relicensing, ensure that:

• all passwords and licence-related information is available. You can get this information usingSecure Channel. For more information about Secure Channel, see "Secure Channel" onpage 11.

• both Alliance Access Security Officers (or their deputies) are present, unless you are loadingyour 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 Administrationwindow, double-click the Stop Alliance icon.

• you check the integrity of your existing Alliance Access software. See "Checking the AllianceAccess Software Files" on page 234 and "The Software Integrity Report" on page 96 fordetails.

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 orencrypted. See "Prepare the Licence File" on page 21.

– a response file. See "Prepare the Response File (for Silent Installation, Upgrade,Relicensing, or Removal)" on page 22.

Prerequisites for Destination and Package Removal

Before removing destinations or packages, read the following table and perform the tasks if theyapply to your Alliance Access installation.

Licensed options Required task

Licensed destinations If the new licensing contains fewer destinations, then the unwanteddestinations are removed. Before relicensing, ensure that no unwanteddestination is referenced by:

• configuration parameters

• operator profiles

• message templates

• message file search templates

Relicensing

30 September 2011 77

Licensed options Required task

• routing rules

Application interface A message partner with Session Direction 'To' can only be removed whenthere are no Exit Points assigned to it. If this is the case, first de-assign theExit Points and then remove the message partner.

Packages 14:DATABASE RECOVERY Deactivate the database recovery mode.

16:FILE AUTOMATED No action required. Print message partnersare not affected. Note that automatedmessage partners are changed to manual.

18:CAS TCP-IP Remove all message partners that use TCP/IP. If not removed, then they are disabled.

5.2 Interactive RelicensingOverview

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-relicenseTo record the relicensing details for future use, run the relicense command with the -record option. See "Record input parameters" on page 88 for more information.

4. The installation application unpacks the files in the installer.

The Packages Configuration window appears.

Alliance Access 7.0 - Solaris

78 Installation and Administration Guide

This window is used to license the packages and features that your institution haspurchased from SWIFT. The pre-selected packages are part of the base licence andinclude 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. Thisis the licence file that you prepared in "Prepare the Licence File" on page 21.

Then click Next and proceed to step 11.

6. Select the licensed components, using the items listed in the Packages section of yourlicensing agreement. Then click Next .

7. The Servers Configuration window appears.

8. Select the licensed components, using the items listed in the Servers section of yourlicensing agreement. Then click Next .

The Licensed Destinations Configuration window appears, showing the destinationsalready licensed on your Alliance Access system.

9. In this window, type:

• the eight characters of any new live destination(s) listed in the Licensed Destinationssection of your licensing agreement

• the 8-character training destinations. The eighth character is a ''0'' to denote test andtraining. Although the test and training destination does not appear on your licensingagreement, 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 alreadylicensed on your Alliance Access system.

Relicensing

30 September 2011 79

10. In this window, type any new message types listed in the Message Types section of yourlicensing agreement.

Each message type must be on a separate line. Once you have typed all your messagetypes, 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 1of 2 of the licensing agreement must type this password in the First initialisationpassword field.

• The Security Officer who received the INITIALISATION PASSWORD provided in Part 2of 2 of the licensing agreement must type this password in the Second initialisationpassword field.

Note Do not confuse the Initialisation Passwords with the Master Passwords. Theseare used by the two Security Officers when they first sign on to AllianceAccess.

12. Click Next .

If the password verification fails, then an error message appears. Click OK and enter thecorrect input.

The Installation Summary window appears.

13. Check that the details displayed are correct, and if so, click Install . Once you click Install , itis 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 hascompleted successfully.

14. Click Finish .

15. Proceed to "Next Steps" on page 81.

Alliance Access 7.0 - Solaris

80 Installation and Administration Guide

5.3 Silent RelicensingOverview

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. Enter the following command: cd $ALLIANCE/INA/bin/$ARCH

5. Enter the following command:

./saa-relicense -silent <response file> [-key <value>]Where:

• <response file> identifies the path to and name of the properties file to be used. Forexample:

/tmp/alliance/silent.properties.relicensing-key <value> specifies the key to use if the response file has encrypted passwords.

Viewing the silent relicensing progress or result

The installation log file is updated during silent relicensing. You can view the log to see theprogress of the relicensing, or the result if the relicensing operation has ended.

5.4 Next StepsTasks 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 SystemManagement application still point to the removed destination(s) (forexample, the Sender Logical Terminal for Alarm Messages). Ifnecessary, redefine these configuration parameters to point to validlicensed destinations.

• open the Correspondent Information application and add a newdestination with the "External" definition if required for the removeddestination.

• if you have scheduled the automatic import of authorisations fromthese destinations, then you must modify the action to removethese destinations. For details, see the Relationship ManagementApplication User Guide.

Relicensing

30 September 2011 81

Licensed Options Required task

• remove the emission profiles, reception profiles, input channels,and output channels related to these destinations.

Application interface If necessary, redefine message partners using licensed protocols andcheck that the message partners work properly.

Operator profiles

After relicensing, review the operator profiles and remove any functions or permissions relatedto the down-licensed options, and then approve the operators assigned to these profiles.

Alliance Access 7.0 - Solaris

82 Installation and Administration Guide

6 RemovalIntroduction

Should it ever be necessary to remove Alliance Access instances and software from yoursystem (for example, due to an error during installation), the Alliance administrator can removeAlliance Access files using the following procedure.

Hosted database

If you uninstall an instance of Alliance Access that uses a hosted database, then the AllianceAccess database is not removed. In this case, the customer must remove the Alliance Accessdatabase from the Oracle database instance where it is installed. A hosted database requiresthe license, 13:HOSTED DATABASE.

6.1 Before You RemoveRemoval 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 AllianceAccess 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 RemovalProcedure

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.0where <IPaddressComputer> must be replaced by the IP address for the computerwhere the uninstallation windows will be displayed.

4. At the command prompt, use the following change directory command to locate thedirectory that contains the Alliance Access application:

cd <Alliance installation directory>where <Alliance installation directory> is the name of the directory whereAlliance Access is installed.

5. Start the removal process by typing:

_uninst/uninstallThe Uninstaller window appears.

6. Click Next to proceed, or Cancel to terminate the process.

Removal

30 September 2011 83

A warning prompts you to confirm the removal.

7. Click Yes to remove the software, or No to terminate the process.

After you click Yes , the removal of the software starts. When the process is complete, awindow appears to confirm that the software was removed successfully.

8. Click Finish .

9. Reboot your system.

6.3 Silent RemovalPrerequisites

Before removing Alliance Access, ensure that:

• you have prepared the requisite response file.

For complete removal, the response file must contain system.deinstallOption=base.See "Prepare the Response File (for Silent Installation, Upgrade, Relicensing, or Removal)"on page 22.

• the Alliance Access servers are stopped.

Procedure

1. 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.0where <IPaddressComputer> must be replaced by the IP address for the computerwhere the uninstallation windows will be displayed.

4. At the command prompt, use the following change directory command to locate thedirectory that contains the Alliance Access application:

cd <Alliance installation directory>where <Alliance installation directory> is the name of the directory whereAlliance Access is installed.

5. Start the removal process by typing:

_uninst/uninstall -silent <response file>Where <response file> identifies the path to and name of the properties file to be used.

6. Reboot your system.

Alliance Access 7.0 - Solaris

84 Installation and Administration Guide

7 PatchesOverview

Software fixes are applied in the form of patches. This section explains how to install andremove 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 patchincludes the previous cumulative patch and any optional patches issued after the previouscumulative patch.

• "Optional (emergency) patches", which are sent to selected Alliance Access users and whichaffect specific deliverables, such as executables and library files. Optional patches do notinclude any previous patches.

Patches can be downloaded from the Download Centre on www.swift.com.

7.1 InstallationPrerequisites

Before installing a patch, you must:

1. read the patch release letter carefully. It describes the scope of the patch and theinstallation 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)" onpage 22.

5. log on as the user who installed Alliance Access, unless specified otherwise in the releaseletter.

For cumulative patches:

• A cumulative patch can be installed on a base release, on a previous cumulative patch or ona previous optional patch. A cumulative patch contains all cumulative and optional patchessince the base release.

For optional (emergency) patches:

• An optional patch can be installed on a base release, on a previous cumulative patch or on aprevious optional patch. Optional patches must be installed in the order of increasing level

Patches

30 September 2011 85

number. Removing an optional patch restores the previous version of the affecteddeliverables.

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 installationsoftware to be restored when the patch is removed.

7.2 RemovalCan the patch be removed?

Not all patches can be removed. See the patch release letter for specific information aboutpatch 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 containsystem.deinstallOption=delta. For more information, see "Prepare the ResponseFile (for Silent Installation, Upgrade, Relicensing, or Removal)" on page 22.

Note that cumulative patches cannot be removed with this method.

3. log on as the user who installed Alliance Access, unless specified otherwise in the releaseletter.

Alliance Access 7.0 - Solaris

86 Installation and Administration Guide

8 Additional Information

8.1 Non-root Installation or UpgradePurpose

It is possible to install, patch, or upgrade the Alliance Access software with a non-root useraccount, such as, all_adm. The non-root user account will own the installation, and become theAlliance administrator.

A non-root user logs on using the owner account of Alliance Access and launches the installerto begin the installation. Before you can launch the installation with a non-root user account, youmust 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 moreinformation, see "Prepare for Non-root Installation, Upgrade, Backup, or Removal" onpage 20.

For example, to install Alliance Access on Oracle Solaris, the root user must perform somepreliminary tasks to prepare for the installation by a non-root user.

2. A non-root user logs on using the owner account of Alliance Access and launches theinstaller to begin the installation.

3. Complete any post-installation or post-upgrade tasks. For more information, see "AdditionalTasks after a Non-root Installation" on page 50 or "Additional Tasks after a Non-rootUpgrade" on page 75.

Checkhost

If a non-root user account runs the installation, then some of the checkhost checks may failbecause of the privileges associated to the account. Typically, these will be warnings. Thecheckhost report will include information about any such failures.

8.2 Silent ModeDifference 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 silentoperation, the data is provided in response files and licence files. For more information, see"Response Files" on page 88.

Benefits

Silent operations have the following benefits:

• Do not require firewall administrators to open many ports to support the X-Display necessaryfor a GUI. This makes it easier and more secure to connect to remote servers or serversbehind a firewall.

• Simplify the repetition of an operation over several instances of the same product, by reusingthe response files after editing them.

Additional Information

30 September 2011 87

• Allow for the segregation of duties: operations managers can prepare the response files inadvance, and the operation can be scripted or carried out by other people of the organisation.

Silent operations are as secure as interactive operations. Any passwords can be madeunreadable in the response file. For more information, see "Protect the Passwords in theResponse File" on page 23.

Scope

The following Alliance Access operations can be performed silently:

• Installation

• Upgrade

• Removal

• Patch installation

• Patch removal

• Relicensing

Viewing the silent operation progress and result

The installation log file is updated during a silent operation. You can view the log to see theprogress 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 youmust 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 "Recordinput parameters" on page 88.

• modify the sample response file that is provided on the release media. See "Prepare theResponse File (for Silent Installation, Upgrade, Relicensing, or Removal)" on page 22.

• modify an existing response file, which you created previously during installation, upgrade,relicensing, or removal.

The release media contains sample response files (with extension .properties).

Record input parameters

If the -record option is provided as an option during installation, upgrade, relicensing, orremoval, then the program will:

• create a response file in the location specified.

Alliance Access 7.0 - Solaris

88 Installation and Administration Guide

The response file has a name that ends with .properties and the Licence File has a namethat ends with .properties.lic. The license file is created in the same location as theresponse file. For more information, see "Prepare the Licence File" on page 21.

If a file of the same name already exists, then it is overwritten.

• record the parameters as they are input and store them as values of the correspondingsystem parameters, in the newly created response file. The parameters are storedalphabetically 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" onpage 93.

• When any password is entered (left and right initialisation passwords, system password),they are encrypted or obfuscated before being stored in the response file.

The syntax for the -record option is as in the following example:

saa-install -record <response file> [-key <value>]Where:

• <response file> identifies the path to and name of the file to be used to record theparameters.

• -key <value>, if used, indicates that the passwords in the response file will be encryptedwith the provided encryption key. If this parameter is omitted, then the passwords will beobfuscated.

8.2.1.2 Response File Parameters

Purpose

This section describes the possible parameters and indicates their applicability in installation-related 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 inthe response file. The parameters that end with .encrypted must be used to provideencrypted or obfuscated values only. For more information, see "Protect the Passwords in theResponse File" on page 23.

Additional Information

30 September 2011 89

Response file parameters

The following table lists the parameters that must be defined in the response file for AllianceAccess:

Parameter name Description Inst

alla

tio

n

Up

gra

de

Rel

icen

sin

g

Rem

ova

l

Pat

ch in

stal

lati

on

Pat

ch r

emo

val

system.installOption Install type

Use base (installation), ordelta (upgrade).

M M - - - -

system.deinstallOption Uninstall type

Use base (full systemremoval), or delta (patchremoval).

- - - M - M

application.key A keyword that identifies theproduct.

Use saa (upgrade fromAlliance Access), or sar(upgrade from Alliance RMA).

M M - - M -

Mandatory.Accept.LicensingTerms

Licensing agreement. Musthave the value: Agree

M M - - M -

application.installLocation Installation directory(1) M M(2)

- - M(2)

-

application.owner.name Operating system account thatis the owner of the resultinginstance. For example,all_admThe operating system accountthat is used to install theinstance. The name can bepreceded by the domain name.

C - - - - -

application.ipAddress IP address of the machinewhere the instance exists

C C - - - -

application.instanceName Instance name

For example: AccessC - - - - -

application.instanceComment Instance comment C C - - - -

licence.left.passwordlicence.left.password.encrypted

Left Initial password.

You can only use one of thetwo parameters in a responsefile.

C C M - - -

licence.right.passwordlicence.right.password.encrypted

Right Initial password.

You can only use one of thetwo parameters in a responsefile.

C C M - - -

database.type Type of database M - - - - -

Alliance Access 7.0 - Solaris

90 Installation and Administration Guide

Parameter name Description Inst

alla

tio

n

Up

gra

de

Rel

icen

sin

g

Rem

ova

l

Pat

ch in

stal

lati

on

Pat

ch r

emo

val

installer.delta.tmpdir Temporary directory for thedatabase upgrade

- M(3)

- - - -

upgrade.deleteAuditCards Delete audit cards

Use the value:

true - delete audit cards

false - cancel the upgrade

- M - - - -

(1) For example, <system_drive>:/Alliance/Access (upgrade from Alliance Access) or <system_drive>:/Alliance/RMA (upgrade from Alliance RMA).

(2) In this case, the directory location also specifies the location of the Installation Log file.

(3) If there is not enough space in the default directory, then the temporary directory for the database upgrade will be

used.

Hosted database - additional installation options

When Alliance Access is installed onto an external Oracle instance, then the following additionalparameters are required in the response file. These parameters relate to the configuration of theAlliance Access database in the external Oracle instance:

Parameter name Description Inst

alla

tio

n

Rel

icen

sin

g

Rem

ova

l

Pat

ch in

stal

lati

on

Pat

ch r

emo

val

oracle.listener.host Host name or IP address ofserver which hosts the Oracleinstance.

C - - - -

oracle.listener.port Port number used to connect tothe Oracle instance.(1)

If not defined, then the defaultport number is used: 1521

C - - - -

oracle.sid Oracle service ID of the Oracleinstance.

C - - - -

database.tablespace.data.name The tablespace from thedatabase where tables thathold the Alliance Accessconfiguration data will becreated.

For example: SAA_DATA

C - - - -

database.tablespace.event.name The tablespace from thedatabase where tables thathold the Alliance Accessevents will be created.

C - - - -

Additional Information

30 September 2011 91

Parameter name Description Inst

alla

tio

n

Rel

icen

sin

g

Rem

ova

l

Pat

ch in

stal

lati

on

Pat

ch r

emo

val

For example: SAA_JRNL

database.tablespace.message.name The tablespace from thedatabase where tables thathold theAlliance Accessmessages will be created.

For example: SAA_MESG

C - - - -

database.tablespace.file.name The tablespace from thedatabase where tables thathold the Alliance AccessFileAct payloads will becreated.

For example: SAA_FILE

C - - - -

database.tablespace.temp.name The tablespace from thedatabase where tables will becreated to hold the AllianceAccess restored data.

For example: SAA_TEMP

C - - - -

database.temporary.schema.name Database temporary schemaowner name

C - - - -

database.temporary.schema.passworddatabase.temporary.schema.password.encrypted

Password for the temporarydatabase schema owner.

You can only use one of thetwo parameters in a responsefile.

C - - - -

database.schema.name Database schema ownername(1)

C - - - -

database.schema.passworddatabase.schema.password.encrypted

Password for the databaseschema owner.

You can only use one of thetwo parameters in a responsefile.

C - - - -

database.user.name Database user name to beused by the Alliance Accessserver to connect to thedatabase(1)

C - - - -

database.user.passworddatabase.user.password.encrypted

Password for the databaseuser name.

You can only use one of thetwo parameters in a responsefile.(1)

C - - - -

(1) You can use the saa_dbpwdutil command to change the value of this parameter.

Alliance Access 7.0 - Solaris

92 Installation and Administration Guide

8.3 Licence Files for Alliance AccessInput Licence File

During an interactive installation, upgrade, or relicensing of Alliance Access, you can choose touse 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 InputLicence Files can be built as a result of a Secure Channel download. For more informationabout Secure Channel, see "Secure Channel" on page 11.

By using the -record option during an interactive installation, upgrade, or relicensing, you canalso 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 Fileprovides the data about the Package and Server licences, Destinations, and MTs.

For more information about Response Files, see "Response Files" on page 88.

Name of Input Licence File

If the file name of the Response File is filename.prop, then the file name of the associatedInput Licence File must be filename.prop.lic.

Both files must be in the same directory.

For more information about preparing Licence Files, see "Prepare the Licence File" on page 21.

8.4 Checking Your System ConfigurationUses of the checkhost tool

You can use the checkhost tool provided on the release media to analyse the configuration ofa 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 minimumrequirements provided in a requirements file.

The checkhost tool is integrated in the Alliance Access installer as well and provides an on-screen 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 SunOS directory.

Additional Information

30 September 2011 93

5. Locate the checkhost tool by typing:

#cd <Mount point CD>/SunOS/checkhost

6. Launch the checkhost tool.

8.4.2 checkhost Syntax and Examples

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 checkhosttool must perform a disk space validation.

-out a location for the report file. If not used, then the report isproduced 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 diskspace 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 followingreport details are produced:

Information Unit

Checkhost command invoked

CPU type

CPU speed MHz

Number of CPUs

Memory size(1) MB

Alliance Access 7.0 - Solaris

94 Installation and Administration Guide

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 requirementscriteria in a requirements file.

Performing a comparative analysis before a software installation ensures that the intended hostmachine meets the requirements.

Requirements file

The access.dat file is found on the release DVD, in the SunOS/installer folder. It contains thebase 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 fromhanging while the checkhost tool queries the operating system. The checkhost tool displaysthis message against each report detail for which property information is not received withinthe timeout period.

Additional Information

30 September 2011 95

Patch level warnings and errors

When it is run to check minimum requirements, the OS patch level check can generate Warningerrors. This means that the patch is either at a higher or lower level than the requirement, or notpresent. Some errors are reported as Fatal, which means that it is highly recommended toadjust the patch level to the requirements. Failure to do so can cause unexpected Alliancebehaviour.

Example

Installed patches-----------------Warning: patch too HIGH : patch 'IMNSearch.bld.DBCS' must be installed with level '2.3.1.15' instead of '2.4.0.0'.Warning: patch too HIGH : patch 'IMNSearch.bld.SBCS' must be installed with level '2.3.1.15' instead of '2.4.0.0'.

8.5 The Software Integrity ReportSoftware integrity verification

The integrity of the Alliance Access software is checked by the Integrity Verification Tool (IVT).

The installation log file that is produced during the installation, upgrade, and patch operationsprovides details about the generation of the software integrity report and the result of thesoftware integrity check.

The security parameter, Software Check At Startup, controls whether the Integrity VerificationTool is run each time that Alliance Access is started.

You can also generate the Software Integrity report at any time, using thesaa_system integrity command. as described in "Checking the Alliance Access SoftwareFiles" on page 234.

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 softwarefiles of Alliance Access.

• Before software upgrade (fromrelease 7.0 onwards)

• Before patch installation

• Before relicensing

Partial A report is produced for specific softwarefiles (.exe, .dll) of Alliance Access.

Before starting the Alliance Accessservers.

Related information

System Management Guide, Security Parameters

Alliance Access 7.0 - Solaris

96 Installation and Administration Guide

Part B

Configuring for SWIFTNet

Part B - Configuring for SWIFTNet

30 September 2011 97

Alliance Access 7.0 - Solaris

98 Installation and Administration Guide

9 IntroductionPurpose

This section describes the steps to complete before you can send and receive FIN, InterAct,and FileAct messages.

Prerequisites

Before performing the steps in this section, the following must be completed:

• Connectivity setup. For details, see "Check Connectivity" on page 100.

• SWIFTNet Link 7.0 is installed and configured on the system hosting Alliance Gateway.

• You have installed or upgraded to Alliance Gateway 7.0.

• You have set up valid certificates for an Authoriser DN.

Tasks related to the management of certificates are performed on Alliance Gateway. Formore information, see the Alliance Gateway Operations Guide.

• You have installed or upgraded to Alliance Access 7.0. For details, see Part C, "SystemAdministration" on page 113.

Configuration tasks

The main tasks are:

• Checking connectivity

• Defining Alliance Access in Alliance Gateway

• Configuring Alliance Access for FIN messaging

• Configuring Alliance Access for InterAct and FileAct messaging.

Introduction

30 September 2011 99

10 Check Connectivity

10.1 Configure SWIFT DNS ServersDescription

Before you can use your connection correctly, ensure that you have access to the SWIFT DNSservers. For details of configuring the SWIFT DNS servers, see the SWIFTNet Link InstallationGuide.

Note To configure the DNS, you do not need the SNLOwner Account. You can use theroot account.

10.2 Confirm ConnectivityDescription

You must ensure that the host computer can successfully reach the necessary ports on theSWIFT systems. The ports that must be accessible are defined in the SWIFTNet NetworkConfiguration Tables Guide.

Before proceeding with the SWIFTNet Link installation, confirm your Network Connectivity byexecuting the checkip program, as explained in the SWIFTNet Link Installation Guide,"Checking the TCP/IP Network Configuration". This program contacts all necessary ports andchecks whether they are open and can be reached.

If this connectivity test is not successful, then the next step (SWIFTNet Link installation) will fail.

Alliance Access 7.0 - Solaris

100 Installation and Administration Guide

11 Defining Alliance Access in AllianceGateway

Overview

This section explains how to:

• set up Alliance Access as a message partner in Alliance Gateway, with Relaxed SNLFormat selected

• define Alliance Access as an endpoint on Alliance Gateway.

These steps are similar whether you are configuring for FIN, InterAct, or FileAct messaging.Only the message partner and endpoint names differ.

11.1 Guidelines for NamesMessage partner names

When Alliance Access connects to an Alliance Gateway system, it must provide a uniquemessage partner name. The Alliance Access message partner name is derived from its instancename.

Alliance Access creates the message partner name with the characters fin_ (for FINmessaging), or sni_ (for InterAct and FileAct messaging) followed by a normalised AllianceAccess instance name.

A normalised Alliance Access instance name is the Alliance Access instance name, reduced tolower case with underscores removed and truncated to 10 characters. The name can have amaximum of 14 characters.

For example, if the Alliance Access instance name is SAA_Rel_70, then the message partnername must be fin_saarel70 (for FIN messaging), or sni_saarel70 (for InterAct and FileActmessaging).

Note If you have multiple Alliance Access systems connecting to SWIFTNet throughAlliance 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. AllianceAccess 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 Gatewaysystem.

Defining Alliance Access in Alliance Gateway

30 September 2011 101

Note • If you have performed a fresh installation of Alliance Gateway 7.0 on yoursystem, then a default message partner called fin_relaxed is provided. Thismessage partner has the correct settings for connection between AllianceAccess and Alliance Gateway. You can use the settings of this message partneras an example to create your fin_<your_instance_name> message partner.

• You must select Relaxed SNL Format as default message format for emissionand reception.

To set up a message partner for FIN messaging

Add a new message partner as described in the Alliance Gateway Operations Guide, "Creatinga Client/Server Message Partner", with the following details:

1. For the message partner and SWIFTNet Link Endpoint, enter a Name. Enter a uniquemessage partner name based on the Alliance Access instance name. See "Guidelines forNames" on page 101.

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, selectRelaxed SNL Format.

5. In the Supported Message Formats section, select Relaxed SNL Format. Move it fromthe 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 LocalAuthentication, 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 AllianceGateway

Overview

When data arrives from SWIFTNet into Alliance Gateway, it has the Endpoint name embeddedin the data. Alliance Gateway must know how to route this data to the correct Alliance Accesssystem.

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 beused by the Endpoint.

If you have performed a fresh installation of Alliance Gateway 7.0 on your system,then a default Endpoint called fin_relaxed is provided. You can use the settings ofthis endpoint as an example to create your fin_<your_instance_name>endpoint.

Alliance Access 7.0 - Solaris

102 Installation and Administration Guide

To define an Endpoint

Add a new Endpoint as described in the Alliance Gateway Operations Guide, "Adding anEndpoint", with the following details:

1. In the Routing tab:

• in the Name field, enter the message partner name that you defined in "Setting Up aMessage Partner in Alliance Gateway" on page 101.

• in the SNL Endpoint field, select Equals (=) in the Relation subfield and the messagepartner name that you defined in "Setting Up a Message Partner in Alliance Gateway" onpage 101, in the second subfield.

• in the Traffic Type field, select All.

2. In the Destination tab:

• in the Interface field, select Application Interface.

• in the Application field, select the message partner name that you defined in "SettingUp a Message Partner in Alliance Gateway" on page 103.

• from the Mode option buttons, select Relaxed.

• from the Cryptographic protocol option buttons, select Advanced.

• the Namespace Declarations check box must not be selected.

• in the Error Code field, select Old.

3. Save this configuration.

4. Finally, enable the Endpoint. See the Alliance Gateway Operations Guide, "Enabling andDisabling an Endpoint".

11.3 InterAct and FileAct Messaging

11.3.1 Setting Up a Message Partner in Alliance Gateway

Overview

For InterAct and FileAct messaging, you must also configure Alliance Access as an additionalmessage partner in Alliance Gateway. This must be completed for each Alliance Access systemthat connects to this Alliance Gateway system.

Note • The message partner definition for the SWIFTNet Interface component (forInterAct and FileAct messaging) also follows a defined naming convention. Themessage 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 emissionand reception.

Defining Alliance Access in Alliance Gateway

30 September 2011 103

To set up a message partner for InterAct and FileAct messaging

Add a new message partner as described in the Alliance Gateway Operations Guide, "Creatinga Client/Server Message Partner", with the following details:

1. For the message partner and SWIFTNet Link Endpoint, enter a Name. Enter a uniquemessage partner name based on the Alliance Access instance name. See "Guidelines forNames" on page 101.

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, selectRelaxed SNL Format.

5. In the Supported Message Formats section, select Relaxed SNL Format. Move it fromthe 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 LocalAuthentication, 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 AllianceGateway

Overview

When data arrives from SWIFTNet into Alliance Gateway, it has the Endpoint name embeddedin 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 beused by the Endpoint.

To define an Endpoint

Add a new Endpoint as described in the Alliance Gateway Operations Guide, "Adding anEndpoint", with the following details:

1. In the Routing tab:

• in the Name field, enter the message partner name that you defined in "Setting Up aMessage Partner in Alliance Gateway" on page 103.

• in the SNL Endpoint field, select Equals (=) in the Relation subfield and the messagepartner name that you defined in "Setting Up a Message Partner in Alliance Gateway" onpage 103 in the second subfield.

• in the Traffic Type field, select All.

Alliance Access 7.0 - Solaris

104 Installation and Administration Guide

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 "DefiningAlliance Access as an Endpoint on Alliance Gateway" on page 102.

• from the Mode option buttons, select Relaxed.

• from the Cryptographic protocol option buttons, select Advanced.

• the Namespace Declarations check box must not be selected.

• in the Error Code field, select Old.

3. Save this configuration.

4. Finally, enable the Endpoint. See the Alliance Gateway Operations Guide, "Enabling andDisabling an Endpoint".

11.4 Data Encryption/Gateway Authentication betweenAlliance Access and Alliance Gateway

Description

If you have decided to use Data Encryption/Gateway Authentication between Alliance Accessand Alliance Gateway, then perform these steps:

• On Alliance Gateway, create a Private Key and Certificate. See the Alliance GatewayOperations Guide, "Creating a Private Key and Certificates".

• On Alliance Access, configure the SSL settings on Remote API. See the Alliance GatewayRemote API Operations Guide, "Configuring SSL Settings on RA".

Defining Alliance Access in Alliance Gateway

30 September 2011 105

12 Configuring Alliance Access for FINMessaging

Overview

To configure Alliance Access to send and receive FIN messages, you must:

• define a SWIFTNet connection

• assign a SWIFTNet connection to a Logical Terminal

• send and receive a Test MT message

• set up your access to the SWIFTNet FIN Test service (only if you are a vendor).

Configuration through the Alliance Web Platform

You can configure Alliance Access for FIN messaging using the Alliance Access Configurationpackage on the Alliance Web Platform.

For more information, see the section about configuration for SWIFNet Messaging Services inthe Configuration Guide.

To configure the SWIFTNet FIN Test Service (Vendors only), see .

Note

When a FIN message is sent from Alliance Access over SWIFTNet, it is enveloped in anInterAct message. In addition, relationship management authorisations for the live RMA serviceare also exchanged as InterAct messages over SWIFTNet. An Authoriser DN signs the InterActmessages 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 Associated Alliance Gatewaymessage partner

the fin role for the swift.fin service.

In other words, such an Authoriser DN is a certified FINUser.

fin_<instance>

12.1 Defining a SWIFTNet ConnectionOverview

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 ModifyingSWIFTNet Connections" in the System Management Guide.

Alliance Access 7.0 - Solaris

106 Installation and Administration Guide

Permissions

By default, only the security officers, and the R7.0_Supervisor and R7.0_Superkey operatorprofiles have the SWIFTNet Support application permissions. Assign these permissions to otheroperators as needed.

When assigning permissions, ensure that Connection Handling in the "SNL Handling" functionis set to Yes.

If you use Local Authentication between Alliance Gateway and Alliance Access, then you canassign the two parts of the Local Authentication Key in the "SNL Handling" function to a singleoperator, or separately to two operators. By default, the Security Officers (LSO and RSO) onlyhave one part of the Local Authentication Key in the "SNL Handling" function assigned.

For more information about assigning permissions, see "Managing Alliance Access Security" inthe System Management Guide.

12.2 Assigning a SWIFTNet Connection to a LogicalTerminal

Overview

For information about assigning a SWIFTNet connection to a Logical Terminal, see "AssigningSWIFTNet Connections to a Logical Terminal" in the System Management Guide.

12.3 Sending and Receiving a Test MT MessageProcedure

1. Ensure that the Alliance Access servers are running in Operational mode.

2. Sign on through Alliance Workstation as an operator with message processingentitlements.

3. Open the Message Creation application.

4. Create an MT 999 (free format message) to be sent from your Test and TrainingDestination (which is assigned to SWIFTNet) addressed back to your Test and TrainingDestination. Sender and Destination fields in the message must be the same. Your Testand 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 thequeued 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 beselected 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.

Configuring Alliance Access for FIN Messaging

30 September 2011 107

12.4 Access to the SWIFTNet FIN Test Service(Vendors only)

Important

To connect to the SWIFTNet FIN test-infrastructure (FIN Vendor Testbed (VTB) through theSWIFTNet Integration Testbed (ITB)), you must access the swift.fin!x service.

A system variable (SERVICE_NAME) must be set with the value swift.fin!x.

Important This section applies only to SWIFT, its partners, and vendors (your BIC must startwith PT).

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 SystemAdministration window.

Note If the servers are running while setting the variable, then you must do the following:

• Stop the Alliance Access servers and the bootstrap.

• Close the System Administration window, and open it again.

• Start the Alliance Access bootstrap and the servers.

Alliance Access 7.0 - Solaris

108 Installation and Administration Guide

13 Configuring Alliance Access for InterActand 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.

Configuration through the Alliance Web Platform

You can configure Alliance Access for InterAct and FIN messaging using the Alliance AccessConfiguration package on the Alliance Web Platform.

For more information, see the section about configuration for SWIFNet Messaging Services inthe Configuration Guide.

Note

When an InterAct of FileAct message is sent from Alliance Access over SWIFTNet, it isenveloped in an InterAct message. In addition, relationship management authorisations for thelive RMA service are also exchanged as InterAct messages over SWIFTNet. An Authoriser DNsigns 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 Associated Alliance Gatewaymessage partner

the appropriate role for the SWIFTNet Business service sni_<instance>

13.1 Defining a SWIFTNet ConnectionOverview

You must define a SWIFTNet connection to assign to the SWIFTNet emission and receptionprofiles. For more information, see "Defining a SWIFTNet Connection" on page 106.

13.2 Installing Application Service ProfilesOverview

You must install the latest Application Service Profiles on Alliance Access to send and receivetraffic correctly for InterAct or FileAct services.

For more information, see ''Installing Application Service Profiles" in the System ManagementGuide, or the command, "saa_manageasp" on page 292.

Configuring Alliance Access for InterAct and FileAct Messaging

30 September 2011 109

13.3 Configuring SWIFTNet Emission and ReceptionProfiles

Purpose

To exchange messages through SWIFTNet, you must define, enable, and activate SWIFTNetemission and reception profiles for InterAct and FileAct messaging, and also for the RMAservice. You perform these tasks from the SWIFTNet Interface application.

During the installation or upgrade of Alliance Access, an emission profile and a reception profileis 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 thepermissions 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" inthe System Management Guide.

2. Configure a reception profile for each licensed BIC8. See "Defining Reception Profiles" inthe System Management Guide.

3. Assign a SWIFTNet connection to each emission profile and reception profile that youcreated. See "Assigning SWIFTNet Connections to SWIFTNet Profiles" in the SystemManagement Guide.

4. If required, assign an input channel to an emission profile. For more information, see "SetUp Input Channels" in the System Management Guide.

5. Enable and activate each emission and reception profile. See "Enabling and ActivatingSWIFTNet 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 FileActMessage

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 moreinformation, see the Alliance Messenger Administration and Operations Guide.

• Create an MX message from your back-office application and send it to your AllianceAccess system.

2. Route the message to the _SI_to_SWIFTNet queue.

Alliance Access 7.0 - Solaris

110 Installation and Administration Guide

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 beencreated and set up, as well as a reception profile to receive MX messages from the sameSWIFTNet business service. For details, see "Configuring SWIFTNet Emission andReception Profiles" on page 110.

7. Enable and activate the SWIFTNet emission and reception profiles so that the queued MXmessage can be processed. For details, see "Configuring SWIFTNet Emission andReception Profiles" on page 110.

8. Search for the MX message in the Alliance Access Message File application, or fromAlliance Messenger on Alliance Web Platform. For more information, see the AllianceMessenger Administration and Operations Guide.

Configuring Alliance Access for InterAct and FileAct Messaging

30 September 2011 111

Alliance Access 7.0 - Solaris

112 Installation and Administration Guide

Part C

System Administration

Part C - System Administration

30 September 2011 113

Alliance Access 7.0 - Solaris

114 Installation and Administration Guide

14 Introduction to System AdministrationOverview

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 aschecking that the servers are running) must be performed daily, while others (such as renamingan instance) are performed as and when required.

Access to the role of Alliance administrator is gained by logging in with the AllianceAdministrator account. The name of this account is specified during the installation or upgradeof 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 configurevarious operational parameters of Alliance Access, and to perform backups of the AllianceAccess database and archives.

• by using the Alliance command line tools available in $ALLIANCE/bin (such as saa_systemand saa_dbrestore)

• by using UNIX commands, together with dedicated scripts, to interact directly with the UNIXoperating system.

It is primarily the role of the Alliance administrator to perform these tasks. Normally, the Allianceadministrator does not have access to the operational functions of Alliance Access - that is notdefined as an operator able to sign on to Alliance Access. Tasks that must be performed withinAlliance Access (typically using the System Management application) are, therefore, assumedto 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 toUNIX using the Alliance Administrator account. The use of the System Administrationapplication, therefore, is restricted to those with knowledge of the password for the AllianceAdministrator 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 bedefined as an Alliance Access operator and use their separate Alliance Access operatornickname and password for access to the operational facilities within Alliance Access.

For details about the facilities provided within the System Management application, see theSystem Management Guide.

14.1 Overview of the System AdministrationApplication

Introduction

Alliance Access provides a dedicated application which is used exclusively by the Allianceadministrator.

Introduction to System Administration

30 September 2011 115

14.1.1 Selecting an Instance

Overview

Whenever you log into Solaris as Alliance Administrator and enter the relevant password, thesystem 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" onpage 117.

To select an instance:

1. Log into Solaris as Alliance Administrator and enter the relevant password. The AllianceApplication 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 SystemAdministration window appears.

For a description of this window, see "Alliance System Administration Window" onpage 118.

Alliance Access 7.0 - Solaris

116 Installation and Administration Guide

14.1.2 Alliance Application Instance Selection Window

Description

The Alliance Application Instance Selection window enables you to select an AllianceAccess 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 Configurationmenu in the Alliance System Administration window. This facility enables you to enter UNIXcommands and run admin scripts, if required.

Note When you have logged into Solaris as Alliance Administrator, the Xterm commandprovides a shell window with administrator permissions. If you have simplyswitched to the administrator account (using su - <admin account name>)from your own, or another account, then you only have the permissions set foryour, or the other, account.

Many of the administrative tasks you are able to perform, may only be carried out when theAlliance Access servers are not running. If you select such a command while the servers arerunning, 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 "AllianceSystem Administration Window" on page 118. The detailed use of each command is givenlater, within the appropriate section (for example, "General System Maintenance").

Introduction to System Administration

30 September 2011 117

14.1.4 Alliance System Administration Window

Description

The various functions available within the System Administration application are logicallygrouped on four pull-down menus (File, Instance, OS Configuration and Alliance), whichappear 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 yourcommands, and confirmations of the actions taken, are reported. As a general rule, whenspecific actions are completed, a status like the following is reported in the lower part of thewindow:

Completed, Status = 0 the action has completed successfullyCompleted, Status = 1 the action was NOT completed successfullyIf Completed, Status = 1 appears, scroll back the text in the window for indications as tothe likely cause of the problem. In addition, the Alliance Event Journal may be used toinvestigate possible problems.

The lower part of the window is cleared automatically after every 20 K of characters of statusinformation has accumulated. 20 K is the default value which can be altered by the Allianceadministrator using the UNIX environment variable INA_MAX_STATUS_WIN_SIZE. Forexample,

export INA_MAX_STATUS_WIN_SIZE=20000

Example

Menu descriptions

File

The File menu provides access to commands related to your Alliance software:

• Report. See "General Troubleshooting" on page 246for information.

• Print Screen. See "General System Maintenance" on page 123 for information.

• Clear. See "General System Maintenance" on page 123 for information.

• Exit. See "General System Maintenance" on page 123 for information.

Alliance Access 7.0 - Solaris

118 Installation and Administration Guide

Instance

The Instance menu contains commands which you can use to display and manipulate theattributes of all instances installed on the system.

• Current Instance. See "General System Maintenance" on page 123 for information.

• List Instances. See "General System Maintenance" on page 123 for information.

OS Configuration

The OS Configuration menu provides access to the UNIX shell, which enables you to enterUNIX commands and run admin scripts, if required.

See "General System Maintenance" on page 123 for information.

Alliance

The Alliance menu provides access to commands related to using the Alliance servers,managing Alliance data and for troubleshooting:

• Start Alliance Servers. See "Managing the Alliance Access Servers" on page 131 forinformation.

• Stop Alliance Servers. See "Managing the Alliance Access Servers" on page 131 forinformation.

• JOURNAL_Query. See "General Troubleshooting" on page 246for information.

14.2 System Management Procedures

14.2.1 Regular Procedures

Overview

The following regular system management procedures are used to maintain Alliance Access:

• starting and stopping the servers, as required

• checking that the Alliance Access servers are running normally

• taking regular backups of the Alliance Access database.

The Alliance Access servers can be stopped and started from the following applications:

• System Management application: stop, or stop and restart Alliance Access (servers).

• System Administration application: stop or start the servers.

• UNIX command line (for example, using an Xterm): stop the servers using thesaa_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 whenrequired:

• Manage the configuration of Solaris software for Alliance Access

Introduction to System Administration

30 September 2011 119

• 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 TreeAlliance Access software components

The Alliance Access software is made of major functional entities called components. Thesecomponents recognise the client/server architecture of Alliance Access (using remote procedurecalls 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 collectionof servers providing services to applications.

• The Application Component (which refers to the client in the architectural model) is acollection 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:

BSA Base Application

INA Installation

Alliance Access 7.0 - Solaris

120 Installation and Administration Guide

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 thetwo component types. The following describes the Alliance release tree for service andapplication components.

The software release directory structure is as follows:

$ALLIANCE Root directory for Alliance Access Comment

Any ServiceComponent:

BSS, INS, MAS, MXS, RMS, SIS, SNIS,SNSS, SSS, TRS, XSS

bin/SunOS Executables Contains Alliance Accessexecutables and commandscripts

lib/SunOS Run-time libraries

data/SunOS Data, configuration files, parameters files forprinting

nls/SunOS Language-dependent catalogues

install Installation scripts

log Error and log files

Any ApplicationComponent:

BSA, INA, MPA, MXA, RMA,SIA, SNIA,SNSA, SSA

bin/SunOS Executables Contains Alliance Accessexecutables and commandscripts

lib/SunOS Run-time libraries

data/SunOS Data and configuration files

nls/SunOS Language-dependent catalogues

install Installation scripts

/usr/swa/insts Instances registration file Not in release tree, but animportant directory

/usr/tmp/alliance Error and log files

_uninst Uninstallation scripts

usrdata User data Dedicated folder for userdata

data/BIC Directory for full BIC datafiles

Introduction to System Administration

30 September 2011 121

$ALLIANCE Root directory for Alliance Access Comment

data/UpdateBIC Directory for partial BIC datafiles

Core dumps, resulting from process crashes, are located in the bin/SunOS directory of therelevant 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 {} \;

Alliance Access 7.0 - Solaris

122 Installation and Administration Guide

15 General System MaintenanceIntroduction

Alliance Access provides a range of facilities to assist the Alliance administrator with systemmaintenance activities and with general troubleshooting.

All the facilities described in this section are available to the Alliance administrator when loggedon 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 windowof the System Administration application will appear.

2. If the command you require can only be used when the servers are not running, then firstselect the Stop Alliance Servers command from the Alliance menu and wait for theservers to stop.

3. Select the required command from the relevant menu. Some commands simply displayinformation in the scrolling text area at the bottom of the main window. For othercommands, 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 ofa broader discussion and are described, instead, in the following sections:

• "Managing the Alliance Access Servers" on page 131

– "The "Start Alliance Servers" Command" on page 131

– "The "Stop Alliance Servers" Command" on page 136

• "General Troubleshooting" on page 246

– "The Alliance Configuration Report" on page 246

– "The JOURNAL_query Facility" on page 248

All other administrative commands are described in this section.

Tip You can use the saa_system integrity command to check the integrity of theAlliance Access software. For more information, see "Checking the Alliance AccessSoftware Files" on page 234.

15.1 System Management CommandsOverview

The following commands can be used at any time for system management.

General System Maintenance

30 September 2011 123

15.1.1 The Clear Command

Description

The Clear command from the File menu allows you to clear the scrolling text area in the lowerpart of the main window of the System Administration application. Use this command to deleteany text currently displayed in the main window. Once cleared, this text cannot be recovered.

15.1.2 The Print Screen Command

Description

The Print Screen command from the File menu allows you to print the current window to a fileor 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 theFilename 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 adestination printer from the Printer field. Click OK to send the output to the printer. If noprinters have been defined, then the Printer option is not available.

15.1.3 The Exit Command

Description

The Exit command from the File menu allows you to quit the System Administration application.This command automatically logs you (Alliance Administrator) off from the Solaris operatingsystem.

Upon quitting, you may be prompted for a reboot of the system if certain changes have beenmade to the operating system configuration.

Note Refer to the Xterm command if the reason you want to quit the SystemAdministration application is to access the UNIX shell.

15.1.4 Current Instance

Description

The Current Instance command from the Instance menu allows you to display the name of theAlliance Access instance that you are currently using.

Alliance Access 7.0 - Solaris

124 Installation and Administration Guide

15.1.5 List Instances

Description

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

15.1.6 The Xterm Command

Description

The Xterm command from the OS Configuration menu allows you to interact directly with theoperating system by entering UNIX commands from within the System Administrationapplication.

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, orperform other administrative tasks that require direct interaction with UNIX (for example, checkthe contents of a directory, determine which processes are currently running, and so on). Theresponse to such commands normally appears in the same window.

To cancel and dismiss the Xterm shell, enter the exit command.

Note When you have logged into Solaris as Alliance Administrator, the Xterm commandwill provide an Xterm shell window with administrator permissions. When youswitch to the administrator account (using su - <admin account name>) fromyour own account, or another account, you will only have the permissions set forthe original account.

If you want to have administrator permissions, then type the following commands in the Xtermwindow:

$ id # check your user id

$ su - <admin account name> # supply a password

$ ^D # EOF character to stop another

# SAA application appearing

15.2 Essential System MaintenanceIntroduction

For Alliance Access to function in an efficient and trouble-free manner, the AllianceAdministrator is required to perform certain essential tasks.

General System Maintenance

30 September 2011 125

15.2.1 At the Start of the Business Day

Description

Before Alliance Access and Alliance Workstation operators can sign on for normal operations,the Alliance Administrator should carry out the tasks that follow.

Task Tip

Start the Alliance Access servers From the Alliance menu (in the SystemAdministration application).

15.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 EventJournal application to scrutinise system events andalarms, and to view the audit trail of interactiverequests and responses.

Use the Message File application to view thecontents of messages transferred and theirassociated transmission history.

See the System Management Guide

React to any unknown alarms, for example "DiskSpace Too Low".

When you see this alarm, the Alliance Accesssystem is about to shut down.

Use the Monitoring application or the UNIXcommand df to check the disk space parameters.

15.2.3 At the End of the Business Day

Description

The Systems Administrator is responsible for the tasks that follow at the end of the day.

Task Tip

Search the Event Journal for any untreated alarmsand for Security Events. Treat as appropriate.

See the Daily Operations Guide

Archive and back up (with remove option)messages and events to free disk space for thedatabase. These tasks can be automated using theschedule facility.

Free space can be checked using the Monitoringapplication (System Resources - Disk Space).

See the Daily Operations Guide

Alliance Access 7.0 - Solaris

126 Installation and Administration Guide

15.2.4 At the End of the Week

Description

The Systems Administrator is responsible for the tasks that follow at regular intervals (forexample, 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 theEvent Journal application to archive the EventJournal. This can be automated (for example,weekly) using the schedule facility.

See the Daily Operations Guide

Use the Message File application to archive theMessage File. This can be automated using theschedule facility.

See the Daily Operations Guide

When appropriate, stop the Alliance Accessservers. This can be automated using the schedulefacility.

From the Alliance menu of the SystemAdministration application, the SystemManagement application, or through the UNIXcommand line with the script saa_system stop.

Use the System Management application to:

• back up and remove the Event Journal archives

• back up and remove the Message archives

• back up the Alliance Access database.

See the Daily Operations Guide

General System Maintenance

30 September 2011 127

16 Managing UNIX Accounts

16.1 Alliance Administrator AccountOverview

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 'Allianceadministrator' who operates using the dedicated UNIX account name given to the Allianceadministrator. The administrative functions described in this guide, available through the SystemAdministration application, are used exclusively by the Alliance administrator, when logged onas such. In fact, as soon as the Alliance administrator logs on to UNIX, the Alliance SystemAdministration application is started automatically.

The Alliance administrator user is set up during installation.

16.2 Security ConsiderationsOverview

The security of the Alliance Access software and database is ensured by the file permissionsassigned 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, withthe result that only the Alliance administrator can start the Alliance Access servers. Privilegedoperators may also stop or restart the system, using dedicated functions within the SystemManagement application.

Some executables (such as the saa_monitor or saa_manage tools) can be run by other UNIXaccounts, but require specific Alliance Access credentials.

• The files in the database can only be updated by the Alliance administrator or by the AllianceAccess servers at run time.

The following table lists the ownership and file permissions used for Alliance Access:

File Type Owner Group File Permission

data files all_adm alliance, or the defaultprimary group

rw- --- ---

executables all_adm alliance, or the defaultprimary group

rwx r-x r-x

Alliance Access 7.0 - Solaris

128 Installation and Administration Guide

16.3 The alliance_init FileDescription

From the definition of the environment variables $ALLIANCE and $ALLIANCE_DB, theinstallation 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:

-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.

16.4 Workstation IP Address CheckingDescription

The IP addresses of the remote machines that are permitted to connect to your Alliance Accessserver as Alliance workstations are configured using the saa_configconnection tool. For moreinformation, see "saa_configconnection" on page 230.

To enable the change, you have to stop and restart the Alliance Access servers.

16.5 The Instance Registration FileOverview

The details of all installed instances of Alliance Access are stored in a system file locatedat /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

Managing UNIX Accounts

30 September 2011 129

• instance comment.

Alliance Access 7.0 - Solaris

130 Installation and Administration Guide

17 Managing the Alliance Access ServersOverview

This section describes the management of the Alliance Access servers, using functions whichthe Alliance administrator must perform using either the commands available from the SystemAdministration application or UNIX command line scripts.

Note These command scripts require the correct environment to be set, which isautomatically done when logging on as all_adm. However, if you want to carry outadministrator functions while logged on as "root", then you must run the scriptusing the following syntax:

. /usr/swa/alliance_init -s [-i <instance_name>]

Tip At the end of a normal operational day, a supervisor (or senior operator) can usethe Stop Alliance command in the System Management application to stop theservers.

17.1 Starting the Alliance Access ServersOverview

This section describes how to start the Alliance Access servers using either:

• the System Administration application and the Start Alliance Servers command

• saa_system start housekeeping|operational command

17.1.1 The "Start Alliance Servers" Command

17.1.1.1 Running the "Start Alliance Servers" Command

Description

The Start Alliance Servers command, from the System Administration application, is used(only by the Alliance Administrator) to start the Alliance Access servers (for example, at the startof the day or after system maintenance).

Note The Alliance Access servers MUST be running before any client application (suchas the Support application) can be started by an Alliance Access user. Therefore,no operator can sign on to Alliance Access until the servers are running.

To start the Alliance Access servers:

1. Log into UNIX as Alliance Administrator.

2. If more than one instance is installed on your system, then the Alliance ApplicationInstance Selection window appears. Select the required instance from the list pane. Themain window of the System Administration application appears.

3. Select Start Alliance Servers from the Alliance pull-down menu.

Managing the Alliance Access Servers

30 September 2011 131

If the servers are not already running, then a shortcut menu appears prompting theadministrator 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 atServer Startup" on page 133.

5. If there is no active routing schema, then the servers cannot be started in Operationalmode. In such a case, the Housekeeping mode is invoked.

6. When the servers have started, and after several system messages, the followingconfirmation message appears:

Alliance has started

7. If there are no other tasks to perform, then select Exit from the File pull-down menu. Youare logged off from the Alliance Administrator account.

17.1.1.2 Considerations when Using the "Start Alliance Servers" Command

Overview

When the Start Alliance Servers command is run, the server processes are started in an orderthat respects interdependency between them. The script does not return control to the terminaluntil all server processes have successfully started, until a time-out value is reached, or an erroroccurs.

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 indicatewhy the servers failed to start:

• Time-out value reached before the servers are ready.

• Some process failed to run.

• Some process terminated in error.

• A whole component failed to start.

Relevant errors can be found in:

• the System Administration window

• the event journal

• status_file (in $ALLIANCE_DB)

• logfile.<instance name> (in $TMPDIR or, if $TMPDIR is not defined on the system,in /var/tmp/alliance)

• errorfile.<instance name> (in $TMPDIR or, if $TMPDIR is not defined on the system,in /var/tmp/alliance)

The normal sequence of processes started is as follows:

1. BS_csys

2. BS_topc

Alliance Access 7.0 - Solaris

132 Installation and Administration Guide

3. BS_alarm

4. BS_rmq

5. BS_config

6. BS_search

7. Processes of all the other service components.

17.1.1.3 Extended Reporting at Server Startup

Overview

During startup of the Alliance Access servers, all processing actions are recorded in a log filecalled status_file. This information can also be displayed in the System Administrationapplication window. This optional feature helps you interpret problems which can occur whenthe 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 Administrationapplication. The Alliance System Administration: Start Servers window appears.

2. Click Yes from the Extended Reporting menu button. Extended reporting is displayed inthe main window.

17.1.1.4 Extended Reporting Output Format

What is displayed by Extended Reporting

If Extended Reporting is turned on, then the following items are displayed:

• If the database is being started or if the Alliance Access bootstrap is running, then this isdisplayed.

• For each server that is started, the server name, an indication that the server is starting, andthe result ("Ready" or "Failed") is displayed. If a server fails to start, then the event related tothis failure is also displayed.

Example:

Server MXS : Starting... Ready

• If recovery is invoked, then the following is displayed for any change in the recoveryprocess: which entity, message partner, and so on, is recovering and, where relevant, acounter showing how many records have been recovered, whether any messages are still

Managing the Alliance Access Servers

30 September 2011 133

being processed, and the keyfield of the record being processed. All this helps to determinewhich 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 ifpossible the exact record) is displayed.

• Possible solutions to problems that may arise are displayed. Depending on the situation, awarning is issued for the user to make a backup before trying to solve the problem.

17.1.2 Checking that the Servers are Running

To determine which Alliance Access processes are currently running:

1. Log into UNIX as Alliance Administrator. The main window of the System Administrationapplication 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 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 thanone BS_csys process running for a period of a few seconds. These duplicateprocesses change into genuine processes in due course. Where BS_csys is notrunning, then the Alliance Access servers are not running.

17.2 Stopping the Alliance Access ServersOverview

This section describes how to stop the Alliance Access servers using either:

• the System Administration application and the Stop Alliance Servers command

• saa_system stop command

In most circumstances, a shutdown of the Alliance Access servers is initiated within the SystemManagement application of Alliance Access, using the Stop Alliance command.

The behaviour of Alliance Access after the shutdown request is as described in "Description" onpage 136.

17.2.1 Shutdown of Alliance Access

Description

The usual way to shut down the Alliance Access servers is by using the facilities provided withinthe 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 isrunning out of disk space.

Alliance Access 7.0 - Solaris

134 Installation and Administration Guide

However, in certain circumstances the Alliance administrator may want to shut down theAlliance Access servers (for example, for urgent system maintenance) with the use of the StopAlliance Servers command that is available from the System Administration application.

In urgent situations, the Alliance administrator may also force the immediate termination of allAlliance Access servers and processes using the saa_system stop force command. Fordetails, see "To stop the server" on page 236.

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) atwhich disk space is checked.

300

Shutdown - MB The absolute minimum free disk space (inMB) that must be available on the diskcontaining the database. A system shutdownis initiated if the free disk space available forthe database falls below this value. Thesystem automatically adds (for recoverypurposes) the size of the largest database filestored in the database, plus the size of thedatabase index file, to the value specified.

The frequency with which this parameter ischecked is set by the Disk Space -Frequency parameter.

1000

Shutdown - Release Dir Shut down Alliance Access when availablespace on the disk of the source tree is lessthan this value (in KB).

20000

Warning - MB A warning is issued when the available space(in MB) on the disk of the database is lessthan value.

In addition, extra space (equal to the currentsize of the largest database file) is added tothis value.

5000

Warning - Release Dir A warning is issued when the available space(in KB) on the disk of the source tree is lessthan this value.

50000

Warning - Printer Spool A warning is issued when the available spaceon the /tmp disk is less than this value (inKB).

When the threshold is passed, an alarm issent to all operators who are signed on towarn them that the available disk space islow.

Note that if the disk space available to the "/tmp" directory is less than the value specifiedhere, you will receive warnings about lack ofdisk space.

10000

These parameters are set within the System Management application of Alliance Access. Whena warning of disk space being low has been given, further warnings are generated every 10cycles of disk checking.

If the system shuts down due to insufficient disk space, then you may create additional free diskspace by removing core files and by backing up message and event archives. The archives canthen be removed from the system.

Use the following command to remove core files:

Managing the Alliance Access Servers

30 September 2011 135

find / -name core -exec rm {} \;In addition to the above parameters, a continuous background process also monitors the use ofpaging space. If the available paging space is found to be dangerously low, then a warningmessage will pop up that to inform users to quit Alliance Access. If this message appears, thenall operators must sign off immediately from Alliance Access and you are advised to shut downthe servers.

When the servers have been restarted, the normal functions of Alliance Access are sufficient toenable users to sign on again and continue working.

17.2.2 The "Stop Alliance Servers" Command

Overview

In most circumstances, a shutdown of the Alliance Access servers is initiated from the SystemManagement 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 SystemAdministration 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 thatrequire 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 ofwho initiated the shutdown.

• All operators receive an alarm message, stating that the system is shutting down within aspecified period of time. This "grace period" (default is 120 seconds) is that specified by theShutdown "Delayed" parameter which can be configured within the System Managementapplication.

• During the grace period, the servers continue to function normally to allow users to completeany work.

• After the grace period has expired, the servers stop, one after another, in an order thatrespects 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 iskilled.

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 limitspecified by the Shutdown "Forced" parameter (default value is 240 seconds), a"forced shutdown" is then initiated. During a forced shutdown, processes are killedby BS_csys in an arbitrary order. This parameter is configurable within the SystemManagement application.

Processes terminated in this way are logged in the Event Journal by BS_csys, asif they had crashed.

Alliance Access 7.0 - Solaris

136 Installation and Administration Guide

17.2.3 The saa_system stop Script

Description

The saa_system stop script can be used to stop the Alliance Access servers.

In most circumstances, a shutdown of the Alliance Access servers is initiated within the SystemManagement application of Alliance Access, using the Stop Alliance command.

The Alliance Access servers may also be shut down from the UNIX command line, by runningthe command:

saa_system stopThe behaviour of Alliance Access after the shutdown request is as described in "Description" onpage 136.

17.2.4 The saa_system stop force Script

Overview

The Alliance administrator must resort to the use of the saa_system stop force script, whenand only when either the system must be stopped urgently or the normal shutdown procedurefailed to complete.

To kill the Alliance Access servers:

1. Log into UNIX as Alliance Administrator. After you make your selection from the instanceselection window (if more than one instance is installed on your system), the main windowof 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 recordedin 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 UNIXcommand:

ps -ef | grep $ALLIANCE | grep -v grepmust not show the BS_csys process.

Managing the Alliance Access Servers

30 September 2011 137

17.3 Running Selected Program Scripts followingServer Start and Stop

Description

You can specify two executables which may be invoked when the Alliance Access servers areeither started or stopped.

These executables must be present in the script sub-directory of usrdata beneath yourinstallation directory, and must be declared in:

• saa_starthook

• saa_stophook

Scheduling the automatic starting and stopping of the Alliance Access servers is described inthe System Management Guide.

Note The post processor scripts must not contain arguments or quotes. The Allianceadministrator (typically all_adm) must own the scripts. The scripts cannot bewriteable for group or for world (use 0755 for example).

17.4 Monitoring ProcessesIntroduction

The Monitoring application (available from the Access Control application) displays dynamicdata for all servers, and applications that are currently operating in the Alliance Accessenvironment.

Processes are divided into server components, which process and deliver data to applicationsand application components.

17.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 Modemenu.

You can select to display all processes, or only those in an exceptional state (crashed ortimed-out).

Alliance Access 7.0 - Solaris

138 Installation and Administration Guide

17.4.2 Viewing the Status of a Process

Displaying the processes:

• Timed-out

The application did not receive input within the time-out period and has terminatedaccordingly. This is an exceptional state.

• Running

The application is available. This is the normal process state. Some processes may godirectly into this state without initialising.

• Crashed

The application or server has either crashed or the user has quit or aborted the process. Thisis an exceptional state.

For more information, see "Session Status Pane" in the Daily Operations Guide.

17.4.3 Stopping a Process

Description

Periodically, you may be working with a process which, for some reason, must be terminated.Such a process (for example) can be an application within a component whose response timehas become unsatisfactory due to a possible system overload.

Note Selecting and stopping a component process terminates the entire componentregardless of the number of sub-applications that may be running. For example,stopping the Message Preparation component would stop all Message Preparationapplications 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 theoperation of the selected process.

4. Select Action | Processes | Stop.

17.4.4 Locating and Identifying a Process

Description

The Processes list displays a number of fields to identify a particular process in the system. Usethese attributes to locate and identify the process that you want to stop.

• Description

Short textual description of the application, or server currently running.

Managing the Alliance Access Servers

30 September 2011 139

• Started By

The name of the operator who is currently using the application. The value of this data field isalways equal to "SYSTEM" for servers.

• PID

Process IDentification number. Each process that is currently active within the UNIXoperating 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 terminalwindow that is used to display the application. This host name is not necessarily the machineon which the host system or client process is running.

• Status

The current operational state of the process.

Alliance Access 7.0 - Solaris

140 Installation and Administration Guide

18 Query the Database for Message, Events,and Operator Details

Overview

This section describes how to query the Alliance Access database for messages, operatordetails, and events.

Important The functionality for querying the database for messages and events is onlyavailable in release 7.0.10 and later releases.

The functionality for querying the database for operator details is only available inrelease 7.0.30, and later releases.

18.1 Query the Database to Extract MessagesPurpose

You can run a query to extract the content of messages (live or archived) from the database.The query provides the contents of the messages that were created within a specific timeperiod.

The messages are provided in an output file in XML format.The XML format is the same formatfor the Web Services for queries on messages.

You can only extract details of messages only from the Alliance Access instance from which thecommand is run.

Note You do not need the Web services licence package to use this command.

Prerequisites

To query messages, the Alliance Access server must be running in operational mode.

Note Your Alliance Access licensing agreement allows only a certain number ofoperators to use the system concurrently. Running a query to extract messagesstarts an operator session with Alliance Access, and this session is included in thecount of concurrent users of the system.

To query messages in the database

1. Log on to the machine where Alliance Access is installed.

2. From the System Administration application, select Xterm from the OS Configurationmenu.

3. Enter the saa_query command.

For command location, syntax, and results, see "saa_query" on page 295.

The contents of all messages that have a creation time or date within the time period areexported from the database to an output file.

The progress of the command is displayed on the screen. The following output appears on-screen when Alliance Access finds no more messages that match the time period specified:

INFO Logging to C:\Alliance\Access\log\sa_extract_20110421T123427.output

Query the Database for Message, Events, and Operator Details

30 September 2011 141

INFO Start time : 2011-04-21T00:00:00.000ZINFO End time : 2011-04-21T23:59:59.000ZINFO 103 records exported INFO Extraction successful

18.2 Query the Database to Extract EventsPurpose

You can run a query to extract the content of events (live or archived) from the database. Thequery provides the contents of the events that were created within a specific time period.

The messages are provided in an output file in XML format.The XML format is the same formatfor the Web Services for queries on messages.

Prerequisites

To query events, the Alliance Access server can be running in either operational orhousekeeping mode.

Note Your Alliance Access licensing agreement allows only a certain number ofoperators to use the system concurrently. Running a query to extract messagesstarts an operator session with Alliance Access, and this session is included in thecount of concurrent users of the system.

To query events in the database

1. Log on to the machine where Alliance Access is installed.

2. From the System Administration application, select Xterm from the OS Configurationmenu.

3. Enter the saa_query command.

For command location, syntax, and results, see "saa_query" on page 295.

The contents of all events that have a creation time or date within the time period arecopied from the database to an output file.

The progress of the command is displayed on the screen. The following output appears on-screen when Alliance Access finds no more events that match the time period specified:

INFO Logging to C:\Alliance\Access\log\sa_extract_20110419T163427.outputINFO Start time : 2011-04-19T00:00:00.000Z INFO End time : 2011-04-19T23:59:59.000Z INFO 720 records exported INFO Extraction successful

18.3 Query the Database to Operator DetailsPurpose

You can run a query to extract information about operators and operator profiles from thedatabase.

The command extracts details only from the Alliance Access instance from which the commandis run.

The extracted information is stored in an output file in XML format.The XML format is the sameformat for the Web Services for queries on messages.

Alliance Access 7.0 - Solaris

142 Installation and Administration Guide

Prerequisites

To query operator details, the Alliance Access server can be running in either operational orhousekeeping mode.

In addition, to extract the delegation details of an operator, the operator profile of the operatorthat runs the command must include the System Management entity in the selectedpermissions. By default, the default operator profile, R7.0_Import_Export includes the requiredpermissions.

Note Your Alliance Access licensing agreement allows only a certain number ofoperators to use the system concurrently. Running a query to extract messagesstarts an operator session with Alliance Access, and this session is included in thecount of concurrent users of the system.

To query events in the database

1. Log on to the machine where Alliance Access is installed.

2. From the System Administration application, select Xterm from the OS Configurationmenu.

3. Enter the saa_query command.

For command location, syntax, and results, see "saa_query" on page 295.

The operator details are copied from the database to an output file.

If the operator that launches the command has delegated units, profile, or destinations,then only those allowed units, profiles and destinations are exported.

The progress of the command is displayed on the screen. The following output appears on-screen when Alliance Access finds no more events that match the time period specified:

INFO Logging to C:\Alliance\Access\log\sa_extract_20110419T163427.outputINFO Start time : 2011-04-19T00:00:00.000Z INFO End time : 2011-04-19T23:59:59.000Z INFO 720 records exported INFO Extraction successful

Query the Database for Message, Events, and Operator Details

30 September 2011 143

19 Backing Up DataIntroduction

Data generated by Alliance Access is stored in a database and archives. It is important to makebackups of this data. This can be done in either of the following ways:

• by using the Backup/Restore command from the System Management application (throughthe Access Control application, using an Alliance Workstation).

• by typing a command from a Command Prompt window. For detailed instructions, see"saa_system" on page 231.

SWIFT recommends to:

• back up (and remove) the Message File and Event Journal archives every week

• perform a database backup on a daily basis

• take a full system backup at least weekly, or more frequently if required.

Important To take a full system backup, all applications on the system must be stopped.This includes stopping the Alliance Access bootstrap service and the database,using the saa_bootstrap stop command.

Alliance Access maintains all of its software in a directory defined by the environment variable$ALLIANCE.

To ensure operational security and efficient data recovery in the event of a major problem, allAlliance Access data AND associated system configuration data must be backed upperiodically. This section describes the procedures used to back up the Alliance Access data, aswell as the complete system.

The frequency with which backups are taken, and the number of historical copies retainedbefore the oldest is overwritten, is for individual organisations to decide according to localrequirements for operational security. The main reason for making regular backups is to ensureminimal downtime in the event of disaster. It is therefore highly recommended that youimplement regular backup procedures to protect against equipment failure.

19.1 Database BackupDescription

Alliance Access configuration data (for example, operator definitions, profiles, routing rules,RMA authorisations, and so on) is maintained in the $ALLIANCE/database directory. Thecollection 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 arearchived. For information about archiving, see the Daily Operations Guide.

Note An Alliance Access database backup does not include messages or events.

Alliance Access 7.0 - Solaris

144 Installation and Administration Guide

19.2 Archive BackupDescription

Archives of the Message File and Event Journal are kept in the database until they are backedup.

Only the archive backups that were created using the Backup/Restore function are compatiblebetween versions of Alliance Access.

Note You cannot create backups of archives that were created using Alliance Access6.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 thearchives on a daily basis, then you are advised to make regular backups of the archives andremove the original archives. This action makes disk space available and enables data to berecovered efficiently in the event of a major problem, such as, disk failure.

19.3 Temporary Storage Directory for BackupOverview

If one of the environment variables $TMP, $TMPDIR or $TEMP are set, it will be used asstorage 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 (bydefault, .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

Backing Up Data

30 September 2011 145

Note If you select not to create this entry, temporary files will populate the /var/tmp and /tmp directories during operation and backups. These files must bedeleted manually during maintenance periods. An exception is the /var/tmp/alliance directory, which contains important log files and is maintainedby Alliance Access.

7. Save the file and quit the System Administration window.

19.4 Performing a Manual Backup of ArchivesIntroduction

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 recordedpermanently.

Status of the archives

The archives that appear in the Available list in the Alliance Backup window can have thefollowing states:

Status Description

Ready Alliance Access has created an archive successfully, and the archive isready 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. In the Backup operating mode field, select Manual.

Alliance Access 7.0 - Solaris

146 Installation and Administration Guide

5. Click Backup .

The Alliance Backup window appears.

6. The Backup Directory field specifies the location where Alliance Access stores the backupfile. 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 directorypath 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 originalarchive after the backup is complete.

• Remove, to delete an archive that has the status Done, without creating a backup for thearchive.

8. Select the archives to back up, by clicking the transfer arrows to move the archivesbetween the Available pane and the Selected pane.

Note An archive must have the status of Ready or Done, before you can create abackup for it.

9. Click OK .

If the Alliance Access creates the backup file successfully, then it displays a confirmationmessage. Click OK in the confirmation dialog box.

The selected archives are backed up, or removed according to your selection.

Backing Up Data

30 September 2011 147

Names of archive backup files

Alliance Access creates a directory for every archive backup, and uses the following namingconvention 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_20070617JRAR_20070610_20070614

19.5 Performing a Manual Backup of the DatabaseIntroduction

You can create a backup of the Alliance Access database manually using the SystemManagement 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 recordedpermanently.

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.

Alliance Access 7.0 - Solaris

148 Installation and Administration Guide

6. The Backup Directory field specifies the location where Alliance Access creates thedirectory for the backup.

If required, click ... to specify a different location.

Tip If you intend to copy the backup to tape or a hard disk, then make a note ofthis directory path for future reference.

7. Click OK .

If the Alliance Access creates the backup file successfully, then it displays a confirmationmessage. Click OK in the confirmation dialog box.

Following the successful backup of a database, Alliance Access writes the version number ofthe Alliance instance and the current date in an information file called backup.info. AllianceAccess 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 theoldest backup. If you click No , then it does not remove the oldest backup. If you click Yes , thenit 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 namingconvention for the directory:

YYYYMMDDTHHMMSS_SAA_DATA_BACKUPWhere YYYYMMDDTHHMMSS represents the local time on the server when the backup wascreated.

Backing Up Data

30 September 2011 149

Examples of directory names:

20070426T120000_SAA_DATA_BACKUP20070426T220000_SAA_DATA_BACKUP

19.6 Scheduling Automatic BackupsOverview

It is possible to schedule automated backups of the database and of archives. The AllianceBackup/Restore application starts backups according to the schedule defined. For moreinformation, see "Configuring the Calendar and Scheduling Processes" in the SystemManagement Guide.

Backup schedule exceptions

If a backup or restore is running at the time the backup is scheduled, the scheduled backup isnot performed and an event is logged in the Event Journal. Also, scheduled backup does nottake a backup of the archives that are either under construction (that is, the archive process isrunning), or being consulted.

19.7 Following a BackupDescription

The Backup/Restore application creates backup files and places them in a backup directory. Byusing the browse function you can back up to any device with a drive designation on yourmachine. It is up to you to decide what you do with the backup files. They can be copied to tapeor a hard disk. Once created, store your backups in a safe location, according to yourinstitution's security procedures.

Alliance Access 7.0 - Solaris

150 Installation and Administration Guide

20 Restoring DataIntroduction

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 (throughthe Access Control application, using an Alliance workstation). This can only be used torestore archive backups.

• by typing a command from an X-term (from the OS Configuration menu in the SystemAdministration window).

For detailed instructions, see:

– "saa_system" on page 231 to restore archive backups

– "saa_dbrestore" on page 285 to restore database backups.

You can restore:

• Event Journal archives

• Message File archives

• Some or all of the configuration data

For more details, see "Backing Up and Restoring" in the Daily Operations Guide.

20.1 Restoring an Archive BackupOverview

The restore procedure imports the contents of an archive backup file into the Alliance Accessdatabase. 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), thenyou can restore them from the backup files, using the Backup/Restore application or thecommand line tools.

You can also restore archives from backup using the System Management application, which isaccessible through Alliance Workstation.

Note On UNIX, if you are restoring from a backup made with Alliance Access 6.0, thenyou 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 functionalitiesfor 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.

Restoring Data

30 September 2011 151

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 thisfield.

5. The Backup Directory field contains the current path name of the archive to be restored. Ifrequired, select another path by clicking ... .

6. Click the transfer arrows to move the archives between the Available pane and theSelected pane.

7. Click OK to restore the selected archives.

Alliance Access 7.0 - Solaris

152 Installation and Administration Guide

If the archive is restored successfully, then a confirmation message appears. Click OK .

20.2 Restoring the Alliance Access DatabaseWhen to restore

You can restore the content of the database if it becomes corrupt, possibly because of a partialor complete disk failure.

If such a failure occurs, you may have to reinstall the Alliance Access software before you canrestore the database.

Important If you have to restore from a backup, then you lose all the changes that you havemade to your system since this backup. Therefore, you must create backupsfrequently.

You cannot restore a database from a backup that was created with a previousrelease 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. Thisenables you to restore the database to a different installation of Alliance Access on a differentcomputer, or disk.

Restore Sets

You can restore either the complete contents of the database or just a set of related data, whichis called a Restore Set. If you restore the complete database to the same system from which thedatabase backup was created, then the Message File and Event Journal entries are overwrittenduring the restore.

You can use the Restore Set option to restore a set of related data, to the exclusion of all otherdata. For example, to copy configuration files and security definitions from a fully configuredprimary site onto a secondary or backup site. To restore the database completely, select all theRestore Sets.

Before restoring data, you can check the consistency of the Restore Set with your currentdatabase.

For more information, see "Restore Sets" on page 155.

Disabling connectivity and ADK components

When restoring the Alliance Access database, it is possible to disable automatically theconnectivity with different networks, back-office applications, and printers, as well as ADKcomponents. If the restored system is used as a cold backup system, then you must disable thisconnectivity.

Licence verification

When backing up the complete Alliance Access database, the Backup application also backs uplicensing. The Backup/Restore application verifies that the licensed options on the targetmachine are the same as those on the backup machine. This ensures that the licensed optionson the test system and live system are the same. If a difference is found, a warning is given andthe restore operation stopped.

Restoring Data

30 September 2011 153

20.2.1 Overview of Restoration Process

Database restoration

The restoration of the Alliance Access database involves the following tasks:

1. 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 moreinformation, see "saa_configconnection" on page 230.

If you do not know the password used to encrypt the file containing the Private Key(created by the swrpc_keytool), then you must run swrpc_keytool tool first.

5. Start the Alliance Access servers.

The Backup/Restore application keeps a catalogue of entities that are validated whenselectively restored (for example, Units, Operators, Keywords, Exit Points and Queues, and soon).

Synchronisation between Live and Test Alliance Access systems

Some users maintain both "live" and "test" systems. The test systems, which are usuallybackups of the live system, are used to prove that a new release functions correctly or tovalidate 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 databaseonto the live machine, Alliance Access provides verification on each selected Restore Set. Theinformation used to verify that the restored data entities is catalogued during the backupprocess.

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 appearsshowing 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>

Alliance Access 7.0 - Solaris

154 Installation and Administration Guide

Note When restoring data from a database backup, the Restore application verifies thatthe licensed options on the target machine are the same as those on the machinewhere the backup was made. For destinations, the Backup/Restore applicationdoes not check the Test and Training destinations that the users added). If adifference is found, then a warning appears, and the user must stop the restoreoperation.

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. Forexample, you can use this option to copy configuration files from a fully configured primary siteonto a secondary or backup site.

Before restoring data, you can check the consistency of the Restore Set, with your currentdatabase, using the saa_dbrestore command. For command location and syntax, see"saa_dbrestore" on page 285.

20.2.3 Restoring the Database

Permissions required

You need the Alliance Access Administrator account to restore a database backup.

Before you begin

• Before making a partial restore of a database from another machine, make sure that theAlliance 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 "Runninga Consistency Check" on page 155.

• If you have database recovery activated, then you must deactivate it, as described in"Deactivate the Database Recovery Mode" on page 177.

• Stop the Alliance Access servers.

Restore the database

You restore the database using the saa_dbrestore command. For command location andsyntax, see "saa_dbrestore" on page 285.

20.2.4 Restore Sets

ADK storage

If option 99:TOOLKIT RUN-TIME is licensed, information specific to the ADK applications isrestored 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 arerestored.

Restoring Data

30 September 2011 155

Correspondent

The Correspondents information is restored when this Restore Set is selected.

Operator

When you restore the Operator Restore Set, Alliance Access imports the operator definitions,entitlements, and permissions into the database.

When restoring the Operator Restore Set, the consistency check ensures that no conflicts existin the definitions. For Units, the validation is to ensure that they exist. There is no check toensure 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 showsthe validated entities and their level of consistency. The location of a detailed log file is providedat 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 averification 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 beforethe 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 restoreis not allowed. If other inconsistencies are detected (operator names), an option to continue orcancel 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 concerningSWIFTNet connections must be restored.

Alliance Access 7.0 - Solaris

156 Installation and Administration Guide

After a restore, if an LT uses a specific Authoriser DN that no longer exists, then you mustassign another SWIFTNet connection to the LT, or update the SWIFTNet connection assignedto 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 theSWIFTNet connection information must be restored.

Restoring Data

30 September 2011 157

21 Managing Disk SpaceIntroduction

Alliance Access monitors the different parameters related to available disk space. Theseparameters are listed in the following section and can be updated using the SystemManagement application. The most critical parameter ensures that there is always enough diskspace available for Alliance to take a copy of the largest file of the database (for archiving andrecovery 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 (ofthe 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 diskspace decreases. You can only free disk space when archives are backed up and removed.

21.1 Monitoring Available Disk SpaceDescription

Applications such as the Event Journal and the Message File applications are continuallyadding 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 iscontinually available to other applications.

The system resource display provides a parameter (Disk Space) which enables you to monitorthe available disk space for the database at any given time. Exceptional events are defined formany object classes monitored in the Monitoring application. For example, the Disk Spaceparameter is considered to be in the exceptional state if the free space is less than the minimumvalue specified by the Disk Space configuration parameter Warning - MB. For moreinformation about Disk Space parameters, see the System Management Guide.

21.2 Modifying Disk Space ParametersIntroduction

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 youwant to modify.

Fore information about the parameters available, see the System Management Guide.

Alliance Access 7.0 - Solaris

158 Installation and Administration Guide

21.3 System ResourcesDescription

The Monitoring application provides a Disk Space parameter which enables you to monitor theavailable disk space and system archiving. The parameter indicates the amount of spacecurrently 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) aswell as '% capacity' used. Any file system reported as nearing capacity should be investigatedso as to free up disk space.

21.4 How To Recover Disk SpaceTo recover disk space:

1. Remove unwanted files from the system (for example: Core dump files, old files held inprint 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 Managementapplication.

21.5 Backing Up the Instance Registration FileDescription

Use these commands to copy the directory containing the instance registration file to an archivefile in a suitable directory:

su root #provide password

cd /usrtar cvpf <target directory>/<archive file> swa/*The instance registration file can be identified by its title 'insts'.

Managing Disk Space

30 September 2011 159

22 Managing the Database

22.1 Getting Information about the Alliance AccessDatabase

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 physicalmemory (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 Configurationmenu.

3. Enter the saa_dbinfo command.

For command location and syntax, see "saa_dbinfo" on page 282.

The tool provides, for the period specified, the available hourly diagnostic information generatedby the database engine.

22.2 Checking the Alliance Access DatabasePurpose

Verifies the integrity (absence of unauthorised updates) of the Alliance Access database. Youcan 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 Configurationmenu.

Alliance Access 7.0 - Solaris

160 Installation and Administration Guide

3. Enter the saa_system dbintegrity command.

For command location and syntax, see "saa_system" on page 303.

22.3 Configuring the Embedded DatabasePurpose

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 aspecific 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 requiredsize

• 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 notalready 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 thedata files.

Prerequisites

The command must be run by the Alliance Access Administrator account.

The Alliance Access Bootstrap service must be stopped.

The servers must be stopped, except in the case of saa_dbconfig -display.

Note You cannot use the saa_dbconfig command with a hosted databaseconfiguration.

Managing the Database

30 September 2011 161

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 Configurationmenu.

3. Enter the saa_dbconfig tablespace command.

For command location and syntax, see "saa_dbconfig" on page 281.

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 Configurationmenu.

3. Enter the saa_dbconfig redolog command.

For command location and syntax, see "saa_dbconfig" on page 281.

Note The original redo log files remain in the original directory.

Location of database files

The Location Journal Events and Location Messages configuration parameters can be usedto change the default location of the datafiles used to store Journal Events and Messages.

For more information, see the System Management Guide, Classes of ConfigurationParameters.

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 Configurationmenu.

3. Enter the saa_dbconfig command.

For command location and syntax, see "saa_dbconfig" on page 281.

Note To allocate more memory to the database, it is recommended to have the project-max-shm-memory parameter at least equal to the database memory value plus 2GB. The minimum for project-max-shm-memory should be 4 GB. If there aremultiple Alliance Access instances for the same user account, then the databasememory value (in the above formula) is the sum of each Alliance Access instancedatabase memory size.

22.4 Backing Up the Alliance Access DatabasePurpose

The saa_system dbbackup command is used to perform a full database backup. Thedatabase can be either hosted on a separate Oracle database, or embedded in AllianceAccess.

Alliance Access 7.0 - Solaris

162 Installation and Administration Guide

Procedure

1. Log on to the machine where Alliance Access is installed.

2. From the System Administration application, select Xterm from the OS Configurationmenu.

3. Enter the saa_system dbbackup command.

For command location and syntax, see "saa_system" on page 303.

Note Alliance Access removes the oldest backup if more than two backups exist withinthe target backup directory.

22.5 Moving the Database to a New HostPurpose

Use this procedure if you need to move the hosted database to a new host machine.

Procedure

1. Stop the Alliance Access servers.

2. Move the database to the new host machine.

3. Run the saa_dbpwdutil command (for information and details, see "saa_dbpwdutil " onpage 282).

4. Start the Alliance Access servers.

22.6 The saa_bankquery ToolPurpose

The saa_bankquery tool provides a dedicated Alliance Access database enquiry and repairfacility to verify and repair database entities.

Prerequisites

Only an Alliance Access Administrator can run saa_bankquery .

Given the powerful nature of this tool, its use is protected by three passwords:

• the first password is the Solaris password of the Alliance Administrator (needed initially to logon to the Alliance Administrator account to run saa_bankquery)

• the second password is that of any Alliance Access operator (for example, a supervisor) whohas 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, asdescribed further.

When running the saa_bankquery tool for repair, the Alliance Access servers must not berunning.

Managing the Database

30 September 2011 163

Note An operator who uses One-Time Passwords or LAPD authentication cannot usethe saa_bankquery tool.

22.6.1 Running saa_bankquery

Overview

The need to run the saa_bankquery tool implies that you have a serious problem that cannotbe resolved without assistance from SWIFT. If so, first contact Support and be ready to followthe 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 Configurationmenu.

3. Enter the saa_bankquery command.

For command location and syntax, see "saa_bankquery" on page 279.

You are prompted to enter the name and password of a valid Alliance Access operator.This operator must have been granted the entitlement to use saa_bankquery within theAccess Control application of Alliance Access. This entitlement is granted automatically tothe default Supervisor and SuperKey profiles. Assigning this entitlement to other operatorsrequires the approval of both security officers.

4. When prompted, enter a valid Alliance Access operator nickname and the associatedpassword.

The saa_bankquery tool then generates a "session ID" which you must communicate (byphone) to Support. A message is displayed, like:

*** The ID to be used today is "01 SAAGBEBB B04D035F REL6200".ZERO ONESIERRA ALPHA ALPHA GOLF BRAVO ECHO BRAVO BRAVOBRAVO ZERO FOUR DELTA ZERO THREE FIVE FOXTROTROMEO ECHO LIMA SIX TWO ZERO ZEROPlease contact SWIFT customer support for the password

5. Inform Support of the ID shown on the screen. In return, Support informs you of a specialpassword, based on the ID you have provided. You need this password to runsaa_bankquery and it is only valid for one saa_bankquery session.

6. When prompted, enter the one-time password, as provided by Support, intosaa_bankquery.

When using saa_bankquery, Support can guide you as to the commands to enter toinvestigate and resolve your problem. Be ready to read out the relevant responses to eachcommand from the screen.

7. To terminate the execution of saa_bankquery, type:

qThis quits saa_bankquery and returns control back to the Xterm window.

Alliance Access 7.0 - Solaris

164 Installation and Administration Guide

23 Database Recovery

23.1 About Database RecoveryIntroduction

The relational database of Alliance Access can be configured to enhance protection againstmedia failures such as a disk crash or datafile loss.

Database recovery provides functionality that allows an Alliance Access administrator to recoverthe database content, including "live" messages and events. The functionality is subject to thelicence option 14:DATABASE RECOVERY.

Once activated, database recovery maintains ready-to-use backups of database updates onseparate disks (mirror and backup disk). In case of a media failure resulting in the loss of thedatabase content, database recovery provides a single command to restore the database fromthe 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 andbackup disk data. In this scenario, only synchronous replication of the mirror and backupdisks is allowed.

• Partial database recovery

This option must be used when the recovery data set is not guaranteed to be consistent, thatis, typically when it is maintained on a remote site through an asynchronous replication froma primary site. The "partial" recovery restores the database to a consistent state, but possiblywithout the last updates done on the primary site (before switching to the remote site). Anautomatic repair of the recovered database is performed (to prevent duplicate transactions).

For more information, see "Repairing Messages" on page 173.

The main database recovery functions are:

• configure the database for enhanced resiliency, by defining additional mirror and backupdisks.

• schedule database recovery backups. These backups can also be generated on request, tobe included in an external scheduler maintained by the customer.

A recovery backup of the database contains all the data present in the database and noinformation is lost when using these backups for recovery.

• recover the database to its last committed state in case of a major incident affecting thedatabase 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 timerequired to restore data

Database Recovery

30 September 2011 165

Recovery will ignore:

– restored archives (which have been backed up)

– days of traffic backed up (but not removed from the database)

• compress the generated recovery backups: this reduces the size of the recovery backup.

For more information, see "Scheduling Database Recovery Backups" in the SystemManagement Guide.

Note The disks used for the recovery backup disk and the recovery mirror disk must bemounted exclusively so that only the Alliance Access system where the databaserecovery 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 isoften provided by a Storage Area Network (SAN) infrastructure.

The SAN replication must not affect the overall file system performance and is therefore onlypossible 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 degradethe 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 operationsfrom the replicated database. In this scenario, operations are resumed on the standby sitewithout any data loss. The back-office communication is interrupted until the standby site hasbeen 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 faraway from the primary site. In this configuration, an Alliance Access system is set up on theremote site and remains inactive until a failover from the primary site occurs. During normalfunctioning of the primary site, recovery data from the primary site is asynchronously replicatedon the remote site.

With asynchronous replication, the data is not identical between the two sites. There is aninherent time delay before the information generated on the primary site is available on theremote site. The delay is mainly linked to the quality and speed of the connection between thetwo sites. This delay can vary a lot, from a few minutes for the most sophisticated infrastructuresto a few seconds for less advanced configuration. The delay is usually never exceeding half anhour. Due to the asynchronous replication, the data will be inconsistent, as the last updatesdone on the primary site will not be available on the remote site. The amount of information lostwill correspond to the database updates done during the replication delay.

Database recovery allows to restore the database in a consistent state, but missing the lastupdates done on the primary site. This is due to the asynchronous replication of data from theprimary site to the remote site.

This will result in resuming with a database that is not an exact up-to-date image of the livedatabase at the incident.

Alliance Access 7.0 - Solaris

166 Installation and Administration Guide

This situation may generate duplicate transactions. That is, messages just completed before theincident, may re-appear as "live" in the remote database. If not addressed, the "live" messageswill 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, amessage repair operation takes place. For more information, see "Repairing Messages" onpage 173.

Managing recovery backups

From the System Management application, you use the Manage Recovery Backups commandto specify:

• when to generate a full or incremental recovery backup of the database (either based on atime schedule or on disk space usage)

• whether to include archives already backed up (messages and events) in the recoverybackup

• whether to compress the generated recovery backups.

The Manage Recovery Backups command also allows to launch a full or incremental recoverybackup.

For more information about this command, see "Scheduling Database Recovery Backups" inthe System Management Guide.

Disk space monitoring

The Monitoring application provides a System Resources view to check the size of therecovery backup disk containing the recovery backups. For more information, see "The SystemResources Window" in the Daily Operations Guide.

The "Recovery Shutdown - MB" and "Recovery Warning - MB" configuration parameters can beset with relation to disk space monitoring. For more information, see "Classes of ConfigurationParameters - Disk Space" in the System Management Guide.

23.2 Database Configuration for Enhanced ResiliencyDescription

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 mappedto logical database structures called tablespaces. These tablespaces group the databaseentities.

• 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 (thatis, database name, names, and locations of datafiles and redo log files).

Alliance Access provides a database configuration tool (saa_dbconfig) to move redo log filesand tablespaces (hence datafiles) to another physical location.

The activation of the database recovery on Alliance Access enhances further the databaseresiliency and allows a recovery of the Alliance Access database to its last committed state incase of media failure.

Database Recovery

30 September 2011 167

Activate Recovery Mode

The following changes have been performed after the activation of the database recoverymode:

1. After having set up the database for "DB recovery mode", the structure has been changedand is as follows:

D05

4017

6

Live DiskRecovery

Mirror DiskRecovery

Backup Disk

CONTROL02.CTL

REDO01.LOG

REDO02.LOG

REDO03.LOG

DATAFILES

CONTROL03.CTL

REDOM01.LOG

REDOM02.LOG

REDOM03.LOG

ARCHIVEDREDO LOG

FULL BACKUPS

INCREMENTALBACKUPS

CONTROL01.CTL

This database configuration implies that:

– The Recovery Mirror Disk is a fast disk, as it is constantly accessed for writing the redolog files.

– The Recovery Backup Disk is a large-size disk, as it stores the different databasebackups and the archived redo log files.

Note SWIFT recommends using a separate disk controller for the Recovery MirrorDisk 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 orrestored archives of messages, and events

– a backup of the Alliance Access configuration files stored outside the database

Alliance Access 7.0 - Solaris

168 Installation and Administration Guide

4. The database size is monitored, which triggers the generation of full or incrementaldatabase recovery backups when specified disk size thresholds are reached.

The default configuration for the recovery backups can be changed using the ManageRecovery Backups command in the System Management application.

Note No recovery is possible if the Recovery Mirror Disk or the Recovery Backup Diskare damaged, or have missing or corrupted files. As soon as you discover that therecovery disks are damaged, you must deactivate the recovery mode.

For more information on how to activate the database recovery mode, see "Activate theDatabase Recovery Mode" on page 176.

Alliance Access setup on remote site

To use the database recovery functionality on a remote site in case of failure, the followingsteps must be performed:

1. Install Alliance Access on the primary and remote site, with the same licence, version andpatch level, and instance name.

The IP address, host name, operating system level, software installation location and pathsfor 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 automaticallycreate or update the database control file and trigger the replication of the latest files availableon the mirror and backup disks of the primary site to the mirror and backup disks on the remotesite.

Important A partial database recovery up to the last valid transaction is performed. If youwant to use the data from the partial database recovery, then you must set thevalue of the "Message Repair Action" security parameter on the Alliance Access ofthe primary site.

23.3 Database Recovery ProcessPrerequisites

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 arecovery on a remote site (disaster site recovery), the complete information present on thesemirror 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 takesplace must be set up.

For more information, see "Alliance Access setup on remote site" on page 169.

Full recovery process

The full recovery of the Alliance Access database is initiated by launching thesaa_dbrecovery command line tool, using the -r option. For the command to succeed, it ismandatory that the recovery data is complete. This will always be the case when using the local

Database Recovery

30 September 2011 169

recovery data. The full recovery command will be rejected if it is executed against recovery datathat 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 requiredto 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 thedatabase backups, archived redo log files, and on-line redo log files.

For more information on how to start the database recovery, see "Activate the DatabaseRecovery Mode" on page 176.

Note The recovery process assumes that the mirror and backup disks are locallyavailable to be restored on the database. In case of a remote recovery, themirrored control file, on-line redo logs, archived redo logs, and database backupsmust 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-to-date, containing the last committed data. This constraint is particularly important forthe mirrored control file and the on-line redo log files that are constantly updatedduring database activity.

Partial recovery process

The partial recovery of the database is initiated by launching the command line toolsaa_dbrecovery, using the -v option. This recovery mode must be used when the recoverydata is not complete. It is therefore the only option allowed when executing a recovery from aremote site, using recovery data replicated asynchronously from the primary site. During apartial recovery, database recovery will transparently perform the following steps required torecover 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 theremote site, the re-emission of messages already sent on the primary site, database recoveryperforms the following actions:

Alliance Access 7.0 - Solaris

170 Installation and Administration Guide

• Produce a report with the outstanding live message instances following the databaserecovery.

• Add a possible duplication indicator (PDE) to each outstanding live message instancepresent in the restored database.

• Perform on these live message instances the action defined by the value of the securityparameter "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 furtherinvestigation

– 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_dbrecoverycommand.

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 RecoveryProcess" on page 169.

For more information about possible actions on message instances, see "Processing RepairedMessages" on page 175.

23.4 Database Recovery Backups

23.4.1 Database Recovery Backups

Overview

Database recovery backups can be taken if option 14:DATABASE RECOVERY is licensed andif the operator has the function "Manage Rec Backup" of the System Management applicationincluded 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 DailyOperations Guide.

• using the saa_dbrecovery command line tool. For command location and syntax, see"saa_dbrecovery" on page 283.

23.4.2 Creating Database Backups in Recovery Mode

Purpose

Alliance Access provides functionality to schedule a database-recovery backup or to create adatabase-recovery backup manually. A database-recovery backup includes all the data presentin the Alliance Access database. A database is backed up either fully or in increments.

Database Recovery

30 September 2011 171

Contents of a database-recovery backup

If the database and Alliance Access configuration files, which are stored outside the database,have been changed since the last recovery backup was taken, then a database-recoverybackup also includes these files.

The following outlines the contents and results of a database-recovery backup:

Backup type Contents and results

Full The backup on the recovery-backup disk contains all data files includingarchive backups. It also includes archive backups if the Include ArchiveBackups option is selected.

Alliance Access deletes the existing backups of the type:

• incremental backups and the archived redo logs

• full recovery backup(1)

Incremental The backup on the recovery-backup disk contains of all data files for whichchanges have occurred since the last backup was created (any backuptype). It also includes archive backups if the Include Archive Backupsoption is selected.

The existing archived redo logs are deleted.

(1) You can remove the existing full recovery backup before taking a new one, by using the option -e with the

saa_dbrecovery command. You can also use this option to create disk space if there is insufficient disk space to

launch a new full recovery backup.

Include archive backup files

An archive backup is a data file that contains an archive of messages or events. Therefore, adata file may contain archives that were backed up previously but not removed from thedatabase. Also, a data file may contain archives that were restored previously. However, youcan include the archive backups in the database-recovery backup using the Include ArchiveBackups option.

Available disk space

When you perform a database recovery backup, Alliance Access first verifies that the estimatedsize of the recovery backup is less than the available disk space on the recovery backup disk. Ifinsufficient space is available, then the backup operation will fail. This will not affect normalAlliance Access operations.

To create a database backup

You can create backup in either of the following ways:

1. Manually create a database-recovery backup in either of the following ways:

• Use the Manage Recovery Backups command in the System Management application.

For more information, see the Daily Operations Guide, Performing Manual DatabaseRecovery Backups.

• Use the saa_dbrecovery command-line tool. Use this tool if you prefer to rely on theexternal scheduling of these backups instead of relying on the internal Alliance Accessscheduler.

For more information about running this command, see "saa_dbrecovery" on page 283.

Alliance Access 7.0 - Solaris

172 Installation and Administration Guide

2. Schedule database-recovery backups using the Manage Recovery Backups command inthe System Management application.

For more information, see the System Management Guide, Scheduling Database RecoveryBackups.

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 followinga partial database recovery.

When the Alliance Access database is partially recovered on a remote disaster site, it could bethat some FIN, InterAct, or FileAct messages sent or received by Alliance Access on theprimary site, or some FIN network acknowledgements (ACK or NAK) have not been replicatedon the remote disaster site.

Some of these messages would reappear as live and hence, these messages would be resentto SWIFT, which can result in duplicate messages. The message repair functionality helps youto avoid this because the outstanding live messages are identified with possible duplicateemission (PDE) flags, which ensures that potential duplicate re-emissions are identifiedproperly.

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 therecovery process

– to perform the message repair action following a recovery on an Alliance Access withhosted database

You use the saa_msgrepair tool:

• on an Alliance Access with an embedded database to re-launch a message repair operationpreviously interrupted. The tool is used to take corrective actions following the interruption ofmessage repair operation launched by the saa_dbrecovery tool.

• on an Alliance Access with a hosted database to launch a message repair operation after adatabase restore was performed without the saa_dbrecovery tool. In this case, licenceoption 13:HOSTED DATABASE must be present.

For details about the usage of saa_msgrepair, see "saa_msgrepair tool" on page 174.

When the message repair operation is launched, a possible duplicate emission (PDE) indicatoris added to all the outstanding live messages present in the restored Alliance Access database.

Database Recovery

30 September 2011 173

For the live messages that are flagged with PDE, one of the following actions is performed:

• Complete all the outstanding live messages present in the restored Alliance Accessdatabase.

• Route all the outstanding live messages present in the restored Alliance Access databaseinto a dedicated queue, _MP_recovery, for further investigation.

• Leave all the outstanding live messages present in the restored Alliance Access database intheir queue, but flagged with PDE. This will trigger their automatic re-emission to SWIFT or tothe back office.

Note You can resume the normal operations only after the message repair operation hasbeen 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 databaserecovery following a disaster on an Alliance Access hosted on a primary site. Youmust not use it as a support tool to complete outstanding live messages duringnormal operations. If you launch the tool when there is no database recoveryoperation, 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 Configurationmenu.

3. Enter the saa_msgrepair command.

For command location and syntax, see "saa_msgrepair" on page 295.

The outstanding live messages are either completed, routed to _MP_recovery for furtherinvestigation, or left in the routing point.

Alliance Access 7.0 - Solaris

174 Installation and Administration Guide

Note A report on the outstanding live messages is stored in the following file:

<Alliance installation directory>/usrdata/report/saa_msgrepair_<YYYYMMDDTHHMMSS>.xmlwhere YYYYMMDDTHHMMSS is the timestamp when the message repair operationwas started.

Error or confirmation messages are produced upon execution of thesaa_msgrepair tool.

Logging information is stored in the following file:

<Alliance installation directory>/log/saa_msgrepair.<YYYYMMDDTHHMMSS>.outputwhere <YYYYMMDDTHHMMSS> is the timestamp when the message repair operationwas started.

23.5.2 Processing Repaired Messages

Process messages after a partial database recovery

You can find the live outstanding messages that have been repaired following a databaserecovery in the Message Approval application.

If the messages are completed or if there is no action, and if such messages are moved to therepair 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 themessage repair operation.

23.6 The saa_dbrecovery CommandTool availability

The saa_dbrecovery command line tool is available if the database is embedded on AllianceAccess 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 whichAlliance Access is operating.

Database Recovery

30 September 2011 175

The modes available are:

• Activated

• DeactivatedThe 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 Configurationmenu.

3. How do you want to run the saa_dbrecovery tool?

To launch command Then

with parameters go to step 4

without parameters go to step 5

4. Run the command:

saa_dbrecovery -mThe database recovery mode is displayed.

If the mode is Activated, then the command also displays the total disk size and the freedisk space available in MB for the live disk and each recovery disk.

For more information about the saa_dbrecovery tool, see "saa_dbrecovery" onpage 283.

5. Run the command:

1. saa_dbrecovery

2. Select Display Recovery Mode.

3. Select Quit.

The database recovery mode is displayed.

If the mode is Activated, then the command also displays the total disk size and the freedisk 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 thesaa_dbrecovery tool.

For more information about active database recovery mode, see "Database Configuration forEnhanced Resiliency" on page 167.

Alliance Access 7.0 - Solaris

176 Installation and Administration Guide

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 Configurationmenu.

3. How do you want to run the saa_dbrecovery tool?

To launch command Then

with parameters go to step 4

without parameters go to step 5

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 theactivation.

The command displays the total disk size and the free disk space available in MB for thelive disk and each recovery disk.

For more information about the saa_dbrecovery tool, see "saa_dbrecovery" onpage 283.

5. Run the command:

1. saa_dbrecovery

2. Select Activate Recovery Mode.

3. Specify the full path names of the mirror and backup disks.

4. Select Quit.

The command displays the total disk size and the free disk space available in MB for thelive disk and each recovery disk.

Information about the success or failure of the command is recorded in a log file at the followinglocation:

<Alliance installation directory>/log/saa_dbrecovery.YYYYMMDDTHHMMSS.outputwhere 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 thesaa_dbrecovery tool.

Database Recovery

30 September 2011 177

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 Configurationmenu.

3. How do you want to run the saa_dbrecovery tool?

To launch command Then

with parameters go to step 4

without parameters go to step 5

4. Run the command:

saa_dbrecovery -dFor more information about the saa_dbrecovery tool, see "saa_dbrecovery" onpage 283.

5. Run the command:

1. saa_dbrecovery

2. Select Deactivate Recovery Mode.

3. Select Quit.

Information about the success or failure of the command is recorded in a log file at the followinglocation:

<Alliance installation directory>/log/saa_dbrecovery.YYYYMMDDTHHMMSS.outputwhere 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) backupof the database using the saa_dbrecovery tool.

This tool is available if the database is embedded on Alliance Access and if licence option14:DATABASE RECOVERY is present. To create a database backup in recovery mode, thedatabase recovery mode must be activated, as described in "Activate the Database RecoveryMode" on page 176.

Before performing a database recovery backup, Alliance Access estimates the space requiredfor the backup, and then verifies that the recovery backup disk has enough disk space availableto store the database backup.

Alliance Access 7.0 - Solaris

178 Installation and Administration Guide

By default, old database backups are removed after Alliance Access creates a new full-database backup successfully. However, you can specify that Alliance Access removes the oldbackup before creating a new backup.

Disks for backups

The Recovery Backup Disk and the Recovery Mirror Disk must be mounted exclusively to allowonly the Alliance Access system where the database recovery is activated to access thesedisks.

Permissions required

The Alliance Access Administrator account must run the command.

Prerequisite

The Alliance Access database must be running.

To create a database recovery backup:

1. From the System Administration application, select Xterm from the OS Configurationmenu.

2. How do you want to run the saa_dbrecovery tool?

To launchcommand

Create full backup Create incremental backup

withparameters

go to step 3 go to step 5

withoutparameters

go to step 4 go to step 6

3. Run the command:

saa_dbrecovery -c f [-e]Optionally use -e to specify that Alliance Access removes the old backup before creating anew backup.

For more information about the saa_dbrecovery tool, see "saa_dbrecovery" onpage 283.

4. Run the command:

1. saa_dbrecovery

2. Select Create Full Database Backup.

3. Optionally, you can specify that Alliance Access removes the old backup beforecreating a new backup.

4. Select Quit.

5. Run the following command:

saa_dbrecovery -c iFor more information about the saa_dbrecovery tool, see "saa_dbrecovery" onpage 283.

Database Recovery

30 September 2011 179

6. Run the command:

1. saa_dbrecovery

2. Select Create Incremental Database Backup.

3. Select Quit.

Alliance Access 7.0 - Solaris

180 Installation and Administration Guide

24 Handling System FailuresIntroduction

This section describes possible causes of system failure and the procedures to recover theAlliance Access system following such a failure.

The commands described must be run by the Alliance administrator, when logged on to theAlliance Administrator account.

Depending on the nature of the failure, Alliance Access offers different levels of restart andrecovery possibilities:

• If the Alliance Access software has been lost or corrupted, then it must to be re-installed andthe data must be restored from a backup.

• If a disk has failed, then the Alliance Access software must be re-installed and the data mustbe 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 ColdBackup" on page 183.

If ever a disk failure causes the loss or corruption of the operating system, then the operatingsystem 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 beeninstalled and configured for Alliance Access (that is, immediately following Alliance Accessinstallation).

The procedures described in this section must be followed if the Alliance Access servers halt, orfail to start, due to a process failure, power failure, or disk failure. These procedures assumethat, following a hardware failure, the system has been repaired, and that the operating systemis available and has been fully configured for Alliance Access.

24.1 Process FailureDescription

Some Alliance Access server processes may terminate unexpectedly for various reasons:software errors, RPC time-outs, kill process commands issued from the shell, systemmanagement actions, and so on. Whatever the reason, all unexpected process terminations arejournalised 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 atime-out from the server and possibly enter into recovery mode. Following recovery, futureclients will automatically start speaking to the recovered server again.

Handling System Failures

30 September 2011 181

24.2 Power FailureDescription

After a power failure, the disk(s) are checked automatically by the operating system when thesystem reboots.

If a disk error is found, then the recovery scenario is the same as for a disk failure. See "DiskFailure" on page 182.

If no damage has occurred to the disk(s), then the recovery scenario is the same as for aprocess failure. See "Process Failure" on page 181.

24.3 Disk FailureOverview

Following a disk failure, all data held on the damaged disk is either lost or inaccessible. Youmust repair or replace the damaged disk and then restore both the Alliance Access softwareand data from backups.

If you have the licence option 14:DATABASE RECOVERY, then you can restore your databaseto 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 berecovered 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" onpage 151.

You can restore Alliance Access archives in either of the following ways:

• by using the Backup/Restore command from the System Management application (throughthe Access Control application, using an Alliance workstation).

• by typing a command from an Xterm window (available from the OS Configuration menu ofthe System Administration window).

For more information about restoring Alliance Access archives, see "Restoring Data" onpage 151.

Note Before attempting a restore of any data files or archives, check that the backupdirectories exist. For example,

$echo $ALLIANCE_DB

Alliance Access 7.0 - Solaris

182 Installation and Administration Guide

24.4 Recovery on a Different Host Using a ColdBackup

Overview

This section provides instructions for preparing for, and recovering Alliance Access on adifferent host using a cold backup.

If you have the licence option 14:DATABASE RECOVERY, then you can recover the AllianceAccess database to its latest committed state (including live messages) on a remote system.For more information, see "Database Recovery" on page 165.

Where relevant, additional information is provided if you have the licence option 14:DATABASERECOVERY.

24.4.1 Recovery Overview

Purpose

You can choose to recover the entire Alliance Access software on a different host using a "ColdBackup" system. This requires an active system and a backup system.

This recovering the Alliance Access software and its database, and then configuring AllianceAccess to run on a different host using the recovered information.

Overview

1. Normally, Alliance Access runs on the active system from which you can take dailybackups.

2. Upon failure of the active system, you can restore the most recent recovery backups ontothe backup system, and continue working from the backup system. You can take dailyrecovery backups using the backup system.

3. When the active system is running again, you can apply the switch-over procedure in thereverse order to restore the database backup from the backup system onto the activesystem.

24.4.2 Configure the Active System

Prerequisites

On the active system:

1. Install and configure the correct operating system software.

For information about the system requirements, see the Release Letter and "Preparation"on page 13.

2. Install Alliance Access, as described in "Installation" on page 32.

3. Install any required Alliance Access patches.

Make a note of what has been loaded, because the same patches must also be installed onthe backup system.

Handling System Failures

30 September 2011 183

Configure Alliance Access cold backup

1. Customise the active system installation as required (for example, define operators, routing,message partners, and import RMA authorisation data).

2. Configure the active system for SWIFTNet. See Part B, "Configuring for SWIFTNet" onpage 97.

3. Back up the Alliance Access database, see "Backing Up Data" on page 144.

Perform this step regularly, for example on a daily basis.

If you have the licence option 14:DATABASE RECOVERY, then you can configure yoursystem for database recovery instead of performing a database backup:

1. Activate the database recovery mode of the Alliance Access database. For moreinformation, see "Database Recovery" on page 165.

2. Check and possibly change the trigger for the creation of the database recoverybackup. For more information, see "Scheduling Database Recovery Backup" in theSystem Management Guide.

4. Generate a report of your system configuration, using the Report command in the Filemenu of the System Administration application.

Repeat this step whenever you update your system (for example, after installing a newpatch, or changing an IP address of the active system).

5. Continue to work normally with Alliance Access for live operations.

6. Perform regular archives of the Event Journal and Message File. You can scheduleautomatic archiving from the Event Journal and Message File applications respectively, orperform manual archiving from these applications.

7. Perform regular backups of the Event Journal and Message File archives. You canschedule automatic backups from the System Management application, or perform manualbackups from this application.

Notes and recommendations

• For security reasons, the database backup utility does not back up the Message File andEvent Journal. This prevents Alliance Access from processing a message that wasprocessed already, in particular after an old backup was restored.

If you have the licence option 14:DATABASE RECOVERY:

– in case of a full database recovery backup, the content includes all the data present in thedatabase at the time of the backup, except the restored archives or archive backups if theconfiguration explicitly excluded them. The external database and Alliance Accessconfiguration files are also included in these backups.

– in case of incremental database recovery backup, the content includes only the changescompared to the previous full or incremental backups.

For more information, see "Database Recovery" on page 165.

• To back up the archives, you must perform the backup from Alliance Access, which storesthese archives in a release-independent backup format. This allows you to restore thearchives on the current and on any future release of Alliance Access. When you have backedup an archive, the archive may be removed from the database.

Alliance Access 7.0 - Solaris

184 Installation and Administration Guide

• SWIFT recommends that you archive and back up data on a regular basis:

– back up the release tree whenever you upgrade the Alliance Access release or you installan Alliance Access patch

– perform a database backup on a daily basis

– perform archives of the Message File and Event Journal every week

– back up the Message File and Event Journal archives every week.

• Store these backups on separate media, not on the one from which Alliance Access isloaded.

• 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 andoptionally the archive backups must be readily available in the event of a crash of the activesystem.

24.4.3 Configure the Backup System

Overview

You must configure your backup system (install the same operating system software and definepaging space, for example) in the same way as your active system.

Configure Alliance Access on your backup system

1. Install Alliance Access using the same release media as for the active system.

• Assign a different global and local IP address to the backup system. The global IPaddress is the IP address used within your network environment, as it is known toSWIFT.

• Use the same Alliance Access Initialisation and Master passwords as those used on theactive system.

• At this stage, there is no need to configure operators, routing, for example, in AllianceAccess. When needed, Alliance Access configuration data is restored from databasebackups, taken from the active system.

• The $PATH definition for root must be the same for Alliance Access on both systems. Tocheck this, log on as root and type:

echo $PATHThe result of this command must be the same on both systems. If not, then type:

export PATH=$PATH:<missing directory path>

2. After installation, if the range of ports that is defined on Alliance Access for server andmessenger is different from the ports range defined on the active system, then updatethe /usr/swa/alliance_port file. Then, run apply_alliance_ports command to configure thesame range of ports for server and messenger on both primary and the backup system.For more information about using this command, see "TCP Configuration for the AllianceAccess Server" on page 243.

3. If any patches or release upgrades have been applied to the active system, then ensurethat they are also applied to the backup system.

Handling System Failures

30 September 2011 185

4. Restore the database backup from the active system. Restore all data sets, including theSWIFTNet Interface Restore set.

You restore the database using the saa_dbrestore command.

You may disable connectivity when restoring the database. For more information, see"Restoring the Alliance Access Database" on page 153.

To disable the startup of the SWIFT connectivity and Alliance Developers Toolkitapplications on Alliance Access when starting the servers in Operational mode, you canalso prevent the SWIFT Interface Services, SWIFTNet Support Services, or any AllianceDevelopers Toolkit components from starting by following these steps:

1. Start the Alliance Access servers in Housekeeping mode.

2. Run the System Management application.

3. Select Stop Component from the File menu. The Stop Component window appears.

4. Select the component that you want to stop in this window and click Stop . Repeat thisstep 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 anydatabase backup on the backup system.

This procedure restores all of your Alliance Access configuration data, exceptfor the Event Journal and Message File. Empty files are created for theseobjects.

For more information about restoring the database, see "Restoring the AllianceAccess Database" on page 153.

5. Start the Alliance Access servers, to validate the installation.

6. Stop the Alliance Access servers.

7. 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 backupsystem. In this case, use the saa_configconnection tool to import the certificate ontothe backup system. For more information about using this tool, see "saa_configconnection"on page 230.

8. Start the Alliance Access servers.

Important If the active system has a logical terminal configured with automatic login, thenat server startup on the backup system, the logical terminal automaticallyattempts to log in. The same is true for automatic activation of emission andreception profiles.

9. Stop the SIS and SNIS components from the System Management application.

10. Possibly modify the configuration of your backup system for SWIFTNet (see Part B,"Configuring for SWIFTNet" on page 97). For example, this may be necessary if theAlliance Gateway to which the system will to connect is located on another host.

11. Start the SIS and SNIS components from the System Management application.

Alliance Access 7.0 - Solaris

186 Installation and Administration Guide

Note Any changes to ports on the active system must also be made on the backupsystem.

24.4.4 Switch Over to the Backup System

Procedure

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 tocheck the configuration of the backup system. Compare this report with the latest reporttaken 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 levelare correct.

3. Restore your most recent backup of the Alliance Access database (taken from the activesystem) to the same directory on the backup system. Restore all data sets except theSWIFTNet 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 theAlliance Access Database" on page 153.

Note This step restores all of your Alliance Access configuration data, except for theEvent Journal and Message File. Empty files are created for these objects.

If you have the licence option 14:DATABASE RECOVERY, then restore onthe backup system the Alliance Access database from the recovery backupsavailable on the recovery backup disk. Use the saa_dbrecovery tool, asdescribed in "saa_dbrecovery" on page 283.

4. If you use server authentication and a CA certificate was obtained on your active system(using swrpc_keytool), then you may want to use the same certificate on your backupsystem. In this case, use the saa_configconnection tool to import the certificate ontothe backup system. For more information about using this tool, see "saa_configconnection"on page 230.

5. Start the Alliance Access servers.

Important If the active system has a logical terminal configured with automatic login, thenat server startup on the backup system, the logical terminal automaticallyattempts to log in. The same is true for automatic activation of emission andreception profiles.

6. Sign on to Alliance Access (as Supervisor - existing passwords apply) and check whetherthe 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 andEvent Journal archives, as required. Messages and Events which were not included in thearchives cannot be recovered.

Handling System Failures

30 September 2011 187

9. Verify the SWIFTNet connection details of your logical terminals, and of your SWIFTNetemission and reception profiles. For more details, see Part B, "Configuring for SWIFTNet"on page 97.

10. Start the SIS and SNIS components from the System Management application.

11. Use the SWIFT Interface application to connect to the SWIFT network to check theconnection 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 andSelect commands.

12. If you exchange FileAct or InterAct messages, then use the SWIFTNet Interface applicationto check the connection to SWIFTNet.

When all is well, resume normal live operations using your backup system.

Alliance Access 7.0 - Solaris

188 Installation and Administration Guide

25 Replication of Configuration DataOverview

This section describes how to replicate configuration data from one Alliance Access instance toanother instance.

This functionality allows you to:

• validate the configuration changes of a test system before applying these changes on aproduction system.

• easily change the configuration of several production systems that increase the levels ofresilience 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 ReplicationDescription

Alliance Access provides the following command-line tools to replicate configuration data fromone 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 exportand 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 theconfiguration of the target Alliance Access instance.

You run the export tool locally on the source instance and the import tool locally on any targetinstance:

Export tool Import tool

Access

D0

54

01

83

Access Export file

(User modifiable

file - text format)

When you run the export tool, the configuration data that matches the criteria defined in theexport 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 texteditor the export file that the export tool produced. This allows you to customise theconfiguration in the target instance. For example, you can replace Test and Training logicalterminals by Production logical terminals before replicating a test instance configuration into aproduction instance.

Replication of Configuration Data

30 September 2011 189

Parameter file validation

The parameter file used during the export or import operation is validated against schemadefinitions (.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 theAlliance Access instance. For example, the Unit entity indicates all Unit occurrences defined inAlliance 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 forExport and Import" on page 192.

You can use the import and export tools to replicate one or several entities at a time to a targetAlliance Access.

Alliance Access does not support the replication of operational entities, such as, calendarentries, events, or messages, or the entities that it configures automatically either at installationtime or at relicensing time, such as, Destinations.

Sensitive data

Some entities have parameters that may contain sensitive data. You can choose whether toexport sensitive data to the export file. For more information, see "Handling the Export andImport of Sensitive Data" on page 191.

The data in the export file is not protected by a signature. Ensure that the export file is properlysecured, 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 exportand 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 softwareowner, then you must run the tools with the -user, or -application, and -passwordoptions, to provide the user credentials.

For more information about the permissions required to export or import specific entities, see"Entities Eligible for Export and Import" on page 192.

In all of the cases below, the user must have the profile R7.0_Import_Export assigned:

User account Software Owner Profile isdefined?

Specify -user, or -application,and -password

all_adm Y Optional

N Mandatory

Any other OS account (operator) N Mandatory

Alliance Access 7.0 - Solaris

190 Installation and Administration Guide

25.2 Handling the Export and Import of Sensitive DataOverview

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 LocalIf the same entities exist in both the source and the target Alliance Access instance, then youcan update the configuration of the entities in the target instance using the -overwriteparameter with the saa_import command.

Operator passwords

If you export sensitive data using the -exportsensitivedata parameter with thesaa_export command, then the following results are achieved:

Action -exportsensitivedata specified

Result

Export Y The password information (password digest) is added tothe export file.

Import Y The password information (password digest) is added tothe 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 resetthe 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 isLocal, then the Import process varies depending on whether a password is present in theImport 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 resetthe password the next time the operator logs on.

Replication of Configuration Data

30 September 2011 191

If no digest exists for the password, then the Alliance Access instance:

• sets a system-generated password as the value of password for the operator.

• logs the action in the report file with the occurrence reference of the operator entity.

If -exportsensitivedata not specified

Action -exportsensitivedata specified

Result

Export N The password information (password digest) is notexported to the export file.

Import N If a new operator is added, then Alliance Access generatesa password and assigns it to the operator.

If the operator exists in the target instance, then thepasswords are not changed.

25.3 Entities Eligible for Export and ImportFiltering fields

Entity Permission required forexport

Permission required for import

Configuration System Management System Management: Modify ConfigurationParameter

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 (1)

SWIFTNet Interface:

• Open/Print Emission Profile

• Add Emission Profile, and/or

• Modify Emission Profile

• Schedule Emission Profile(2), and/or

• Disable Emission Profile auto

• Enable Emission Profile auto

Event Distribution System Management System Management: Modify Event List

Alliance Access 7.0 - Solaris

192 Installation and Administration Guide

Entity Permission required forexport

Permission required for import

Exit Point Application Interface: Open/Print Exit Point (3)

Application Interface:

• Open/Print Exit Point(3)

• Add Exit Point, and/or

• Modify Exit Point

File Template(5) Mesg Creation Mesg Creation: Add/Mod/Rem Template

Input Channel SWIFTNet Interface: Open/Print Input Channel (4)

SWIFTNet Interface:

• Adopt Input Channel and

• Open/Print Input Channel(4)

Logical Terminal SWIFT Support SWIFT Support:

• Add LT, and/or

• Modify LT

• Set default Live, and/or

• Set default T&T

Logical TerminalDefinition

SWIFT Interface: OwnDestination List (6)

SWIFT Interface:

• Modify LT, and

• Add Action, and/or

• Modify Action, and/or

• Remove Action, and/or

• Enable / Disable Auto Mode, and/or

• Enable / Disable Reconnect , and/or

• Own Destination List(6)

Message Partner Application Interface: Open/Print Partner (7)

Access Control: Files onServer

Application Interface:

• Open/Print Partner(7)

• Add Partner, and/or (8)

• Modify Partner(8)

Access Control: Files on Server

Operator Security Definition Security Definition:

• Add Operator, and/or

• Modify Operator

Operator Profile Security Definition Security Definition:

• Add profile, and/or

• Modify profile

Replication of Configuration Data

30 September 2011 193

Entity Permission required forexport

Permission required for import

Output Channel SWIFTNet Interface Open/Print Output Channel (4)

SWIFTNet Interface:

• Adopt Output Channel and

• Open/Print Output Channel(4)

Reception Profile SWIFTNet Interface: Open/Print Reception Profile RTand Open/Print ReceptionProfile SnF (9)

SWIFTNet Interface:

• Open/Print Reception Profile RT,(9) and/or

• Open/Print Reception Profile SnF

• Add Reception Profile, and/or

• Modify Reception Profile and

• Schedule Reception Profile,(2)and/or

• Disable Reception Profile auto or

• Enable Reception Profile auto

Routing Keyword Routing Routing:

• Add Keyword, and/or

• Modify Keyword

Routing KeywordDefinition

SWIFT Support SWIFT Support:

• Add Keyword, and/or

• Modify Keyword

Routing Rule(10) Routing: Open Routing Point(11)

Routing:

• Open Routing Point(11)

• Add Rule, and/or

• Modify Rule

• Default Rule (12)

Routing Schema Routing Routing:

• Add Schema, and/or

• Modify Schema

SWIFTNet Connection SWIFTNet Support: SNLHandling (13)

SWIFTNet Support: SNL Handling (13)

System Queue System Management System Management: Modify Queue

Unit Security Definition Security Definition:

• Add Unit, and/or

• Modify Unit

Alliance Access 7.0 - Solaris

194 Installation and Administration Guide

Entity Permission required forexport

Permission required for import

User Queue System Management System Management:

• Add Queue, and/or

• Modify Queue

(1) Alliance Access exports or imports only the Emissions profiles that are configured for the explicitly allowed the

services or BICs, or that are not explicitly prohibited for those services or BICs. The R7.0_Import_Export profile is

configured with 'Prohibited: None'.

(2) To import scheduled actions (adding or possibly overwriting existing ones), then the operator must have the

permissions to add actions and/or modify actions and/or remove actions as required by the specific import needs.

The R7.0_Import_Export profile is configured with 'Add / modify / remove actions allowed'.

(3) Alliance Access imports or exports only the exit points that are explicitly allowed (or not explicitly prohibited). The

R7.0_Import_Export profile is configured with 'Prohibited: None'.

(4) Alliance Access imports or exports only the Input Channel or Output Channel occurrences that belong to the

destinations (BIC8) that are explicitly allowed (or not explicitly prohibited). The R7.0_Import_Export profile is

configured with 'Prohibited: None'.

(5) Permissions for file templates are not included in the default R7.0_Import_Export profile. This entity is available

for import and export only from Alliance Access 7.0.30.

(6) Alliance Access imports or exports only the logical terminal (Logical Terminal Definition) occurrences that belong to

the destinations (BIC8) that are explicitly allowed (or not explicitly prohibited). The R7.0_Import_Export profile is

configured with 'Prohibited: None'.

(7) Alliance Access imports or exports only the message partner profiles that are explicitly allowed (or not explicitly

prohibited). The R7.0_Import_Export profile is configured with 'Prohibited: None'.

(8) LAU keys are not imported. Therefore, there are no constraints.

(9) Alliance Access imports or exports only the store-and-forward (SnF) reception profiles that are configured for

explicitly allowed BICs (or for BICs that are not explicitly prohibited). The R7.0_Import_Export profile is configured

with 'Prohibited: None'.

(10) Alliance Access imports or exports only the user-defined routing rules. It does not import or export internal or

default routing rules.

(11) Alliance Access imports or exports only the routing rules that relate to routing points that are explicitly allowed (or

not explicitly prohibited). The R7.0_Import_Export profile is configured with 'Prohibited: None'.

(12) To change the default action for a routing rule, Alliance Access must be operating in housekeeping mode.

(13) Alliance Access imports or exports only the SWIFTNet connections where the Connection Handling permission is

set to 'Y'. The R7.0_Import_Export profile is configured with SNL Handling-Connection Handling set to 'Y'.

Settings for LAU keys

Action Result

Export LAU keys are never exported. Therefore, the LAU keys for Message Partner entities andSWIFTNet Connection entities are not included in the export file.

Import New entity You must define the LAU keys after the import is completedbecause a new entity is added in the target instance withoutLAU keys.

Existing entity LAU keys remain as they are defined already in targetinstance.

Replication of Configuration Data

30 September 2011 195

25.4 Status of Entities Before and After ImportEntity dependencies

Entities have dependencies between themselves or some entities refer to other entities. Forexample, an Operator entity refers to a Profile entity and a Unit entity. A Message Partner entityrefers to a Profile entity. The Message Partner, Operator, and Routing Rule entities refer to Unitentities.

During an import, ensure that the entities that are referred to by imported entities exist in thetarget Alliance Access instance or are imported as part of the same import command and theseentities are in the same export file.

For example, when you import Operator entities, the Units to which the operators belong musteither exist in the target instance or be part of the same export file as the operators beingimported. In addition, the Unit to which an operator belongs must be in an approved state intarget 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 beforethe import and their status after the import is complete.

Alliance Access 7.0 - Solaris

196 Installation and Administration Guide

Any invalid status stops the export or the import process.

Important If Alliance Access cannot add an entity, then it exports only the fields that arerequired to identify the occurrence of the entity in the target instance, and the fieldsthat can be updated.

Entity name Newoccurrencein targetinstance?

Prerequisites Status in target instance

Before import After import

Configuration - ADK Storage parameter is read-only (left unchanged duringimport)

- -

Correspondent Y Country and Correspondent typefields are read-only (leftunchanged during import

- -

Distribution List Y - - -

Emission Profile Y - Disabled Disabled

Event Distribution - Distribution, if equal to Fixed,then it is read-only (leftunchanged during import)

- -

Exit Point Y Assigned Message Partner fieldis read-only (left unchangedduring import)

- -

File Template Y The server must be running inoperational mode.

- -

Input Channel Y Add or update = input channeladoption

The import tool skips updates.

- -

Logical Terminal Y The server must be in running inhousekeeping mode.

- -

Logical TerminalDefinition

- Before update: SIS componentmust be stopped

- -

Message Partner Y - Disabled Disabled

Operator Y - Disabled Approvedstatus:Unapproved

and

Enable status:disabled

Operator Profile Y - No operatorusing thatoperator profilecan be loggedon

All operatorsusing theupdatedoperatorprofile getdisabled andunapproved

Output Channel Y Add or update = output channeladoption

The import tool skips updates.

- -

Reception Profile Y - Disabled Disabled

Replication of Configuration Data

30 September 2011 197

Entity name Newoccurrencein targetinstance?

Prerequisites Status in target instance

Before import After import

Routing Keyword Y - - -

Routing KeywordDefinition

- - - -

Routing Rule Y In some cases, user routing rulesexisting in the target instance aredeleted before adding theoccurrences present in the exportfile.(1)

Before a routing rule is added orupdated, the assigned routingschemes must be inactive, orelse the server must be runningin housekeeping mode.

After add or update, the assignedrouting schemes becomeunapproved.

- -

Routing Schema Y - Any Add:unapproved

Update:remainsunchanged

SWIFTNetConnection

Y Before add or update: SIS andSNIS components must bestopped

- -

System Queue - - - -

Unit Y - - Approvalstatus: un-approved(add) or

remainsunchanged(update)

User Queue Y - - -

(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 ReplicationDescription

You use the export parameter file to specify the entity types and entity occurrences that must beexported.

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.

Alliance Access 7.0 - Solaris

198 Installation and Administration Guide

For more information about the entities that you can export and import, see "Entities Eligiblefor Export and Import" on page 192.

• For each entity type, you can specify additional filtering criteria to export specific entityoccurrences.

– The filtering criteria are optional. If no filtering criteria are specified, then Alliance Accessexports 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 inthe database is always available as a filtering criterion.

Sample parameter files

Two sample export parameter files are provided in the $ALLIANCE/samples directory:

• saaExportParam-Complete.xml, listing all the entities that can be exported and all possiblefiltering criteria

• saaExportParam-Basic.xml, listing all the entities that can be exported, without any filteringcriteria.

You can copy and update a sample export parameter file to match your own export criteria. Thatis, remove some entities that must not be exported or add filtering criteria to some entities torestrict the export. For more information, see "Filtering fields" on page 192.

Syntax of the parameter file

The following is the syntax to use in the parameter file:

<entities> <!-- <Entity_name> --> <entity name='<entity_name>' <filterset> <filter attrib='<Field_name>' value='<field_value>' [op='<operator>'] /> > </entity></entities>You can combine the filtering criteria for several fields by using:

• a logical OR. To do this, specify multiple <filterset> elements.

Example:

<!-- Correspondent --> <entity name='Correspondent'> <filterset> <filter attrib='BIC11' value='SAAABEBBXXX' /> </filterset> <filterset> <filter attrib='Update on BIC Load' value='Yes' /> </filterset> <filterset> <filter attrib='Correspondent Definition' value='External' /> </filterset> </entity>

• a logical AND. To do this, specify multiple <filter> elements.

Replication of Configuration Data

30 September 2011 199

Example:

<!-- Logical Terminal --> <entity name='Logical Terminal'> <filterset> <filter attrib='BIC8' value='SAAABEBB' /> <filter attrib='LT Code' value='A' /> </filterset> </entity>

Also, for each filtering field, you can provide a wildcard value or a set of values, each of themallowing to import an occurrence.

Syntax description

To specify a list of entity or entities to export, and any optional filtering criteria, use the followingelements and attributes in the parameter file:

Element Description Mandatory?

<entities> Denotes the start of the parameter file. Y

<!-- <Entity_name>-->

Comments about a specific entity. N

<entityname='<entity_name>'>

The name of an entity.

The 'entity_name' can be used only once in the file, and itmust be an entity that is eligible for configurationreplication(1).

Y

<filterset> The criteria by which to select the entities to export.

If you specify multiple <filterset> elements, then alogical OR is applied when forming the selection criteria.

A <filterset> cannot have two filters with the sameattrib and op

N

<filterattrib='<Field_name>'value='<field_value>' [op='<operator>']/> >

If you specify multiple <filter> elements, then a logicalAND is applied when forming the selection criteria:

• attrib - a field by which you can filter

• value - value of the field(3).

• op - SQL operator

For a list of values, see "Op values" on page 201.

(2)

</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) You can replicate the configuration data for the entities that are listed in the section, "Entities Eligible for Export and

Import" on page 192.

(2) If <filterset> is used, then <filterset> must include at least one <filter> element.

(3) Use either single (') or double quotes ("), irrespective of the type of data.

Alliance Access 7.0 - Solaris

200 Installation and Administration Guide

Op values

The following table outlines the values of the Op operator that you can use in the parameter filefor exporting or importing data:

operator Description

EQ Equal to (=)

The default is EQ (equal).

GT Greater than (>)

GE Greater than or equal to (>=)

NE Not equal to (!=)

LE Less than or equal to (<=)

LT Less than (<)

LIKE Same as EQ (equal) but you can use wildcards, such as% or _

NOT LIKE Same as NE (not equal) but you can use wildcards, such as% or _

IN The item is contained in a list

NOT IN The item is not contained in a list

Example of parameter file with filtering criteria

The following shows an example of a parameter file with filtering criteria for the entities, RoutingRule, Configuration, and Operator Profile:

<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> <!-- 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>

Replication of Configuration Data

30 September 2011 201

<!-- Operator Profile --> <entity name='Operator Profile'> <filterset> <filter attrib='Name' value='R7.0_SuperKey' /> <filterset conjunction='OR'> <filter attrib='Name' value='R7.0_RMA%' op='LIKE' /> <filter attrib='Name' value='R7.0_MsgEntry' /> </filterset> </entity>

Filtering criteria for correspondents

Use the following filtering criteria to export BICs:

To export 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 toInternal

Correspondents that cannot be modified bythe BIC upload

the Update on BIC Load filter attribute set to No

25.6 Fields Eligible for Export and FilteringDescription

The following table outlines the fields that you can export for each entity in Alliance Access. Italso shows the fields that you can use to filter the exported data.

For more information about how to use the filtering, see "Parameter File for ConfigurationReplication" on page 198.

Fields for export and filtering

You can filter on one or several of these exported fields:

Entity name Exportable fields Filter on field?

Configuration Component ✓

Object ✓

Parameter ✓

Value

Alliance Access 7.0 - Solaris

202 Installation and Administration Guide

Entity name Exportable fields Filter on field?

Correspondent Address

Branch info

City name

Comment

Correspondent type

Correspondent definition ✓

Correspondent status

Country

Institution full name

Institution (BIC11) ✓

Location

POB location

POB number

Preferred language

Profile

Sub-type

Selected integrated applications and their details

Update on BIC load ✓

Distribution List Name ✓

Operators

Selected operators

Selected internal correspondents

SNMP server IP address or port number

Replication of Configuration Data

30 September 2011 203

Entity name Exportable fields Filter on field?

Emission Profile ACTIONS = Action ID, Day profile, Time, Action

Calendar

Delivery mode

Delivery notification queue

Delivery notification required

Input channel

Manual / Automatic mode

Messaging service

Name ✓

Non repudiation required

Retry limit

Requestor DN

Schedule category

Sequence 1: SWIFTNet connection name, Use specificAuthoriser DN, [Authoriser DN]

Sequence 2: SWIFTNet connection name, Use specificAuthoriser DN, [Authoriser DN]

Sequence 3: SWIFTNet connection name, Use specificAuthoriser DN, [Authoriser DN]

Sequence 4: SWIFTNet connection name, Use specificAuthoriser DN, [Authoriser DN]

Service name

Signing required

Use input channel

Window size

Event Distribution Alarm

Component

Configuration management

Distribution

Distribute alarm

Event number ✓

Type

To distribution list

Alliance Access 7.0 - Solaris

204 Installation and Administration Guide

Entity name Exportable fields Filter on field?

Exit Point Assigned to message partner

Display rules allowed

Maximum message age

Modify rules allowed

Name ✓

Processing order

Queue threshold

Selected Valid Routing Targets

Replication of Configuration Data

30 September 2011 205

Entity name Exportable fields Filter on field?

File Template Authorisation Notification ✓

Authoriser DN

Comment

Copy

Direction

File Description

File Info

File Path

(only if File in User Space has the value true)

File In User Space

Header Info

Logical File Name

Name ✓

Non Repudiation

Notification Requested

Overdue Warning Delay

Overdue Warning Time

Possible Duplicate

Priority

Reception Profile

Requestor DN

Responder DN

Request Type

Service Name

Signature Method

Signature Level

Third Party List

Transfer Description

Transfer Info

Unit

User Reference ✓

Input Channel Name ✓

Alliance Access 7.0 - Solaris

206 Installation and Administration Guide

Entity name Exportable fields Filter on field?

Logical Terminal BIC8 = Destination name ✓

LT Code ✓

Master BIC for T&T (for Test and Training LTs only)

MstvId

Window Size

Logical TerminalDefinition(3)

Auto reconnect

BIC8 = Destination name ✓

Delivery subsets

LT Code ✓

Operation mode

Scheduling category, Calendar, Action ID, Day profile,Time, Action

Selection mode

Sequence 1: SWIFTNet Connection name, Use specificAuthoriser DN, [Authoriser DN], Use specific CID SigningDN, [CID Signing DN]

Sequence 2: SWIFTNet Connection name, Use specificAuthoriser DN, [Authoriser DN], Use specific CID SigningDN, [CID Signing DN]

Sequence 3: SWIFTNet Connection name, Use specificAuthoriser DN, [Authoriser DN], Use specific CID SigningDN, [CID Signing DN]

Sequence 4: SWIFTNet Connection name, Use specificAuthoriser DN, [Authoriser DN], Use specific CID SigningDN, [CID Signing DN]

Replication of Configuration Data

30 September 2011 207

Entity name Exportable fields Filter on field?

Message Partner Allowed direction

Always transfer MAC / PAC

Batch file validation

Build unique file transfer reference

Connection method

Description

DETAILS = details of any type of Connection Method

Disposition

Format of original message

Increment sequence number across sessions

Local authentication required

Message emission format

Message in

Message modification allowed

Name ✓

Original message

Profile name

Reply

Routing code transmitted

Selected exit points

Send original message

Transfer PKI signature

Transfer UUMID

Unit to be assigned

Validation error code

Validation level

Alliance Access 7.0 - Solaris

208 Installation and Administration Guide

Entity name Exportable fields Filter on field?

Operator Application

Authentication method

Display password

Full name

LDAP user identifier

Name(4) ✓

Operator Profile(4) ✓

Selected allowed profiles

Selected assigned units

Selected Delegated Destinations

Selected Delegated Profiles

Selected Delegated Units

Unit(4) ✓

Operator Profile All Permission Details (if any)

Name ✓

Selected applications

Selected functions

Output Channel Name ✓

Reception Profile ACTIONS = Action ID, Day profile, Time, Action

Calendar

Delivery mode

Manual / Automatic mode

Name ✓

Queue name

Schedule category

Selected subset names

Sequence 1: SWIFTNet connection name, Use specificAuthoriser DN, [Authoriser DN]

Sequence 2: SWIFTNet connection name, Use specificAuthoriser DN, [Authoriser DN]

Sequence 3: SWIFTNet connection name, Use specificAuthoriser DN, [Authoriser DN]

Sequence 4: SWIFTNet connection name, Use specificAuthoriser DN, [Authoriser DN]

Window size

Replication of Configuration Data

30 September 2011 209

Entity name Exportable fields Filter on field?

Routing Keyword Description

Name ✓

Type

Routing KeywordDefinition

Column range from

Field tag

Line range from

MstvId

Name ✓

Selected messages

Subfield

Alliance Access 7.0 - Solaris

210 Installation and Administration Guide

Entity name Exportable fields Filter on field?

Routing Rule(1) Action on

Assigned schemes ✓

Condition on

Description

Last update timestamp(2) ✓

Message

New instance action

New instance addressee

New instance append intervention

New instance free text intervention

New instance notification type

New instance priority

New instance Routing code

New instance type

New instance Unit

New instance selected valid target point

Routing Point Name ✓

Selected function result

SeqNo ✓

Source instance action

Source instance append intervention

Source instance free text intervention

Source instance notification type

Source instance priority

Source instance Routing code

Source instance selected valid target point

Source instance type

Source instance Unit

Routing Schema Description

Name ✓

Replication of Configuration Data

30 September 2011 211

Entity name Exportable fields Filter on field?

SWIFTNet Connection FileAct port number

FileAct SSL

Name ✓

Hostname

Port number

SSL CA Certificate

SSL Certificate

SSL settings

LAU settings

System Queue Name ✓

Queue Threshold

Modify rules allowed

Display rules allowed

Selected Valid Routing Targets

Maximum message age

Unit Full description

Name ✓

User Queue Display rules allowed

Maximum message age

Modify rules allowed

Name ✓

Selected Valid Routing Targets

(1) Alliance Access exports user-defined routing rules only. It does not export or import internal or default routing rules.

(2) You can use this as a filtering criterion to export only the entities that have a Last update timestamp that meets a

specific condition. You can use a date/time interval condition to export entities that have been last updated during

that date/time interval. For example, you can use it to export only entities that have been updated after a specific

start date/time.

(3) The specified delivery subsets must exist on the target system for the import to be successful.

(4) You can filter on one or several of these fields: Name, Unit, Operator Profile

25.7 Export Configuration DataPrerequisites

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 moreinformation, see "Parameter File for Configuration Replication" on page 198.

Alliance Access 7.0 - Solaris

212 Installation and Administration Guide

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 Configurationmenu.

3. Enter the saa_export command.

For command location and syntax, see "saa_export" on page 287.

The export process starts. The progress of the export process is displayed on the screen asthe different entity occurrences are exported and stored in the export file.

After the export process is completed, the following message appears.

Export completedTotal no. of occurrences exported: 20CONFIGURATION REPLICATION (EXPORT) - ENDStart 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 inthe report file and the Event Journal.

25.8 Import Configuration DataPrerequisites

Before launching the import tool, check the following:

• The Alliance Access server is running in the required mode (operational or housekeeping) forthe import. This prerequisite depends on the entity to be imported.

• During the import, if you want to update some entity occurrences, then check whether theentities are in the appropriate status. For more information about the required status, see"Status of Entities Before and After Import" on page 196.

• If you are using message partners with the Print connection method, before importing theconfiguration data, verify in the export file that the printer name is less than or equal to 40characters.

• An operator profile must be disabled for the import tool to be able to update it. Therefore, nooperator with that profile can be logged on when the tool is launched.

When an operator launches the import tool, that operator must ensure that the export filedoes not contain his/her operator profile. In addition, the tool cannot import the operatorprofile that is assigned to the Software Owner Profile security parameter.

The operator profile that is assigned to the Software Owner Profile security parameter isalways considered as being logged on and must not appear in the import file.

• The target Alliance Access is licensed according to the entities that you import.

Replication of Configuration Data

30 September 2011 213

Important If the import command fails to import any entity occurrence present in the exportfile, then the import process stops. However, the entity occurrences (present in theexport file) that have successfully been imported before the failure are not rolledback.

Therefore, in this case, it is recommended to perform the following steps:

• Back up the database

• Import the configuration data

• If the import process fails after having imported at least one occurrencesuccessfully, 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 Accessinstance according to the input parameters.

Some entities must have a specific status before they can be updated by the import command(for example, Message Partner must be disabled). For more information, see "Status of EntitiesBefore and After Import" on page 196.

For example, if a Routing Rule entity is exported with no filtering or with no Name specified,then the Full indicator is added to the Export file: <ns2:Full>True</ns:Full>. During animport action, if the Full indicator is present in the parameter file, then Alliance Accessreplaces all the routing rules in the target instance with the rules that are defined in the exportfile.

If an entity occurrence is present in the export file and is not present in the target AllianceAccess instance, then the entity occurrence is added into the target instance.

For information about importing sensitive data, see "Handling the Export and Import of SensitiveData" on page 191.

Tip If occurrences cannot be added for a specific entity (for example, a configurationentity), then the import process skips the occurrence and continues with the nextoccurrence.

For more information, see "Entities Eligible for Export and Import" on page 192.

The overwrite parameter

You can force an update to the configuration data in the target Alliance Access instance byusing the overwrite parameter in the import command.

Alliance Access 7.0 - Solaris

214 Installation and Administration Guide

For each entity occurrence present in the export file, and for the corresponding entityoccurrence present in the target Alliance Access instance:

• When the import command is executed with the -overwrite parameter, then the data in theexport file overwrites the data in the target instance even if the values were identical beforethe export process.

• When the import command is executed without the -overwrite parameter, then the data inthe export file for that entity occurrence is ignored or skipped and the occurrence in the targetinstance remains unchanged.

If the Full indicator is present in the Export file (<ns2:Full>True</ns:Full>), then theoverwrite 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 Configurationmenu.

3. Enter the saa_import command.

For command location and syntax, see "saa_import" on page 288.

The entity occurrences are added or updated into the database of the target AllianceAccess instance.

The progress of the import process is displayed on the screen as the different entities areadded or updated. Once the import process is completed, the following messages appear:

Import completedTotal 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 SWIFTNetConnection entities were created in the target instance.

Note If the import fails, check the report file.

25.9 Report File for Configuration ReplicationDescription

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 skippedor exported. It also contains warning messages related to the export, for example, if errorsoccurred while handling sensitive data.

The report file for saa_import contains an exhaustive list of the occurrences that were skippedor imported, that is, added or updated in the target Alliance Access instance. The file alsocontains warning messages related to the import, for example, if errors occurred while handlingsensitive data or the import was not completed successfully.

Replication of Configuration Data

30 September 2011 215

Additional notes about the file:

• The file does not contain any password information.

• The content in the file is overwritten with the new logs created during the export process.

• The file is not deleted when the product is removed.

You can specify a name and location for the report file using the -reportfile parameter.

Name and location of report file

If you do not specify this parameter, then the tool creates a report file in the<Alliance installation> directory with the name:

For export: export<timestamp>.log

For import: import<timestamp>.log

where <timestamp> indicates the date and time at which the command wasrun.

The format for the date is yyyymmdd followed by T and the time hhmmss, basedon the 24-hour format.

Alliance Access 7.0 - Solaris

216 Installation and Administration Guide

26 Integration of Operational Data with Third-Party Applications

26.1 Overview of Operational IntegrationOverview

The Operational Integration functionality provides command line tools to help integrate themonitoring and management of Alliance Access entities into third-party applications.

Operational monitoring

The monitoring tool extracts the monitoring information from Alliance Access based on aspecific list of entities and fields that are provided through a parameter file. The monitoringinformation about the entity occurrences (such as the status of an entity) is stored an XML file.

The information can be transferred to other applications that monitor operations.

Operational management

The management tool performs actions on Alliance Access entities based a list of specificactions that are provided through a parameter file. An exit code provides the results of themanagement actions which the tool performed.

The tool manages operations, such as enabling or disabling a message partner, logging on to alogical terminal, or logging off from a logical terminal. In addition, an operator can launch thetool manually, or from a scheduler application that is running outside Alliance Access.

Entities

The term "entities" refers to all defined occurrences of an entity of a specific type.

For a list of entities, see "Entities Eligible for Operational Monitoring" on page 221 and "EntitiesEligible for Operational Management" on page 228.

26.2 Permissions for Launching OperationalIntegration Tools

Permission required

The Alliance Access software owner (all_adm) or any operating system account (operator)defined in the system can launch the tools.

Software Owner Profile

The permissions for the user that runs the tools depends on the value of the Software OwnerProfile security parameter, as follows:

• Software Owner Profile is defined for all_adm, then it is optional to provide the user, orapplication, name and password.

• Software Owner Profile is not defined for all_adm, then it is mandatory to provide the user,or application, name and password to run the command.

Integration of Operational Data with Third-Party Applications

30 September 2011 217

If any other operating system account launches the tool, then it is mandatory to provide theuser, or application, name and password. Depending on the permissions, the operator (oftype Human or Application) can run the command.

The following table outlines in more detail how the parameter influences the permissions:

Command launcher SoftwareOwner Profileis defined

Specify user, orapplication,name andpassword incommand

User credentials

all_adm Yes Optional • If user, or application, name andpassword are not provided: all_adm

• If user, or application, name andpassword are provided: operator

No Mandatory The user or application name, and thepassword must be provided to run thecommand.

Any other OSaccount (operator)

No Mandatory The user or application name, and thepassword must be provided to run thecommand.

For more information about the Software Owner Profile parameter, see the Security Guide.

26.3 Operational Monitoring

26.3.1 Parameter File for the Monitoring Tool

Purpose

A parameter file contains the entity types and the selection criteria used to define the monitoringscope. The file is in XML format.

You can find a sample parameter file that contains all the entities for operational monitoring inthe directory $ALLIANCE/samples. You can copy and update this file to match your owncriteria.

Validation of the parameter file

The parameter file is validated against XML schema definitions (.xsd files).

These .xsd files for each entity are located in the following directory:

<Alliance installation directory>/bin/xsd

Scope of monitoring

For each entity type, one of the following options are applicable for the selection of entityoccurrences to monitor:

Scope of monitoring Description

All Monitor all occurrences of the entity type are monitored.

Summary Provide the monitoring information in summary format for an entity type.

Summary information is applicable only when monitoring an operatorsession.

Alliance Access 7.0 - Solaris

218 Installation and Administration Guide

Scope of monitoring Description

Exception Monitor all occurrences in exception state for that entity type.

Selection Monitor all occurrences that match the user criteria for the entity type.

Structure of the 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"> <Enabled>false</Enabled> </entity> <!-- Emission Profile --> <entity name="Emission Profile" scope="Selection"> <SessionStatus>ACTIVE</SessionStatus>

Integration of Operational Data with Third-Party Applications

30 September 2011 219

<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>

26.3.2 Extract the Data for Operational Monitoring

Purpose

The monitoring tool saa_monitor extracts data for operational monitoring from AllianceAccess based on a specific list of entities and fields that are provided through a parameter file.The information can be transferred to other applications that monitor operations.

Prerequisites

Before launching the command, ensure that:

• The tool is run locally on the Alliance Access instance that you are monitoring.

Note If you want to launch the tool remotely, then you are responsible for ensuringthat the remote implementation is secure.

• the Alliance Access server is running in Operational mode.

• a monitor parameter file is available, which defines the monitoring scope. For moreinformation, see "Parameter File for the Monitoring Tool" on page 218.

To extract the data

1. Log on to the machine where Alliance Access is installed.

2. From the System Administration application, select Xterm from the OS Configurationmenu.

3. Enter the saa_monitor command (for details, see "saa_monitor" on page 293).

Alliance Access 7.0 - Solaris

220 Installation and Administration Guide

The monitoring information about the entity occurrences is stored an XML file, which iscalled the monitor output file. An exit code provides feedback about the results of thecommand.

Tip You can use the Enter key to stop the monitoring.

Note The monitoring tool uses minimal Alliance Access resources even if it is usedintensively.

26.3.3 Entities Eligible for Operational Monitoring

Entities eligible for monitoring

The following entities are eligible for operational monitoring:

• file transfer

• logical terminal

• message partner

• operator session

• process

• queue

• SWIFTNet profile

• system resource

Integration of Operational Data with Third-Party Applications

30 September 2011 221

Scope of monitoring data

The following table outlines the scope of operational monitoring and the fields that can bemonitored:

Entity name Scope ofMonitoring

Fields forselection ofoccurrences

Monitored fields

Logical Terminal All or Exception orSelection

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 orSelection

Name or status orSession 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

Alliance Access 7.0 - Solaris

222 Installation and Administration Guide

Entity name Scope ofMonitoring

Fields forselection ofoccurrences

Monitored fields

Queue All or Exception orSelection

Name Name

Entries

Reserved

Overdue

Message partner

Status

Age of the oldest message instance inqueue

Exception indicator

In exception timestamp

Throughput information (Overflowcount, entry per second, exit persecond, trend, delay (optional - only incase of flow control)

SWIFTNetProfile

All or Exception orSelection

Name or Enabledor 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 (emissionprofile only)(1)

User-controlled received counter(reception profile only)(1)

Exception indicator

In exception timestamp

SystemResource

All or Exception NA System resource name and type(2)

Value

Exception indicator

In exception timestamp

Integration of Operational Data with Third-Party Applications

30 September 2011 223

Entity name Scope ofMonitoring

Fields forselection ofoccurrences

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

OperatorSession

All NA Operator

Operator type

Remote IP

Expiration

Session type

Summary NA Count of human operator sessions

Count of application operator sessions

Alliance Access 7.0 - Solaris

224 Installation and Administration Guide

Entity name Scope ofMonitoring

Fields forselection ofoccurrences

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 can be used for statistical purposes. For performance reasons, these counters are not updated every

time a message is sent or received. Operator permissions control the resetting of these counters, which can be

performed using the Alliance Web Platform.

(2) The type indicates the type of system resource monitored. The possible values are: DISKSPACE,

RECOVERYBACKUP, DATABASEBACKUP, JOURNALARCHIVE, JOURNALARCHIVEBACKUP,

MESSAGEARCHIVE, MESSAGEARCHIVEBACKUP, and OTHER

Fields descriptions

For more information about these fields, see the following guides:

• Daily Operations Guide, monitoring the Object windows.

• Monitoring Guide

Integration of Operational Data with Third-Party Applications

30 September 2011 225

26.4 Operational Management

26.4.1 Parameter File for the Management Tool

Purpose

A parameter file contains the entity types and the selection criteria used to define themanagement scope. The file is in XML format.

You can find a sample parameter file that contains all the entities for operational management inthe directory $ALLIANCE/samples. You can copy and update this file to match your owncriteria.

Validation of the parameter file

The parameter file is validated against XML schema definitions (.xsd files).

These .xsd files for each entity are located in the following directory:

<Alliance installation directory>/bin/xsd

Scope of management

For each entity type, one of the following options are applicable for the selection of entityoccurrences to monitor:

Scope of monitoring Description

All Monitor all occurrences of the entity type will be monitored

Selection Monitor all occurrences that match the user criteria for the entity type

Structure of the parameter file

<ManageEntities> <!-- Only one entity at a time 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 '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"> <FieldSet> <field name="Name" value="saaabebb_rma"/>

Alliance Access 7.0 - Solaris

226 Installation and Administration Guide

<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>

26.4.2 Manage Alliance Access Entities

Purpose

The management tool saa_manage performs actions on Alliance Access entities based a list ofspecific actions that are provided through a parameter file.

Prerequisites

Before you launch the command, ensure that:

• The tool is run locally on the Alliance Access instance that you are monitoring.

Note If you want to launch the tool remotely, then you are responsible for ensuringthat the remote implementation is secure.

• the server is running in either housekeeping or operational mode, as required for the entitybeing managed.

• a manage parameter file is available, which specifies the entities to be managed. For moreinformation, see "Parameter File for the Management Tool" on page 226

Important Your Alliance Access licensing agreement allows only a certain number ofoperators to use the system concurrently. Running this tool starts an operatorsession with Alliance Access, and this session is included in the count ofconcurrent users of the system.

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 Configurationmenu.

Integration of Operational Data with Third-Party Applications

30 September 2011 227

3. Run the saa_manage command (for details, see "saa_manage" on page 290).

An exit code provides the results of the management actions which the tool performed. Thecommand launches the management action immediately. For example, for the logical-terminal login action, the tool does not wait until the logical terminal is logged in to return anexit code.

If you run the command on several occurrences of a specified entity, and the commandfails for one or more occurrences, then the action is stopped. However, the actions thatwere completed successfully for some are not rolled back.

26.4.3 Entities Eligible for Operational Management

Details

Entity name Occurrenceidentification

Management actions Permission required

Component Name field values Start System Management, Stop, StartComponent

Stop System Management, Stop, StartComponent

LogicalTerminal

All or logicalterminal fieldvalues

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

Emission /ReceptionSWIFTNetprofile

All or Name fieldvalues

Activate SWIFTNet Interface, ActivateEProf / Activate RProf

De_activate SWIFTNet Interface, DeactivateEProf / Deactivate RProf

Enable SWIFTNet Interface, EnableEProf / Enable RProf

Disable SWIFTNet Interface, DisableEProf / Disable RProf

Change_mode SWIFTNet Interface, EnableEProf auto / Disable EProf auto /Enable RProf auto / DisableRProf auto

Reset_Sent (for EmissionProfile only) (1)

Monitoring, Reset EProf Counter(Emission profile) or Reset RProfCounter (Reception profile)

Reset_Received (forReception Profile only) (1)

Monitoring, Reset EProf Counter(Emission profile) / Reset RProfCounter (Reception profile)

Alliance Access 7.0 - Solaris

228 Installation and Administration Guide

Entity name Occurrenceidentification

Management actions Permission required

MessagePartner

All or Name fieldvalues

Enable Application Interface, EnableMessage Partner

Run_session Application Interface, RunSession

Abort_session Application Interface, AbortSession

Start_session Application Interface, StartSession

Stop_session Application Interface, StopSession

Reset_Sent (1) Monitoring, Reset MP Counter

Reset_Received (1) Monitoring, Reset MP Counter

Queue All or Name fieldvalues

Hold System Management, HoldQueue

Release System Management, ReleaseQueue

Operator All or Name fieldvalues

Enable Security Definition, EnableOperator

Disable Security Definition, DisableOperator

(1) When these actions are executed, the value of the counter before the reset is provided in the output.

Information about actions

For more information about these management actions, the System Management Guide or theConfiguration Guide.

Integration of Operational Data with Third-Party Applications

30 September 2011 229

27 Using Command Line ToolsIntroduction

In addition to the System Administration application, you can use a number of tools availablefrom the command line to administer Alliance Access.

27.1 saa_configconnectionPurpose

Using the saa_configconnection tool, you can:

• display, add, or delete IP addresses that the SwRPC layer uses to listen for the clientconnections (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 tool must be run from the Alliance Access Administrator account

• The tool is used to configure the Alliance Access instance that it is packaged with.

Procedure

1. Log on to the machine where Alliance Access is installed.

2. From the System Administration application, select Xterm from the OS Configurationmenu.

3. Enter the saa_configconnection command.

For command location and syntax, see "saa_configconnection" on page 280.

The configuration program starts.

Note If the Alliance Access servers are running when the command is run, then theymust be restarted before your changes become effective.

After a change of IP address

After an Administrator changes the IP address of Alliance Access, you must perform thefollowing actions:

1. Run the saa_configconnection tool.

2. Remove all the RPC interfaces.

3. Remove all the MAS interfaces.

4. Add new RPC and MAS interfaces so that they match the IP address of Alliance Access.

5. Save the changes and quit the saa_configconnection tool.

Alliance Access 7.0 - Solaris

230 Installation and Administration Guide

27.2 saa_systemIntroduction

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 APIsoftware.

Prerequisites

• The Alliance Access bootstrap must be running. See "Starting and Stopping the BootstrapService" on page 240.

• The saa_system commands must be run from the Alliance Access Administrator account.

saa_system tool location

<Alliance Access installation directory>/bin/saa_system

27.2.1 Displaying All saa_system Commands

Introduction

The saa_system command displays all the available commands and the syntax that you mustuse 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 Configurationmenu.

Using Command Line Tools

30 September 2011 231

3. Enter the saa_system command.

For command location and syntax, see "saa_system" on page 303.

27.2.2 Messages and Events Archives

Introduction

You can use the saa_system command to manage your archives. You can create, list, back up,restore, and remove archives.

27.2.2.1 Archiving Messages and Events

Introduction

You may archive messages and events using Alliance Workstation. Alternatively, you can usethe 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 Configurationmenu.

3. Enter the saa_system archive command.

For command location and syntax, see "saa_system" on page 303.

If you are archiving messages, only days that have all messages completed can bearchived. The <NumberOfDays> variable is used to specify the number of days to beretained in the database (minimum 1, maximum 999).

27.2.2.2 Listing Archives

Purpose

The saa_system archive list command is used to list archives present in the database.

Procedure

1. Log on to the machine where Alliance Access is installed.

2. From the System Administration application, select Xterm from the OS Configurationmenu.

3. Enter the saa_system archive list command.

For command location and syntax, see "saa_system" on page 303.

27.2.2.3 Backing Up Archives

Purpose

The saa_system archive backup command is used to back up one or several archives thatare present in the database. Alternatively, you can use the System Management application.

Alliance Access 7.0 - Solaris

232 Installation and Administration Guide

Procedure

1. Log on to the machine where Alliance Access is installed.

2. From the System Administration application, select Xterm from the OS Configurationmenu.

3. Enter the saa_system archive backup command.

You must specify the type of archive, name of the archive, and the directory where thebackup is to be stored.

For command location and syntax, see "saa_system" on page 303.

27.2.2.4 Removing Archives

Purpose

The saa_system archive remove command is used to remove archives from the database.

Procedure

1. Log on to the machine where Alliance Access is installed.

2. From the System Administration application, select Xterm from the OS Configurationmenu.

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 303.

27.2.2.5 Restoring Archives

Purpose

The saa_system archive restore command is used to restore backed up archives to thedatabase. Alternatively, you can use the System Management application.

Note To restore archives created in previous releases of Alliance Access, you must usethe 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 functionalitiesfor 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 Configurationmenu.

Using Command Line Tools

30 September 2011 233

3. Enter the saa_system archive restore command.

You must specify the type of archive and the full path of the backup.

For command location and syntax, see "saa_system" on page 303.

To restore archives made in previous releases of Alliance Access:

• Enter the saa_system archive restoretar command.

You must specify the type of archive, the name of the archive that you want to restore, andthe full path of the tar file containing the archive.

For command location and syntax, see "saa_system" on page 303.

27.2.2.6 Putting Selected Events into a Text File

Purpose

You can use the saa_system readlog command to place events that belong to a specifiedperiod 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 Configurationmenu.

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 303.

27.2.3 Checking the Alliance Access Software Files

Purpose

You can use the saa_system integrity command to verify the integrity of the Alliance Accesssoftware files.

Procedure

1. Log on to the machine where Alliance Access is installed.

2. From the System Administration application, select Xterm from the OS Configurationmenu.

3. Enter the saa_system integrity command.

For command location and syntax, see "saa_system" on page 303.

27.2.4 Listing and Renaming Instances

Purpose

You can use the saa_system instance command to list all the instances on the host, and torename the current instance.

Alliance Access 7.0 - Solaris

234 Installation and Administration Guide

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 Configurationmenu.

3. Enter the saa_system instance list command.

For command location and syntax, see "saa_system" on page 303.

To rename the current instance:

1. Log on as administrator 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 Configurationmenu.

4. Type the command:

su root

5. Enter the saa_system instance rename command.

For command location and syntax, see "saa_system" on page 303.

6. After the running the command successfully, you must activate the change as follows:

1. Log out as root.

2. Log out as the Alliance Administrator.

3. Log on again as the Alliance Administrator.

The current instance is renamed according to the value specified. For more information, see"Instances" on page 245.

27.2.5 Checking the Alliance Access Database and Server

Purpose

You can use the saa_system status and saa_system dbintegrity commands to check thestatus of the Alliance Access database and servers, and also to detect unauthorised updates tothe 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 Configurationmenu.

3. Enter the saa_system status command.

You can view the status of either the database or the server, or both. For commandlocation and syntax, see "saa_system" on page 303.

If the servers are running, then the mode of operation is displayed.

Using Command Line Tools

30 September 2011 235

4. To check the integrity of the database, enter the saa_system dbintegrity command.

For command syntax, see "saa_system" on page 303.

27.2.6 Starting and Stopping the Alliance Access Server

Purpose

This section describes how to use the saa_system command to start, stop or restart theAlliance Access server.

The Alliance Access server must be running before a user can use a client application ofAlliance Access.

Permissions

The operator that runs the saa_system must have administrator permissions on the server.

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 Configurationmenu.

3. Enter the saa_system start housekeeping command.

For command location and syntax, see "saa_system" on page 303.

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 303.

Note When the above command is run, the server processes are started in an order thatrespects interdependencies between them. The script does not return control to theterminal (The command prompt does not appear) until either all server processeshave successfully started or a time-out value is reached.

For information about how to display errors, see "Considerations when Using the"Start Alliance Servers" Command" on page 132.

To stop the server

1. Log on to the machine where Alliance Access is installed.

2. From the System Administration application, select Xterm from the OS Configurationmenu.

3. Enter the saa_system stop command.

For command location and syntax, see "saa_system" on page 303.

Alliance Access 7.0 - Solaris

236 Installation and Administration Guide

To restart the server

You can restart the server by first running the saa_system stop command and then thesaa_system start housekeeping|operational command.

Related alarms

When the servers are started after Alliance Access is installed for the first time, Alliance Accessdisplays an alarm message per live destination, like:

********************* ALARM ********************SUBSET DEFINITION: 'XXXX': INITIALISED TO SYSTEM DEFAULTSuch alarms are logged in the Event Journal as "severe" events. These alarms occur becausethe licensed destinations have no delivery subsets defined for them in Alliance Access.

27.2.7 Starting and Stopping Tracing

Purpose

You can use the saa_system command to start or stop tracing activities.

Prerequisite

To run tracing, you need a configuration file provided by SWIFT.

To start tracing

1. Log on to the machine where Alliance Access is installed.

2. From the System Administration application, select Xterm from the OS Configurationmenu.

3. Enter the saa_system traceset command.

For command location and syntax, see "saa_system" on page 303.

You must enter the directory and file name of the configuration file provided by SWIFT.

To stop tracing

1. Log on to the machine where Alliance Access is installed.

2. From the System Administration application, select Xterm from the OS Configurationmenu.

3. Enter the saa_system tracereset command.

For command location and syntax, see "saa_system" on page 303.

27.3 saa_configbootstrapPurpose

The saa_configbootstrap command is used to configure the Alliance Access Name Serviceand Bootstrap Service to start automatically at system boot time.

Prerequisite

The saa_configbootstrap tool must be run using the root account.

Using Command Line Tools

30 September 2011 237

27.3.1 Starting the Alliance Access Name Service at BootTime

Overview

You can set the Name Service to start automatically after a system boot. This is done by usingthe 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 thissection.

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 280.

The service is added to the Service Management facility.

To revert back to manual startup:

To remove the service from the Service Management Facility type the following:

svcs -l "*saans*"svcadm disable <fmri>svccfg delete <fmri>

27.3.2 Starting the Alliance Access Bootstrap Service at BootTime

Overview

You can set the Bootstrap Service to start automatically after a system boot. This is done byusing 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 thissection.

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 280.

The service is added to the Service Management Facility.

Alliance Access 7.0 - Solaris

238 Installation and Administration Guide

To revert back to manual startup:

Remove the service from the Service Management Facility, by typing:

svcs -l "*saabootstrap*"svcadm disable <fmri>svccfg delete <fmri>

27.4 saa_bootstrapPurpose

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 keptin the system log file and in the file saa_bootstrap.out.<x>, where <x> is a value from 0through 5. This allow for six logs to be kept. This file is created in the log sub-directory of theinstallation 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 thecommand 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 thesystem and user processes. It can be configured to only record a particular level of errormessages, 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 forreview 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 mustsimply 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 whichsaa_bootstrap) in the given file.

3. To activate the new configuration, type:

kill -HUP <pid of syslogd>

Using Command Line Tools

30 September 2011 239

From this point on, the system log file contains messages from saa_bootstrap about the startand stop of the database or servers, whether the database was shut down and automaticallyrestarted, and so on.

27.4.1 Starting and Stopping the Name Service

To start the Name Service:

1. From the System Administration application, select Xterm from the OS Configurationmenu.

2. Enter the saa_bootstrap -nameservice start command.

For more information about the command and its syntax, see "saa_bootstrap" on page 279.

To stop the Name Service:

1. From the System Administration application, select Xterm from the OS Configurationmenu.

2. Enter saa_bootstrap -nameservice stop command.

27.4.2 Starting and Stopping the Bootstrap Service

To start the Bootstrap Service:

1. From the System Administration application, select Xterm from the OS Configurationmenu.

2. Enter the saa_bootstrap start command.

For more information about the command and its syntax, see "saa_bootstrap" on page 279.

To stop the Bootstrap Service:

1. From the System Administration application, select Xterm from the OS Configurationmenu.

2. Enter the saa_bootstrap stop command.

For more information about the command and its syntax, see "saa_bootstrap" on page 279.

27.5 Alliance CIFA ExportDescription

Using the script $ALLIANCE/BSS/bin/$ARCH/export_cif, you can export selectedinformation from the Correspondent Information File application (CIFA) to the screen (stdout) orto 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 | -hWhere the following is the output of the -h help option:

Alliance Access 7.0 - Solaris

240 Installation and Administration Guide

-c : all correspondent (corr) info-h : helpThe output of the command is sent to stdout by default, any errors are sent to stderr. It is up tothe user to redirect the output to a file. This can be achieved using the redirect operator asfollows:

export_cif -c > correspo.txtThis creates the text file correspo.txt and it contains all information contained in theCorrespondent File. The exported information is formatted with each record separated by ablank line. As an example, here is the export layout for the Correspondent File (CORR):

BIC Code : <corr_X1>

27.6 TCP/IP Service FilesDescription

Alliance Access relies on TCP/IP settings which are contained in operating system files and theAlliance Access database.

The following operating system files are maintained by operating system commands and/orAlliance 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 clientconnections (Alliance Workstation, ADK-based clients, and CAS MXA)

• Allowed Workstations - specifies which SwRPC layer clients (Alliance Workstation and ADK-based clients) that Alliance Access accepts.

Tip Normally CAS MXA creates TCP/IP sockets with the IP address associated withthe command "hostname". In a cluster environment, this may causecommunication problems as the TCP service would only listen to the networkadapter with address <hostnameIP>. 5101. If you have such a problem, thenspecify the correct IP address as the very first entry in RPC interfaces using thesaa_configconnection tool.

When using the interactive connection method to connect to a host, service names arereferenced by message partner profiles using the term Connection Identifier. For moreinformation about the /etc/services file and message partner profiles, see "Managing MessagePartner Profiles" in the System Management Guide.

27.7 The Reset Message Partners (reset_mp) ScriptOverview

The reset_mp script is used to reset and disable a message partner. The tool is password-protected and you must contact Support to use it.

The tool must only be used when the Alliance Access servers are not running.

Using Command Line Tools

30 September 2011 241

To start the tool and reset a message partner:

1. From the System Administration application, select Xterm from the OS Configurationmenu.

2. Enter the reset_mp command.

For command location and syntax, see "reset_mp" on page 278.

3. You are then required to enter a user name and password. You must be an Alliance userthat 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.

Alliance Access 7.0 - Solaris

242 Installation and Administration Guide

28 TCP Configuration for the Alliance AccessServer

28.1 Port ConfigurationDescription

The TCP configuration defines the ports used by the Alliance Access servers in thealliance_ports file (located in /usr/swa). A base port and range of ports for each AllianceAccess 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 AllianceAccess. The Alliance swa_boot process (previously swa_rpcd) has only one port. The defaultnumber 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 usedin /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 Accessthrough 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

TCP Configuration for the Alliance Access Server

30 September 2011 243

server SAA_LIVE 48200

48201

48202

48203

48204

48205

48206

messenger SAA_LIVE 48300

48301

48302

messenger SAA_TEST 48400

48401

48402

The Alliance Administrator can modify this file if other default base_ports (<base_portN>) mustbe used for the Alliance Access servers. If the swa_boot port is changed (default 48009), thenthe configuration for each Alliance Workstation connected to the server must be changed toselect this new port.

If the file is changed by the System Administrator, then the apply_alliance_ports tool mustbe run to update the operating system files. The ports for the servers and swa_boot must not bechanged.

Using firewalls

If you use a firewall blocking port between Alliance Access and Alliance Workstation, then checkbefore the installation whether the "default ports" are free.

If they are, then you can already configure these ports on the firewall to allow an AllianceWorkstation to connect to the Alliance Access server.

28.2 apply_alliance_ports ToolIntroduction

After any change to the alliance_ports file, the operating system files (/etc/ services) must beupdated with the new ports allocations using the apply_alliance_ports tool (locatedin /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>= the instance

Alliance Access 7.0 - Solaris

244 Installation and Administration Guide

Note that in a cluster environment, the apply_alliance_ports tool must be run on eachnode of the cluster to update /etc/services.

Note The comment # SWIFTAlliance_SWRPC is a reserved comment and must onlybe used for apply_alliance_ports.

28.2.1 Handling Multiple Network Cards - IP AddressConfiguration

Description

By default, only one IP address is used by the Alliance Access servers for RPC communicationand is obtained at the startup of the servers. In a system with multiple network cards (which usedifferent IP addresses), or a UNIX cluster environment, the default behaviour can be overruledby running the "saa_configconnection" tool.

For a system with multiple network cards, you must run the "saa_configconnection" tool todeclare 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 thesystem administrator's responsibility to ensure that the IP address is removed from theconfiguration.

28.2.2 Instances

Description

When an instance is created or renamed, the alliance_ports file is updated to add or renamethe instance, and the apply_alliance_ports tool is run.

If an Alliance Access instance is removed, then the Uninstaller program automatically removesthis instance from the alliance_ports file.

If an Alliance Access instance is renamed, then the swa_boot and saa_bootstrap processesmust be stopped and restarted.

28.2.3 Installation

Description

The installation process adds an entry in the alliance_ports file for the new Alliance Accessinstance. If the file does not exist, then it is created.

TCP Configuration for the Alliance Access Server

30 September 2011 245

29 General TroubleshootingIntroduction

As with many complex applications, if one file or program is altered in any way, the completesystem may not operate correctly or even at all.

Alliance Access provides the following facilities to assist with troubleshooting, should problemsarise:

• The Alliance Configuration Report

The Report facility produces a formatted report on the current configuration of your AllianceAccess system. This facility is particularly useful for remote diagnostic purposes. Shouldproblems arise, the script may be run and the resulting report faxed to Support to verify thatthe 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 signon to Alliance Access and use the Event Journal application. JOURNAL_query may also beused for diagnostic purposes if the Alliance Access user interface is unavailable or cannot bestarted.

• Pre-installation Check

The checkhost command is used before an installation to check the software andresources that are currently available on the customers machine. All hardware and softwarechecks associated with the installation procedure are carried out by this script and the resultcan be made available as a text file. Customers can fax or e-mail this text file to Support tooutline the resources of their machine in cases of performance or installation problems.

For information about invoking this script, see "Checking Your System Configuration" onpage 93.

• Software Integrity Check

The saa_system integrity command checks whether the Alliance Access software fileshave been altered since installation.

29.1 The Alliance Configuration ReportOverview

The Report command, from the File menu of the System Administration application, allows youto generate a system status report. This report, which may be output to screen, file or printer isuseful for diagnostic purposes and may also be used to record the current status of yoursystem.

To generate a configuration report:

1. Log on to the Alliance Administrator account, using the current password. The main windowof the System Administration application will appear.

2. Select the Report command from the File menu.

Alliance Access 7.0 - Solaris

246 Installation and Administration Guide

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 mainwindow of the System Administration application. Use the scroll bars to view thecontents of the report.

• Printer: The text of the report will be sent to your printer. You will be asked to enter thename of the printer. Printed reports are formatted for A4-sized paper, suitable for FAXtransmission. If problems arise, use this option to generate a status report and fax it toSupport for first-level diagnosis.

• File: The text of the report will be written to a file. You will be prompted to enter the pathname 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 thesystem. A check is also made to diagnose any patch mismatches.

• File Systems: Details related to the file systems currently defined are included in thereport.

• Licensed Options: Details related to the packages, servers and licensed destinationsdefined at licensing are included in the report.

• Hardware Configuration: Details related to hardware such as disk drives, networkadaptors, and so on are included in the report.

• TTY Configuration: Details relating to the status of the serial ports are included in thereport (only if your system has such ports).

• Alliance Release: Details of the installed Alliance Access release are included in thereport.

• 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.

General Troubleshooting

30 September 2011 247

29.2 The JOURNAL_query FacilityOverview

Alliance Access maintains an audit trail of all significant actions performed by Alliance Accessusers 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 activitymay be monitored. All events are categorised and may be defined as security events or asalarms.

Within Alliance Access, a dedicated application (the Event Journal application) is used to querythe Event Journal and to generate reports. However, the Alliance Access system administratordoes not normally have access to the applications within Alliance Access and, even if he has, ifa problem has occurred which makes the user interface unavailable, the Event Journalapplication cannot be used.

The JOURNAL_query facility enables the Alliance administrator to monitor the Event Journalfrom 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 mainwindow 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 EventJournal. The results of this search may be directed to the scrolling text area of the mainwindow, to a printer or to a file.

3. In the Start Date/Time and End Date/Time fields, enter values to determine the scope ofthe search. For example, if a problem has occurred recently then request all events whichhave occurred in the last 15 minutes. Dates must be entered in the form DD/MM/ YY andtimes as hh:mm:ss, using 24-hour notation. Where no dates or times are entered, thecurrent day from midnight onwards is taken.

Alliance Access 7.0 - Solaris

248 Installation and Administration Guide

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 printeror 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 fieldvalue is used to navigate through the output when using the Next and Previous buttons. Inthe Number of Records field, select the number of records you want to skip when usingthe commands Next and Previous.

Where no value is specified here then the default value of '1' is taken. The informationextracted from the Event Journal is held in a buffer. All operations using the commandsNext and Previous will begin scrolling through the buffer with reference to the number ofrecords specified here.

6. The Search Filter field allows you to input-specific criteria so as to locate particular types ofevent. This field may be used ONLY in consultation with Support and when specificinvestigations are conducted.

7. Events are recorded in the journal in a 'plate-stack' manner, where the latest event isalways situated at the top of the stack. Consequently, the earliest event will always befound at the bottom of the stack. The Event Journal is a large file and even a simple searchcan 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 thewindow or to the bottom (oldest) event

• Use the Next and Previous buttons to jump backwards or forwards by the number ofevents specified in the Number of Records field.

8. When operating under the direction of Support, use the Search command to start aninterrogation 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 searchby default. This can be found directly beneath the search window.

Note This command is not available when Output To is set to 'Screen' or 'Print'.

General Troubleshooting

30 September 2011 249

Alliance Access 7.0 - Solaris

250 Installation and Administration Guide

Part D

Appendices

Part D - Appendices

30 September 2011 251

Alliance Access 7.0 - Solaris

252 Installation and Administration Guide

Appendix A

Setup Recommendations

A.1 Alliance Access for Service BureauxOverview

Alliance Access provides functionality to support a multi-banking environment for ServiceBureaux and includes:

• extended data segregation, with the capability to allow institutions served by a ServiceBureau 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 Bureaucan create and maintain their own set of operators

• the ability to restrict message text viewed in the event log, allowing a Service Bureau tocontrol 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, andRouting 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 (thatis, Message Partner, Exit Point, or Routing Point) for the operator concerned.

For details about setting up permissions, see "Managing Alliance Access Security" in theSystem 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 ofOperator Profiles, Units and Licensed Destination, which are specific to the institutionconcerned. The "local" security officers can be used by the institution to create and maintaintheir own set of operators, by delegating rights, and permissions which belong to their restrictedsubset only.

For details about setting up local security officers, see "Setting Up Local Security Officers" in theSystem Management Guide.

Appendix A - Setup Recommendations

30 September 2011 253

Restrict message text viewed in event log

The Service Bureau can also control whether the text of messages is journalised in the eventlog or not. This can be used to ensure that the text of messages of an institution is not viewableby 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 startwith 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 thenames of "allowed" or "prohibited" entities.

• Security Definition application

The Service Bureau gives the operators of the served institution, the permissions to managetheir 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 itsown 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 UserDefined Queue (UDQ), for example, AAAAUDQ for institution AAAABEBB and BBBBUDQfor 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 assignExit Points to a Message Partner or a Message Partner to an Exit Point according to thelist 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-specificUDQ, based on the message receiver (BIC8).

– Operators of the served institution, define the routing of their own UDQ (optionally this canbe done by the Service Bureau as well). Messages arriving in an institution-owned UDQare routed according to the specific requirements of the served institution.

See "Message Routing" in the System Management Guide for more information.

Alliance Access 7.0 - Solaris

254 Installation and Administration Guide

A.2 Alliance Access as Standalone Message Entryand 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 XML-based messages. This setup requires that the standalone Alliance Access server is licensedwith option 07:STANDALONE REC. This licence option cannot be ordered individually. It is partof a specific licence package, allowing the configuration of a dedicated Alliance Access systemfor standalone message entry/repair next to a master Alliance Access system.

Within such a configuration, the standalone Alliance Access server has no connectivity toSWIFT. This allows for the segregation of the manual message entry/repair activity from thestraight 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 manualentry and repair of MT and XML-based messages, and which can also receive messagesthrough batch input sessions

• a master Alliance Access system connected to SWIFT.

Both Alliance Access systems must use WebSphere MQ to exchange MT and XML-basedmessages. WebSphere MQ connectivity is provided by the native Alliance Access WebSphereMQ 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 systemrequires licence option 13:MQ HOST ADAPTER.

The following figure summarises the supported architecture of such a configuration.

Appendix A - Setup Recommendations

30 September 2011 255

Figure 1 - Standalone message entry and repair configuration

D05

401

67

SWIFT

Back-Office

Central Middleware Infrastructure

TR_REC

MQ Host

Adapter

TR_REC

MQ Host

Adapter

StandaloneAlliance Access 1

StandaloneAlliance Access 2

MQ Host

AdapterMaster Alliance Access

system(s)

XMLv2 XMLv2

XMLv2

A.2.1.1 Message Creation

Overview

The primary function of a standalone Alliance Access system is to support the manual creationof MT and XML-based messages. The messages created on the standalone Alliance Accesssystem are handled by the central middleware infrastructure like any other messages created byback-office applications.

Moreover, messages can be input in the standalone Alliance Access system through the variousadapters available: File Transfer or MQ Host Adapter, for example.

To support the manual creation of MT and XML-based messages, along with reconciliation ofthe network transmission notifications generated on the master Alliance Access system, astandalone 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 Accesssystem

Alliance Access 7.0 - Solaris

256 Installation and Administration Guide

• the reception of network transmission notifications from the master Alliance Access systemover the native MQ Host Adapter, and their reconciliation with the corresponding inputmessage

• the reception of delivery notifications over the native MQ Host Adapter, and theirreconciliation 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 samelogical terminal code and the same message syntax table assigned.

The reconciliation, on the standalone Alliance Access system, of the received deliverynotification with the input message initially sent requires that the LT code of the inputmessage and the LT code of the delivery notification are identical.

Note The transmission notification generated on the master Alliance Access is a newmessage instance of type transmission notification.

The delivery notification sent from the master Alliance Access to the standaloneAlliance Access is actually a delivery notification system message, as receivedfrom the network.

A.2.1.2 Message Repair

Overview

The standalone Alliance Access system also supports the repair of messages created by back-office applications, when NACKed by SWIFT. In this configuration, the messages created by theback office and that were NACKed, can be forwarded to the standalone Alliance Access systemfor manual repair, and then sent back to the master Alliance Access system.

To support this repair function, the standalone Alliance Access system includes the followingfunctionality:

• the reception of a network transmission notification that includes the details of the originalmessage over the native MQ Host Adapter

• the creation of an input message, on reception of the above transmission notificationcontaining 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 anacknowledgement 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 masterAlliance Access system to the standalone Alliance Access system.

• it introduces a dedicated logic to reconcile the received transmission notifications with themessages created on the standalone Alliance Access system. If the reconciliation fails for anegative 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.

Appendix A - Setup Recommendations

30 September 2011 257

A.2.2.1 Use of the "OTHER" Network

Overview

The default Alliance Access routing rules make use of the "Route To Addressee" action to routethe messages to the preferred correspondent network, which in most cases is the SWIFTnetwork, 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 partnerthat will communicate with the master Alliance Access system. Multiple exit points may exist ifcommunication 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 isinstalled, the "OTHER" network is selected as preferred network, instead of the SWIFT andSWIFTNet networks. Similarly, when a new correspondent is defined manually in theCorrespondent 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 uniqueexisting "_OI_to_OTHER" queue. The only main routing change consists in defining theappropriate routing rules on the "_OI_to_OTHER" queue to send the message to theappropriate 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 acknowledgementfrom the SWIFT network is received very quickly: the 'Waiting Ack' state is a very short transientstate.

With a standalone Alliance Access system, the "Waiting Ack" state may last much longer. If thenetwork transmission is held in the master Alliance Access system or, following a configurationerror, is not routed back to the standalone Alliance Access system, then this "Waiting Ack" statecould last forever, until a manual action is taken.

To cope with this potentially long "Waiting Ack" state, the standalone Alliance Access systemuses the "_AI_waiting_ack" queue. This queue holds the messages waiting for the networktransmission notification from the master Alliance Access system.

A routing rule must be added to the exit point associated with the WebSphere MQ messagepartner so that the messages get routed to the "_AI_waiting_ack" queue after being sent to thecentral 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 inthe standalone Alliance Access system to route the messages to the master Alliance Accesssystem. However, it does not check for the existence of a valid RMA authorisation at messagecreation. This is linked to the fact that the OTHER network is a user network and not a SWIFTnetwork.

To support RMA lookup, assuming that the relevant RMA authorisations are present in thestandalone Alliance Access system, the security configuration parameter "Check authorisationexist" is used. When the value of this parameter is set to "Yes", the check for the existence ofan RMA authorisation is performed at message creation, even for correspondents having"OTHER" as network.

Alliance Access 7.0 - Solaris

258 Installation and Administration Guide

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 transmissionnotification 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 impliesthe following:

• the support of the emission of the input message created on the standalone Alliance Accesssystem

• the reconciliation of the transmission notification received from the master Alliance Accesssystem with the created message.

For information about the optional processing of a network delivery notification received fromthe master Alliance Access system, see "Reception of Delivery Notifications" on page 263.

The following diagram gives an overview of the steps involved in this scenario for the creation ofan MT or an XML-based message.

Appendix A - Setup Recommendations

30 September 2011 259

Figure 1 - Message emission flow

D0540168

_OI_to_OTHER

StandaloneAlliance Access

MQ Host Adapter

XMLv2

Message

Back-Office

Application

Alliance

Workstation

1

1

Alliance

Web Platform

1

_AI_waiting_ackEP1 toMaster

XMLv2

Transmission

Report

MQ queueMQ queue

2

33

34

4

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 theusual queues _SI_to_SWIFT or _SI_to_SWIFTNet as this system has no connectivity toSWIFT. 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.

Alliance Access 7.0 - Solaris

260 Installation and Administration Guide

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 forprocessing by the central middleware which routes this message for processing by themaster 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 264

Create message partners "Message Partners" on page 264

Define routing rules associated to the exit points "Exit Points" on page 264

Update routing of _AI_from_APPLI "_AI_from_APPLI" on page 266

Update routing of _OI_to_OTHER "_OI_to_OTHER" on page 269

A.2.3.1.2 Reception of Network Transmission Notifications

Overview

When the input messages are queued in the routing point _AI_waiting_ack, they expect apositive transmission notification before being completed. The transmission notifications transitthrough 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 localrejection (for example, if there is no authorisation, or if the reception of the messages inApplication 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 AllianceAccess system generates a transmission notification (including original message details)which is queued in a specific WebSphere MQ queue for processing by the standaloneAlliance Access system.

The message partner associated with the WebSphere MQ queue containing the transmissionnotification reconciles it with the input message present in the _AI_waiting_ack queue basedon the original details it contains, and completes the message or puts it in the _MP_mod_textqueue 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 264

Update routing of _AI_waiting_ack "_AI_waiting_ack" on page 265

Update routing of _AI_from_APPLI "_AI_from_APPLI" on page 266

Appendix A - Setup Recommendations

30 September 2011 261

A.2.3.2 Message Repair Flow

Overview

The flow where messages originally created in back-office applications are repaired in thestandalone Alliance Access system implies the creation of an input message based on originalmessage details included in the transmission notification received from the master AllianceAccess system.

The following diagram gives an overview of the steps involved in this scenario for the repair of amessage.

Figure 2 - Message repair flow

D0540169

_OI_to_OTHER

StandaloneAlliance Access

MQ Host Adapter

XMLv2

Message

EP1 toMaster

XMLv2

Transmission

Report

MQ queueMQ queue

_AI_from_APPLI

1

1

_AI_waiting_ack

2

_MP_mod_text

The triggering event for this flow is the presence within a WebSphere MQ queue of a negativetransmission notification for a message which the standalone Alliance Access system has neverbeen 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 thetransmission notification and after failing to reconciliate against a message, creates aninput message based on the original details it contains.

2. The message is routed to the _MP_mod_text queue to allow its modification before re-emission. The emission steps are as described in "Message Entry Flow" on page 259.

The required configuration tasks are the same as in "Message Entry Flow" on page 259.

Alliance Access 7.0 - Solaris

262 Installation and Administration Guide

A.2.3.3 Reception of Delivery Notifications

Overview

A standalone Alliance Access system can receive delivery notifications from the master AllianceAccess system. It stores them and can route them to the existing _TR_REC queue forreconciliation with a local input message instance.

The following figure gives an overview of the processing related to the reception of deliverynotifications within the standalone Alliance Access system.

Figure 3 - Reception of delivery notifications

D0540170

StandaloneAlliance Access

MQ Host Adapter

_AI_from_APPLI

XMLv2

Transmission

Report

MQ queue

_TR_REC

1

1

2

The triggering event for this flow is the presence within a WebSphere MQ queue of a deliverynotification 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 deliverynotification.

2. The message is routed to the _TR_REC queue to allow the reconciliation with the inputmessage.

To cater for this scenario, the following configuration tasks must be performed:

Task See section

Create message partners "Message Partners" on page 264

Update routing of _AI_from_APPLI "_AI_from_APPLI" on page 266

Appendix A - Setup Recommendations

30 September 2011 263

A.2.4 Configuration of the Standalone Alliance AccessSystem

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 pointsfor further processing by the associated message partner.

For details about creating exit points, see "Managing Exit Point Profiles" in the SystemManagement Guide.

A.2.4.1.2 Message Partners

Overview

As the supported configuration for a standalone Alliance Access system is based on the nativeMQ Host Adapter, you must create the message partners with connection method 'WebSphereMQ' and data format 'XMLv2' revision 2, or above.

The emission message partner associated with the exit point sends the messages present inthe exit point to the defined WebSphere MQ queue.

The reception message partners process transmission or delivery notifications queued indifferent WebSphere MQ queues. If you want a repair input message created in case thereconciliation of a negative transmission notification fails, then you must activate the "Createrepair message" option of the message partner.

For details about creating message partners, see "Managing Message Partner Profiles" in theSystem 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_ackqueue 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 theSystem Management application to make it visible and allow modification of rules.For more information, see "Queue Details Window - Routing Info Tab" in theSystem Management Guide.

• From the Queue view in the System Management application, open the details ofEP1ToMaster

• From the Routing Info tab, move _AI_waiting_ack to the Selected list box as valid routingtarget

Alliance Access 7.0 - Solaris

264 Installation and Administration Guide

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 transmissionnotification:

• when a positive transmission notification is received, the original message instance must becompleted

• when a negative transmission notification is received, the original message instance must berouted to an investigation queue such as _MP_mod_text.

These routing rules are applied following a successful reconciliation of the receivedtransmission 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

Sequence number 200

Description negative transm. notification

Appendix A - Setup Recommendations

30 September 2011 265

Condition on Message

Message (Network_delivery_status = Network_Aborted)

or (Network_delivery_status = Network_N_A)

or (Network_delivery_status = Network_Nacked)

or (Network_delivery_status = Network_RejectedLocally)

or (Network_delivery_status = Network_TimedOut)

or (Network_delivery_status = Network_WaitingAck)

Action on 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 usingMessenger 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 properlyrouted to the _OI_to_OTHER queue

• route to the _MP_mod_text queue the input messages created in the standalone AllianceAccess system following a repair operation

• route the delivery notifications of MT and XML-based messages to the _TR_REC queue forthe 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 asvalid routing targets.

Define routing rules to cater for the following:

• The input messages (created by specific input message partners) are routed to the_OI_to_OTHER queue.

Sequence number 30

Description input to _OI_to_OTHER

Condition on Message

Alliance Access 7.0 - Solaris

266 Installation and Administration Guide

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 thathave processed the message for input in the standaloneAlliance 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 thetransmission notification coming from the master AllianceAccess system.

Other criteria, such as Creating_mpfn orCreating_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-officeapplications, but which failed the middleware checks.

• The delivery notifications of MT messages are routed to _TR_REC to allow reconciliation withthe original input messages.

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')

Appendix A - Setup Recommendations

30 September 2011 267

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 allowreconciliation with the original input messages.

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

Alliance Access 7.0 - Solaris

268 Installation and Administration Guide

A.2.4.2.4 _OI_to_OTHER

Overview

The user-defined queue _OI_to_OTHER is used to gather all the messages input eithermanually 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 definedrouting criteria. The main reason for using this routing point is to avoid changing the preferrednetwork of the correspondents defined in the Correspondent File (if the Route to Addresseerouting 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 basedon message content (for example, for a given Sender LT toone master Alliance Access system, for another Sender LT toa 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 routedto the _OI_to_OTHER queue by default, the configuration parameter "Preferred Order" definedin 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 queueas 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 routingtarget.

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 AllianceAccess system must forward the following to the standalone Alliance Access system:

• negative transmission notifications associated to messages originating from the standaloneAlliance Access system

• transmission notifications associated to messages created on the back-office applications

Appendix A - Setup Recommendations

30 September 2011 269

• delivery notifications associated to messages created on the standalone Alliance Accesssystem.

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 AllianceAccess system

• TRANStoAloneEP1, to collect all the transmission notifications to be sent to the standaloneAlliance 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 alsoincluded in the XMLv2 TransmissionReport.

For details about creating message partners, see "Managing Message Partner Profiles" in theSystem 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 deliverynotifications are not routed to the standalone Alliance Access system, but the delivery systemmessages are.

As these notifications must be delivered in specific exit points, the routing for the followingrouting 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 routingof these transmission and delivery notifications.

As on any Alliance Access system, the modification queues (such as _MP_mod_transmis) onthe master Alliance Access system must be monitored to ensure that all the traffic is properlysent to and received from SWIFT.

You must define routing rules like the following ones:

• For _SI_to_SWIFT

Alliance Access 7.0 - Solaris

270 Installation and Administration Guide

Route all transmission notifications related to messages originating from the standaloneAlliance Access system

Sequence number 50

Description transmission notifications

Condition on Message: (Src_entity=Message Partner which treated theinput messages coming from the standalone Alliance Accesssystem)

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 Accesssystem.

Sequence number 50

Description transmission notifications

Condition on Message: (Src_entity=Message Partner which treated theinput messages coming from the standalone Alliance Accesssystem)

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

Appendix A - Setup Recommendations

30 September 2011 271

– 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.

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

Alliance Access 7.0 - Solaris

272 Installation and Administration Guide

Appendix B

Command Line Tool Syntax ReferenceIntroduction

This section provides the location and the syntax of commands described in this guide.

Running the tools

Note that the tools can be run in two ways:

• By entering the command from the directory where the tool is located.

• From another location. In this case, you must provide the full path, and command.

Getting help

You can display the syntax for each tool by entering one of the following commands:

• <tool name>

• <tool name> -hwhere <tool name> is the name of the tool that you want to use.

B.1 checkhostTool location

<Alliance installation directory>/SunOS/checkhost

Command syntax

checkhost.ksh [-req <pathname of requirements file]>] [-rootdir <pathname of a directory>] [-out <pathname of the report file>]

Parameters

Parameter Description Mandatory?

-req Used to specify the Alliance Access base requirements file, for acomparative analysis report.

No

-rootdir Used to specify the path to a drive or file system against which thecheckhost tool must perform a disk space validation.

No

-out Used to specify the location for the report file. If no location is specified,then the report is produced in the following default location:

/tmp/checkhost.log

No

-outxml Used to specify the location for the report file, and that the file is to be inXML format. If no location is specified, then the report is produced in thefollowing location:

/tmp/checkhost.log

No

Appendix B - Command Line Tool Syntax Reference

30 September 2011 273

B.2 getmesgPurpose

Use the getmesg tool to obtain database information about a specific message. The tool canbe used with the servers running or stopped.

Note You cannot use the getmesg tool to retrieve information about a message thatwas restored from a backup of the Message Archive from Alliance Access Release6.0.x. Instead, you must use the saa_bankquery tool to retrieve informationabout the message.

Tool location

<Alliance installation directory>/BSS/bin/SunOS

Command syntax

getmesg -u "UUMID" -s DATESUFFIX [-o <output file>] [2><errorfile>]

Parameters

Parameter Description Mandatory?

UUMID The UUMID of the searched message (can be extracted from the MessageFile). It must be specified between double quotes (").

Yes

-s DATESUFFIX The concatenation of the message creation date (YYMMDD) and the suffixdisplayed in the Message File.

Yes

-o <output file> The location of the path and the filename of a file where the output of thecommand is redirected. If the option is not specified, then the commandoutput is displayed on the screen.

No

2><errorfile> Used to save the returned error in a file. No

To run the tool

1. Log on as Alliance Access System Administrator.

2. From the System Administration application select xterm from the OS Configurationmenu.

3. In the Xterm window, run the getmesg command with the required parameters.

For example:

getmesg -u "IALLIBEAAXXX999ABCD1234" -s 0004062345 -o /temp/getmesg.out 2>/temp/mesgerror.out

Alliance Access 7.0 - Solaris

274 Installation and Administration Guide

Result

If the command is run successfully, Alliance Access writes an event to the Event Journal withthe following information about the message:

• the UUMID of the message for which the getmesg tool was run (a concatenation of themessage creation date (YYMMDD) and the suffix of the message for which the getmesg toolwas run)

• the date and time at which the getmesg tool was run

• the operating system account of the operator that launched the tool

B.3 launch MPA EXPORT_TEMPLATESPurpose

Alliance Access provides an export function for MT and MX message templates. For adesignated server and database instance, an offline utility prepares a file that provides forwardcompatibility when migrating templates. You can export the templates that were created withprevious releases on any platform (AIX, Oracle Solaris, or Windows) and then import thosetemplates to this release. You can export all templates, or templates only for a specific logicalterminal.

You can use the export tool as a convenient way to save all your templates. They are stored ina single file, which is useful to have as a backup of this information.

During the export, two files are produced:

• the output file

• the export.log file

Re-running the export overwrites the output file and the log file.

Tool location

<Alliance installation directory>/BSA/bin/SunOS

Command syntax

launch -- -L MPA EXPORT_TEMPLATES ---p <pathname>-f <filename>[-l<senderLT>][-r<replacementLT>]

Parameters

Parameter Description Mandatory?

-p <pathname> Indicates where to store the output files (template file and log file) Yes

-f <filename> Specifies the name of the output file that contains exported templates Yes

[-l<senderLT>] BIC12 name of the logical terminal that contains the templates to beexported. Include the terminal code before the 3-character branch code.

If this parameter is not included, then all templates are exported.

No

[-r<replacementLT>] BIC12 name of the logical terminal that receives the exported templates.Include the terminal code before the 3-character branch code.

If this parameter is included, then the -l argument must also be included.

No

Appendix B - Command Line Tool Syntax Reference

30 September 2011 275

To run the tool

1. Log on as Alliance Access System Administrator.

2. From the System Administration application select xterm from the OS Configurationmenu.

3. In the xterm window, run the launch MPA EXPORT_TEMPLATES command with therequired parameters.

Result

The export.log file contains information about the circumstances of running the export. It liststhe names of each template considered for export and indicates whether a template wasexported successfully. It summarises how many templates were read, how many were exported,and how many were skipped. The log file shows any errors encountered while building theoutput file.

Messages while exporting templates

The following messages can appear when you are exporting templates:

Message Meaning

Cannot open [%] forexport

The operating system cannot open the file that contains the exportedtemplates. There can be problems with file permission, file ownership,file existence, and so on.

[-l argument %] is not aBIC12

There is a syntax error in the BIC12 value keyed as the sender logicalterminal

[-r argument %] is not aBIC12

There is a syntax error in the BIC12 value keyed as the replacementlogical terminal

Template export started[date time]

The export started at the date, and time specified

Selecting LT [%] Templates are being selected from the logical terminal identified in theBIC12 for the -l argument

Replacing with [%] Templates are being replaced on the logical terminal identified in theBIC12 for the -r argument

EXPORTED The template was exported successfully

NOT EXPORTED (RESERVED) The template could not be exported because it was reserved during thetime that the export was running

NOT EXPORTED (LT %s) The templates could not be exported because the logical terminalspecified is incorrect

NOT EXPORTED (MISSINGMESSAGE TYPE)

The template could not be exported because it did not contain amessage type

NOT EXPORTED (WRONGBANKING PRIORITY)

The template could not be exported because it did not contain a validcode for banking priority

NOT EXPORTED (WRONGM.U.R.)

The template could not be exported because the message userreference syntax was incorrect

Alliance Access 7.0 - Solaris

276 Installation and Administration Guide

B.4 launch MPA unres_mesgPurpose

Alliance Access provides an offline utility that allows you to unreserve messages that areblocked. Messages can appear to be reserved even if they are not, due to system crashes ofapplications used in message preparation (MPA).

Prerequisites

The servers must be running.

The instance on which the message must be unreserved must be the active one.

Tool location

<Alliance installation directory>/BSA/bin/SunOS

Command syntax

launch -- -L MPA unres_mesg --<queue><UUMID><suffix>]

Parameters

Parameter Description Mandatory?

<queue> The queue in which the message instance is reserved. Yes

<UUMID> Concatenated values of I/O indicator, Correspondent, Message Type, andReference.

If the UUMID contains any spaces, then enclose the entire string in doublequotation marks.

Yes

<suffix> Suffix of the message to unreserve.

System-generated value.

Yes

To run the tool

1. Log on as Alliance Access System Administrator.

2. From the System Administration application select xterm from the OS Configurationmenu.

3. In the xterm window, run the launch MPA unres_mesg command with the requiredparameters.

Result

All attempts to unreserve messages are logged in the Event Journal.

A message may fail to be unreserved for the following reasons:

• Message not found

• Unreserve operation failed

• No instances found

• No instances reserved by MPA found

Appendix B - Command Line Tool Syntax Reference

30 September 2011 277

B.5 messageToolPurpose

The messageTool command is used to unreserve or to complete all messages at a particularrouting point. The tool can only be used when the Alliance Access servers are stopped.

Tool location

<Alliance installation directory>/BSS/bin/SunOS

Command syntax

messageTool -r <Routing point name> -c | -u

Parameters

Parameter Description Mandatory?

<Routing point name> The name of the Routing Point where the messages to process are located. Yes

-c Option to be used if the messages must be completed. No

-u Option to be used if the messages must be unreserved. No

To run the tool

1. Log on as Alliance Access System Administrator.

2. From the System Administration application select xterm from the OS Configurationmenu.

3. In the xterm window, run the messageTool command with the required parameters.

Result

If the command is run successfully, Alliance Access writes an event in the Event Journal, withthe UMID and instance number of the message instance that was completed or unreserved.

B.6 reset_mpPurpose

reset_mp is used to reset and disable a message partner profile.

The tool can be used only when the Alliance Access servers are stopped.

Tool location

<Alliance installation directory>/MXS/bin/SunOS

Command syntax

reset_mp <Message partner name>

Alliance Access 7.0 - Solaris

278 Installation and Administration Guide

Parameters

Parameter Description Mandatory?

<Message partnername>

The name of the message partner to reset. Yes

Result

If the command is run successfully, Alliance Access writes an event to the Event Journal withthe name of the message partner profile that was reset.

B.7 saa_bankqueryTool 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.8 saa_bootstrapPurpose

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 keptin the system log file and in the file saa_bootstrap.out.<x>, where <x> is a value from 0through 5. This allow for six logs to be kept. This file is created in the log sub-directory of theinstallation directory (that is, $ALLIANCE/log/).

Prerequisites

The saa_bootstrap command must be run using the Alliance Access Administrator account.

Tool location

<Alliance installation directory>/bin

Command syntax

saa_bootstrap [-timeout <value>] [-nameservice]start|stop

Appendix B - Command Line Tool Syntax Reference

30 September 2011 279

Parameters

Parameter Description Mandatory?

-saastart Starts the Alliance Access servers.

If this parameter is not given, then the script uses the value of the StartupMode parameter (set in the System Management application) to decidewhether Alliance Access must be started.

No

stop Stops the Alliance Access servers. No

-timeout <value> Defines a value, in seconds, after which the script stops if the AllianceAccess instance does not start or stop (depending on which is selected).The minimum value is 150 (seconds).

No

-nameservice The Alliance Access name service to be started or stopped. No

B.9 saa_configbootstrapTool location

<Alliance installation directory>/bin

Command syntax

saa_configbootstrap -nameservice -bootstrap

Parameters

Parameter Description Mandatory?

-nameservice Starts the Alliance Access Name Service at start time. No

-bootstrap Starts the Alliance Access bootstrap service at start time. No

B.10 saa_configconnectionPurpose

Use the saa_configconnection tool to perform the following actions:

• display, add, or delete IP addresses that the SwRPC layer uses to listen for the clientconnections (Alliance Workstation and ADK-based clients)

• display, add, or delete IP addresses of SwRPC layer clients that Alliance Access accepts(Alliance Workstation and ADK-based clients)

• import server SSL certificates and display certificate information

Note If the Alliance Access server is running when the command is run, then it must berestarted before your changes become effective.

Prerequisites

• Run this tool from the Alliance Access Administrator account.

• Use this tool to configure the Alliance Access instance that the command is packaged with.

Alliance Access 7.0 - Solaris

280 Installation and Administration Guide

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 theprompts.

The default response is shown in square brackets in the format [default,<default_value>]

B.11 saa_dbconfigTool location

<Alliance installation directory>/bin

Command syntax

saa_dbconfig <entity> <command>

Parameters

Entity Command Description Mandatory?

memory -display Displays the amount of memory allocated for the databasememory regions.

Default value: 1500 MB.

No

-resize -all <Size> Changes the amount of memory allocated for the databasememory regions.

No

tablespace -display [-tablespace<Name>]

Displays the current location, allocated size and usage (inmegabytes) of all tablespaces or for a specified tablespace<Name>.

No

-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 thetablespace UNDO or TEMP (the Size is expressed in MB).

No

-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 automaticallyincrease in size, this allows setting or resetting the size of atablespace.

No

-reorganise -tablespace <Name> -location <TempDir>

Re-organises the specified tablespace <Name> to reclaimunused space and re-sizes it to its minimum required size.This requires sufficient free disk space to be available in the<TempDir> location to perform an export of the data.

No

Appendix B - Command Line Tool Syntax Reference

30 September 2011 281

Entity Command Description Mandatory?

This command only applies to user tablespaces (and notsystem tablespaces).

redolog -display Displays the current location and size of the redo log files. No

-move -location<DestinationDir> -size

Moves all redo log files to a <DestinationDir> location andresizes them to the specified <Size> (expressed in MB). Theoriginal redo logs remain in the original directory, and need tobe removed manually if required.

No

B.12 saa_dbinfoTool 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 aZIP file).

Yes

-startdate <date> The start date, in the format YYYYMMDD. No

-starttime <time> The start time, in the format HH:MM:SS. No

-stopdate <date> The stop date, in the format YYYYMMDD. No

-stoptime <time> The stop time, in the format HH:MM:SS. No

B.13 saa_dbpwdutilPurpose

The saa_dbpwdutil command updates the database information in theinstallation.properties file with the following information:

• the password of a database account (owner account or user account)

• the database connection string

Use this command for either an embedded or a hosted database.

Prerequisites

The following prerequisites apply to this command:

• The command must be run by the software owner account.

• The database must be running.

Alliance Access 7.0 - Solaris

282 Installation and Administration Guide

Tool location

<Alliance installation directory>/bin

Command syntax

saa_dbpwdutil -username <Database Username> [-password <Database User Password>] -connect "<Connect String>" -schema <Database Schema Name>

Parameters

Parameter Description Mandatory?

-username <DatabaseUsername>

Changes database username, where <Database Username> represents theuser account for which the password must be changed.

Yes

[-password <DatabaseUser Password>]

Specifies the new password for the user account No

-connect <ConnectString>

Changes the connect string, where "<Connect String>" represents thedatabase connection string to be used by the <Database Username> toconnect to the database.

For example:"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<hostname_or_IP_address>)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=ORACLE_SID)))"where <hostname_or_IP_address> is the host where the database islocated.

Yes

-schema <DatabaseSchema Name>

Changes the name of the database schema, where <Database SchemaName> represents the name of the schema.

Yes

B.14 saa_dbrecoveryTool 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]

Appendix B - Command Line Tool Syntax Reference

30 September 2011 283

Parameters

Parameter Description Mandatory?

-m Displays the status of Database Recovery Mode, which can be:

• Activated

• Deactivated

If the Database Recovery Mode is Activated, then the command alsodisplays the total disk size and the free disk space available in MB for thelive disk and each recovery disk.

No

-a Activates the Database Recovery Mode.

You must specify the full path names of the mirror and backup disks.

No

-p <pathname_recovery_mirror_disk>

Specifies the full path name of the mirror disk. No

-q<pathname_recovery_backup_disk>

Specifies the full path name of the backup disk. No

-d Deactivates the Database Recovery Mode. No

-f <y|n> Specifies whether a full recovery backup must be created as part of theactivation. The default value is y: a full recovery backup is created.

No

-i <y|n> Launches the tool in interactive mode when activating, deactivating, orrecovering the database:

• y: launch the tool in interactive mode

• n: use command-line parameters

By default, if you omit this parameter, then the tool prompts you for input.

No

-c f|i Launches a backup of the database :

• f: full database backup

• i: incremental database backup

By default, Alliance Access removes old database backups after creating anew full-database backup successfully. Optionally, you can remove oldbackups before Alliance Access creates new backup, by specifying the -eparameter.

No

-e <y|n> Alliance Access removes old backup before it creates a new backup.

By default, Alliance Access removes old database backups after creating anew full-database backup successfully.

No

-r Recovers the database.

You must specify the full path names of the mirror and backup disks.

No

-z <n|s|a> Enables or disables connectivity and Alliance Developers Toolkitcomponents:

• n: enables connectivity. This is the default value.

• s: disables SWIFT connectivity only

• a: disables all connectivity

No

Alliance Access 7.0 - Solaris

284 Installation and Administration Guide

Parameter Description Mandatory?

-v Recovers the database from an incremental database backup. This ispartial database recovery.

You must specify the full path name of the mirror and backup disks.

No

-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 afterthe database recovery.

The -s parameter can have the following values:

• n: leaves live message instances in their queue for further routing. Apossible duplicate emission is added to outstanding live messageinstances.

• c: completes all live message instances.

• i: routes all live message instances to the _MP_recovery queue, forfurther investigation.

If the value of Message Repair Action is not Prompted, then you cannotspecify how messages are repaired after this partial database recovery.The messages will be repaired according to the value specified for theMessage Repair Action parameter.

No

-h Displays help about the command and its parameters. No

B.15 saa_dbrestorePurpose

The saa_dbrestore command enables an Alliance Access Administrator to restore thedatabase either partially or completely.

Tool location

<Alliance installation directory>/bin

Command syntax

saa_dbrestore -r -c -p <path name of database backup file> -s {a|o|s|r|c|d|w|m} [-e {y|n}] [-o {y|n}] [-w {y|n}] [-z {n|s|a}] [-i {y|n}]

Parameters

Parameters and Options Description Mandatory?

-r Restores the database.

Use either -c or -r.

Yes

-c Runs a consistency check.

Use either -c or -r.

Yes

Appendix B - Command Line Tool Syntax Reference

30 September 2011 285

Parameters and Options Description Mandatory?

In case of detected inconsistencies, a log file is generated. The format ofthe log file is restore_YYYYMMDDTHHMMSS.log, whereYYYYMMDDTHHMMSS is the timestamp when the check was done.

-p <path name ofdatabase backup file>

Specifies the path name where the backup of the database is located.

In case of hosted database, <path name of database backup file> isthe database directory itself (for example,20101025T104837_SAA_DATA_BACKUP).

Yes

-s [a|o|s|r|c|d|w|m] The set of entities to be checked or restored. Include one of thefollowing:

Yes

a: all entities No

o: Operators only No

s: SWIFT interface only No

r: Routing information only No

c: Correspondents only No

d: Alliance Developer Kit (ADK) storage only No

w: SWIFTNet Interface only No

m: Relationship Management Application (RMA) authorisations, includingalso the configuration)

No

-e [y|n] Cleans messages and events.

Default value: n.

No

-o [y|n] Restores operators even when the set of operators is not identical. Youcan use this parameter only when you include -s in the command.

Default value: y.

No

-w [y|n] Restores the SWIFTNet related information. You can only this parameteronly when you include -s [a|s|w] in the command.

Default value: y.

No

-z [n|s|a] Disable connectivity and Alliance Developers Toolkit components.Include one of the following:

No

n: no (default value) No

s: SWIFT Connectivity only No

a: All No

-i [y|n] Run the script in interactive mode. Default value: y. No

To perform a full restore

saa_dbrestore -p c:\backup\YYYYMMDDTHHMMSS_DAA_DATA_BACKUP -s -a

To perform a partial restore

saa_dbrestore -p c:\backup\YYYYMMDDTHHMMSS_DAA_DATA_BACKUP -s -m

To run a consistency check

saa_dbrestore -c -p c:\backup\YYYYMMDDTHHMMSS_DAA_DATA_BACKUP -s -m

Alliance Access 7.0 - Solaris

286 Installation and Administration Guide

B.16 saa_exportTool location

<Alliance installation directory>/bin

Operator session

Your Alliance Access licensing agreement allows only a certain number of operators to use thesystem concurrently. Running this tool starts an operator session with Alliance Access, and thissession 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_file>

The name of the export parameter file that contains the list of entities (alongwith 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 ofa successful export process.

Yes

-user <username> The name of the Alliance Access operator of type Human executing thecommand.

If omitted and no -application argument is specified, then the operatorexecuting the command must be all_adm.

No

-application<username>

The name of the Alliance Access operator of type Application executing thecommand.

If omitted and no -user argument is specified, then the operator executingthe command must be all_adm.

No

-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 theuser name and password in the command line.

• -user|-application <username> -passwordfile <passwordfile>:Specify the password file name, which contains the password. Thepassword included in the password file is not encrypted. Accessing thepassword depends on the access rights associated to the password file.

• -user|-application <username>: You are prompted to enter thepassword when you launch the tool. This is the most secured option.

No

-passwordfile<password_file>

The name of a file that contains the password of the Alliance Accessoperator.

No

Appendix B - Command Line Tool Syntax Reference

30 September 2011 287

Parameter Description Mandatory?

-exportsensitivedata Indicates that sensitive data will be exported and stored in the export file. No

-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 theexport tool, then it indicates that the export file will be overwritten. If you donot enter this parameter but the export file exists, then the export processstops.

No

-port <port_number> The port number of the localhost in which the Alliance Access is listening.Default port number: 48200.

No

-reportfile<file_pathname>

The name of the report file in which details of the export are logged. If a filewith that name already exists, then Alliance Access overwrites it.

No

-summaryonly If specified, then the produced export log contains less information aboutthe entity occurrences exported.

No

B.17 saa_importTool location

<Alliance installation directory>/bin

Operator session

Your Alliance Access licensing agreement allows only a certain number of operators to use thesystem concurrently. Running this tool starts an operator session with Alliance Access, and thissession 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 Mandatory?

-exportfile<export_file>

The name of the export file containing the configuration data to export. Yes

-user <username> The name of the Alliance Access operator of type Human executing thecommand.

If omitted and no -application argument is specified, then the operatorexecuting the command must be all_adm.

No

-application<username>

The name of the Alliance Access operator of type Application executing thecommand.

If omitted and no -user argument is specified, then the operator executingthe command must be all_adm.

No

-password <password> The password of the Alliance Access operator. No

Alliance Access 7.0 - Solaris

288 Installation and Administration Guide

Parameter Description Mandatory?

You can use one of the options to specify the password:

• -user|-application <username> -password <password>: Enter theuser name and password in the command line.

• -user|-application <username> -passwordfile <passwordfile>:Specify the password file name, which contains the password. Thepassword included in the password file is not encrypted. Accessing thepassword depends on the access rights associated to the password file.

• -user|-application <username>: You are prompted to enter thepassword when you launch the tool. This is the most secured option.

-passwordfile<password_file>

The name of the password file that contains the password. No

-overwrite The import mode. Specify this parameter to update the existing entities. Ifyou do not specify the parameter, then the update is skipped.

No

-port <port_number> The port number of the localhost in which the Alliance Access is listening.Default port number: 48200.

No

-reportfile<file_pathname>

The name of the report file in which details of the import execution arelogged. If a file with that name already exists, then Alliance Accessoverwrites it.

No

-summaryonly If specified, then the produced import log contains less information aboutthe entity occurrences imported.

No

B.18 saa_import_rmqaPurpose

saa_import_rmqa is used to recover RMA Queries/Answers that were not migrated during anupgrade from Alliance Access 6.3 to 7.0.

You can extract RMA Queries/Answers from a 6.3 database backup or a backup file forupgrade.

Tool location

<Alliance installation directory>/bin

Command syntax

saa_import_rmqa <database backup pathname or name of backup file for upgrade>

Parameters

Parameter Description Mandatory?

<database backuppathname or name ofbackup file forupgrade>

Indicate either:

• The full pathname of a database backup (for example:saa_import_rmqa /backup/20110825T043200_SAA_DATA_BACKUP)

• The name of a backup file for upgrade (for example saa_import_rmqaSAA63to7.zip)

Yes

Appendix B - Command Line Tool Syntax Reference

30 September 2011 289

B.19 saa_manageTool location

<Alliance installation directory>/bin

Operator session

Your Alliance Access licensing agreement allows only a certain number of operators to use thesystem concurrently. Running this tool starts an operator session with Alliance Access, and thissession is included in the count of concurrent users of the system.

Command syntax

saa_manage -manageparameterfile <manage_parameter_file> -manageoutputfile <manage_output_file> -action <action_keyword> <action_parameters> [-user|-application <username>] [-password <password>] | [-passwordfile <password_file>] [-port <port_number>] [-overwrite]

Parameters

Parameter Description Mandatory?

-manageparameterfile<manage_parameter_file>

The name of the file containing the entity type and occurrences to bemanaged. 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 andname of the file.

Yes

-manageoutputfile<manage_output_file>

The name and path of the file that will contain the output of themanagement action (for each occurrence, if the action has beensuccessful or not, as well as any relevant result).

Yes

-action<action_keyword><action_parameters>

The action to perform on the specified entities. For a full list, see "EntitiesEligible for Operational Management" on page 228.

The action is defined by a keyword and parameters. The parameters thatyou must include depend on the action keyword and the entity.

Parameter keywords are case-sensitive.

Yes

Action keyword Parameters Relevantentity

select_FIN [-subset <subset_name_1>][-subset <subset_name_n>]-ltdirqueue y|n-send_receive_mode s|r|sr

logicalterminal

Change_mode -mode manual|automatic logicalterminal

emission orreceptionSWIFTNetprofile

Start_session -file_location server|userspace (1)

-connection_point<connection_point> (1)

-dir to|from (2)

messagepartner

Alliance Access 7.0 - Solaris

290 Installation and Administration Guide

Parameter Description Mandatory?

-add_PDE (3)

-action route|dispose<queue_name> (3)

Run_session Only for File Transfer connectionmethod:

-file_location server|userspace-connection_point<connection_point>

messagepartner

Disable -next_signon_allowed enable, or

-next_signon_allowed date "DD/MM/YYYY HH:MM:SS"

operator

-user <username> The name of the Alliance Access operator of type Human executing thecommand.

If omitted and no -application argument is specified, then the operatorexecuting the command must be all_adm.

No

-application<username>

The name of the Alliance Access operator of type Application executingthe command.

If omitted and no -user argument is specified, then the operator executingthe command must be all_adm.

No

-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 theuser name and password in the command line.

• -user|-application <username> -passwordfile <passwordfile>:Specify the password file name, which contains the password. Thepassword included in the password file is not encrypted. Accessing thepassword depends on the access rights associated to the password file.

• -user|-application <username>: You are prompted to enter thepassword when you launch the tool. This is the most secured option.

No

-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 andname of the file.

No

-port <port_number> The port number of the localhost in which the Alliance Access is listening.Default port number: 48200.

No

-overwrite When this option is specified, and if the file specified by the -manageoutputfile parameter exists, then it is overwritten.

No

(1) Always use -file_location for the File Transfer, Direct FileAct, and Print (Print-to-file option) connection

methods.

(2) Always use -dir for the File Transfer and CAS Interactive connection methods when the message partner profile

is defined as To & From Message Partner. Use -dir to start either a session to the message partner or a

session from message partner.

(3) Use the -action, and optionally, the -add_PDE parameter when you start an input session. An input session

uses From Message Partner, or To & From Message Partner with the -dir from parameter to specify

the input session.

Appendix B - Command Line Tool Syntax Reference

30 September 2011 291

Exit codes

The saa_manage tool returns the following exit codes:

Exit code Description

0 The command ran successfully

1 The command ran successfully for some but not all of the entityoccurrences in the <manage_parameter_file>. See the<manage_output_file>.

255 The command failed to run successfully.

B.20 saa_manageaspPurpose

Installs the Application Service Profiles that are provided in an Application Service Profilepackage, that was downloaded from www.swift.com.

Prerequisites

The Alliance Access server must be running in either Housekeeping or Operational mode.

Tool location

<Alliance installation directory>/bin

Operator session

Your Alliance Access licensing agreement allows only a certain number of operators to use thesystem concurrently. Running this tool starts an operator session with Alliance Access, and thissession is included in the count of concurrent users of the system.

Permissions

To run this command, you must have the permissions Manage ASP in your operator profile

Command syntax

saa_manageasp [-user|-application <username>] [-password <password>] [-passwordfile <passwordfile>] [-l <Full ASP Package Filename>] [-port <port number> [-h]

Parameters

Parameter Description

-user|-application <username> Name of the Alliance Access operator of type Human (-user),or Application (-application) executing the command. Theoperator must have the Manage ASP function in their profile.

Optional.

If omitted, then the operator executing the command must beall_adm.

-password <password> Password of the Alliance Access operator.

Optional.

Alliance Access 7.0 - Solaris

292 Installation and Administration Guide

Parameter Description

If present, then -user must be present too. Must be omitted if-passwordfile is present.

-passwordfile <passwordfile> Name of the file containing the password of the AllianceAccess operator. Allows the password to specified in a fileinstead of in the command line.

Optional.

If present, then -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).

-port <port number> The port number of the localhost in which the Alliance Accessis listening. Default port number: 48200.

This port number is called <instance_name>.messenger1 inthe /etc/services file.

-h Provides a list of the different options and their meaning.

Log file

Error or confirmation messages are recorded in the log directory, underneath your installationdirectory. The name of the log file has the timestamp (YYYYMMDDTHHMMSS) of when thecommand was run.

B.21 saa_monitorTool location

<Alliance installation directory>/bin

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 -passwordfileparameters, 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 bemonitored, and the scope of monitoring for each entity type.

If the file is not located in the current directory, then type the path andname of the file.

Yes

Appendix B - Command Line Tool Syntax Reference

30 September 2011 293

Parameter Description Mandatory?

-monitoroutputfile<monitor_output_file>

The name of the file that contains the monitoring information for theentities included in the monitor parameter file.

If the file is not located in the current directory, then type the path andname of the file.

Yes

-user <username> The name of the Alliance Access operator of type Human executing thecommand.

If omitted and no -application argument is specified, then theoperator executing the command must be all_adm.

No

-application <username> The name of the Alliance Access operator of type Application executingthe command.

If omitted and no -user argument is specified, then the operatorexecuting the command must be all_adm.

No

-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>: Enterthe 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 containsthe password. The password included in the password file is notencrypted. Accessing the password depends on the access rightsassociated to the password file.

• -user|-application <username>: You are prompted to enter thepassword when you launch the tool. This is the most secured option.

No

-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 andname of the file.

No

-cycle <nnnn_sec> The value in seconds of the cycle according to which monitoring mustcontinue. The minimum time is 2 seconds. If you do not provide a valuefor the -cycle parameter, then the monitoring runs once only.

No

-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 alsospecified. If this parameter is not specified, then cyclic monitoring runsforever.

No

-continue_on_error The process continues even if an error occurs on any entity or entityoccurrence. If this parameter is not specified, then the monitoring stopswhen the first error occurs on any entity or entity occurrence.

No

-port <port_number> The port number of the localhost in which the Alliance Access islistening. Default port number: 48200.

This port number is called messenger1 in the /etc/services file.

No

-overwrite When this option is specified, and if the file specified by the -monitoroutputfile parameter exists, then the output file isoverwritten.

No

Alliance Access 7.0 - Solaris

294 Installation and Administration Guide

Exit codes

The saa_monitor tool returns the following exit codes:

Exit code Description

0 The command ran successfully

1 The command ran successfully for some but not all of the entityoccurrences in the <monitor_parameter_file>. See the<monitor_output_file>.

255 The command failed to run successfully.

B.22 saa_msgrepairTool location

<Alliance installation directory>/bin

Command syntax

saa_msgrepair [option]

Parameters

Parameter Description Mandatory?

-m 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

No

-r [n|c|i] After the partial recovery, the actions performed for the message repairdepends on the value of the "Message Repair Action" security parameter. Ifthe value is "Prompted", then the value of the -r parameter is taken intoaccount.

• n: None. Live message instances are left in their queue for furtherrouting.

• c: Complete. Live message instances are completed.

• i: Investigate. Live message instances are routed to the _MP_recoveryqueue.

If the value is different from "Prompted", then the action specified by the"Message Repair Action" security parameter is performed. In all cases, aPDE is added to live outstanding message instances.

No

-h Provides a list and description of the different options. No

B.23 saa_queryPurpose

You can run a query to export the content of events, messages (live or archived), or all theoperator details from the database.

For messages and events:

Appendix B - Command Line Tool Syntax Reference

30 September 2011 295

• The query provides the contents of events or messages that were created within a specifictime period. The results of the query also indicate whether the information is from live orarchived data.

• The command extracts details only from the Alliance Access instance from which thecommand is run.

For operators:

• If the operator that launches the command has delegated units, profile, or destinations, thenonly those allowed units, profiles and destinations are exported. This applies only whenrunning a report on operators.

The results are provided in an output file that uses the same XML format as the Alliance AccessWeb services use. For more information about the XML format that is used in the output file, seethe Web Services Developer Guide.

Important

The description of this command corresponds to release 7.0. This command is not available inrelease 7.0.0 of Alliance Access.

The command is available for messages and events in release 7.0.10, and later releases. Forinformation about further updates to the command in later releases, see the release letter thatcorresponds to those releases.

The command is also available for operators as from release 7.0.30.

Prerequisites

Before launching the command, check the following conditions:

• To query events or operators, the Alliance Access server can be running in either operationalor housekeeping mode.

• To query messages, the Alliance Access server must be running in operational mode.

• If the Alliance Administrator runs the command and the -user or -applicationparameters are excluded, then the Software Owner Profile security parameter must specifya valid operator profile.

• To extract the delegation details of an operator, the operator profile of the operator that runsthe command must include the System Management entity in the selected permissions. Bydefault, the default operator profile, R7.0_Import_Export includes the required permissions.

Note If operator delegations are used, you will only need to have the systemmanagement permission

Tool location

<Alliance installation directory>/bin

Operator session

Your Alliance Access licensing agreement allows only a certain number of operators to use thesystem concurrently. Running this tool starts an operator session with Alliance Access, and thissession is included in the count of concurrent users of the system.

Alliance Access 7.0 - Solaris

296 Installation and Administration Guide

Command syntax

saa_query [-user|-application <username>] [-password <password>] | [-passwordfile <password_file>] [-overwrite] [-port <port_number>] -outputfile <file_pathname> -message|-event|-operator [-start <yyyymmddThhmmss> -end <yyyymmddThhmmss>]

Parameters

Parameter Description Mandatory?

-user <username> The name of the Alliance Access operator of type Human that is runningthe command.

If the -user or -application argument is not specified, then the softwareowner must launch command. In this case, the Software Owner Profilesecurity parameter must be defined.

-application<username>

The name of the Alliance Access operator of type Application that isrunning the command.

If the -user or -application argument is not specified, then the softwareowner must launch command. In this case, the Software Owner Profilesecurity parameter must be defined.

No

-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. If you omit thepassword, then you receive a prompt to enter it.

• -user|-application <username> -passwordfile <passwordfile>:

Specify the password file name, which contains the password. Thepassword included in the password file is not encrypted. The accessrights that are associated with the password file control the access tothe password.

No

-passwordfile<password_file>

The name of the password file that contains the password. No

-overwrite Specify this parameter to overwrite the values in an existing output file. Ifyou omit this parameter, then no changes are made to an existing outputfile.

No

-port <port_number> The port number of the local host in which the Alliance Access is listening.Default port number: 48200.

No

-outputfile<file_pathname>

The name of the output file in which details of the messages, events, oroperators are stored.

Yes

-message|-event|-operator

Specify one of the following parameters:

• -message: export the content of messages

• -event: export the content of events

• -operator (available as of Alliance Access 7.0.30): export the contentof operator profile definitions and operator definitions

Yes

Appendix B - Command Line Tool Syntax Reference

30 September 2011 297

Parameter Description Mandatory?

For more information, see also "Results of operator query" onpage 298.

-start<yyyymmddThhmmss> -end <yyyymmddThhmmss>

Use with -message or -event:

Specify this parameter to indicate a date and time from which to start andend the extraction of messages or events from the database. The time anddate are local to the server.

If you omit this parameter, then the tool is run on the current day from00:00 to 23.59.

No

Results of operator query

If the operator that launches the saa_query command has delegated privileges, then theresults of the query about operators includes only the information that the operator is permittedto access or view.

A query about operators provides the following information:

• Name

• Description

• Operator Type (Human or Application)

• Profiles

• Enable status

• Re-enable date

• Approval status

• Last changed

• Last sign-on

• Last enabled

• Authentication type

• LDAP user identifier

• Units

• Delegated units (if any)

• Delegated BICs (if any)

• Delegated profiles (if any)

A query about operators provides the following information about operator profiles:

• Profile name

• Application Profiles:

– Functions (if any)

• Permission details (if any)

In the XML output, dates are formatted as: dd/mm/yy hh:mm:ss.

Alliance Access 7.0 - Solaris

298 Installation and Administration Guide

Log file

When you run the command, Alliance Access creates a log file, saa_query_<Timestamp>.log,with the details about the time and the date that the tool was used. <Timestamp> is in theformat: yyyymmddThhmmss.

The log file also provides the name of the output file. For more information about the XMLformat that is used in the output file, see the Web Services Developer Guide.

B.24 saa_rtfilegetrequestPurpose

Use the saa_rtfilegetrequest command to request a payload file from a correspondentover the FileAct service in real time.

A real-time SWIFTNet Reception Profile manages the file request, the subsequent reception ofthe file, and its storage in the Alliance Access database.

Tool location

$ALLIANCE/bin

Operator session

Your Alliance Access licensing agreement allows only a certain number of operators to use thesystem concurrently. Running this tool starts an operator session with Alliance Access, and thissession is included in the count of concurrent users of the system.

Command syntax

saa_rtfilegetrequest -user|-application <username> -service <service_name> -request <request_type> -requestor <distinguished_name> -responder <distinguished_name> -rprof <real-time_reception_profile> -logicalname <logical_file_name> [-password <password>] [-passwordfile <password_file>] [-authoriser <distinguished_name>] [-nonrepudiation] [-signature none|crypto|list] [-priority <priority>] [-port <port_number>] [-possible_duplicate] [-transferinfo <info_about_the_transfer>] [-transferdesc <description_of_the_transfer>] [-userref <reference_information> [-unit <unit>]

Parameters

The saa_rtfilegetrequest command has mandatory and optional parameters, as follows:

Parameter Description Mandatory?

-user|-application<username>

The name of the Alliance Access operator of type Human (-user) orApplication (-application) executing the command.

Yes

-service<service_name>

The name of the real-time FileAct service over which the payload file mustbe transferred.

Yes

Appendix B - Command Line Tool Syntax Reference

30 September 2011 299

Parameter Description Mandatory?

-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 theResponder DN.

Yes

-responder<distinguished_name>

The DN of the correspondent institution, that is being requested to transferthe file.

Yes

-rprof <real-time_reception_profile>

The name of the real-time SWIFTNet Reception Profile that will manage thefile request and the reception of the file from the correspondent.

Yes

-logicalname<logical_file_name>

The logical name of the file that is requested from the correspondent. Thisname 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 Accessoperator specified in the -user or -application parameter.

(1)

-authoriser<distinguished_name>

The Authoriser DN that Alliance Access must use when requesting a filefrom the correspondent.

The level-2 BIC8 of the Authoriser DN must be the same as the level-2BIC8 of the Requestor DN.

No

-nonrepudiation The presence of this parameter indicates that non-repudiation is requiredfor the file transfer from the correspondent.

If the business service requires non-repudiation, then the transfernegotiation for that service must be signed, and you must specify both the -nonrepudiation and -signature parameters.

No

-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

No

-priority <priority> The SWIFTNet Priority to apply to the File Get Request:

• urgent

• normal

If you do not specify -priority, then normal priority is applied.

No

-port <port_number> The port number through which to connect to Alliance Access.

If you do not specify -port, then the default port, 48200, is used.

No

[-Possible_duplicate] Indicates whether the File message might be a duplicate. No

[-transferinfo<info_about_the_transfer>]

A string that provides information about a file transfer. Routing rules can bedefined to route FileAct messages based on the content of this field.

No

[-transferdesc<description_of_the_transfer>]

A string that describes the file transfer. No

Alliance Access 7.0 - Solaris

300 Installation and Administration Guide

Parameter Description Mandatory?

-unit <unit> The unit that Alliance Access assigns to the File message after AllianceAccess has received the associated payload file successfully.

No

[-userref<user_reference>

A string, which can be used as a reference for the file transfer or thepayload file.

No

(1) You can use only one of the optional parameters, -password or -passwordfile, in the command. If you do not

specify -password or -passwordfile , then the system prompts you to type the password for the user.

B.25 saa_supportinfoPurpose

The saa_supportinfo tool is used to collect a variety of system-related information over aspecified period and store it in a Zip file. The Alliance System Administrator sends the Zip file toSupport, for the investigation of problems.

Alliance Access configuration data, event journal, trace files, and logs are part of the informationthat is collected. However, secure information is not collected, for example, passwords or keys.

Important Some events related to FIN messages contain the full message payload. If you donot want the FIN message payload to be collected with this tool, then use theJournalise Msg Text security parameter.

Impact of database operations

The Alliance System Administrator can run this tool at any time, regardless of whether theAlliance Access database is running or not. If the database is not running, then the tool tries tostart the database.

• If the database starts successfully, then the collected information is saved in an output file.

• If the database fails to start, then the tool only collects information that does not requiredatabase access, and saves it in an output file.

Tool location

<Alliance installation directory>/BSS/bin/SunOS

Command syntax

saa_supportinfo [-output <output_dir>] [-from <From_datetime>] [-to <To_datetime>] [-hc] [-help]

Parameters

Parameter Description Mandatory?

-output <output_dir> The directory in which the output file is stored.

If you do not use the -output option, then the output file is stored in thesupport folder, under the installation root folder of the Alliance Accesssoftware (that is, \Alliance\Access\support).

No

Appendix B - Command Line Tool Syntax Reference

30 September 2011 301

Parameter Description Mandatory?

-from <From_datetime>-to <To_datetime>put

Specifies the time period, in the format YYYYMMDD[THHMM], during whichinformation is collect. This information includes ( the event journal, tracefiles, and log directory.

If you do not use this option, then the tool collects logging information fromthe previous 24 hours.

If -from and -to are present, then the logging information for the specifiedday period is retrieved.

If the date is specified but not the time, then the default time is 00:00:00 for<From_datetime>, and 23:59:59 for <To_datetime>.

If only -from <from_datetime> is present, then the logging information forthe specified date is retrieved for a period from the time specified, or, bydefault, 00:00:00 to 23:59:59.

If only -to <To_datetime> is present, then the logging information for thespecified date is retrieved for a period from 00:00:00 to the time specified,or, by default, 23:59:59.

No

-hc Checks the integrity of the operating system and resource information. No

-help Provides help. No

To run the tool

1. Log on as Alliance System Administrator to the host machine where Alliance Access isinstalled.

2. From the System Administration application window, select xterm from the OSConfiguration menu.

3. In the xterm window, run the saa_supportinfo command with the required parameters.

Result

The syntax of the output file name is saa_supportinfo.<YYYYMMDDTHHMMSS>.zip

Where:

• YYYYMMDD and THHMMSS are the creation date and time of the zip file

The zip file contains two directories with the collected information:

• config, for the configuration information

• log, for the logging information.

Configuration information that is collected

The configuration information includes the following:

• application server information (such as certificate, configuration file)

• database configuration information (provided by the saa_dbinfo and saa_dbconfigcommands)

• system information (provided by the checkhost tool and the Report utility)

• software integrity information (provided by the saa_system integrity command)

• Alliance Access licence information (provided by the Report utility)

• Alliance Access configuration information (for example, installation.properties)

Alliance Access 7.0 - Solaris

302 Installation and Administration Guide

• dump of the following Alliance Access entities:

– routing information: routing points, routing rules, routing keywords

– configuration information: calendar definitions, configuration parameters, units

– message partner configuration and session details

– SWIFTNet emission and reception profiles details

– operator profiles and operator definitions

– logical terminal definitions

– control tables for the message and event daily table sets

Logging information that is collected

The logging information includes the following:

• the installation.log file

• Installation checkhost report files

• Alliance Access product events log for the specified time frame

• database log and alert files

• log files of the embedded application server (in case of Server-Embedded products).

The time-related options (-to and -from) limit, when applicable to the Alliance Accessproduct, the extracted information for:

– the event journal

– the database alert and trace files

– content of the log directory (only files with a last modification date that falls in the [from-to] time frame).

B.26 saa_systemPurpose

The saa_system command provides a number of commands for administering AllianceAccess.

This command allows you to:

• archive messages and events

• take backups of one archive or several archives of the same type

• take database backups

• list archive backups

• restore an archive backup

• run database and software integrity checks

• start and stop the Alliance Access servers

Appendix B - Command Line Tool Syntax Reference

30 September 2011 303

• get information about the status of the Alliance Access servers and database

• start and stop tracing

• list all Alliance Access instances on a host

• rename Alliance Access instances

• copy the Event Journal (Event Log) to a text file.

The saa_system command is provided in the Alliance Access software and in the Remote APIsoftware.

Prerequisites

• The Alliance Access bootstrap must be running. See "saa_bootstrap" on page 279.

• The saa_system command must be run from the Alliance Access Administrator account.

Tool location

<Alliance installation directory>/bin

Command syntax

saa_system <command> <additional values> <options>where:

• <command> must be replaced with one of the commands listed in the following table.

• <additional values> represents choices for some of the commands.

• <options> represents an optional part of the command.

Parameters

Parameter Description Mandatory?

archive jrnl|mesg -days <NumberOfDays>

Archives the specified entity, where:

• jrnl represents events

• mesg represents complete messages

Use -days to specify the number of days (1 to 999) for which to retain thearchives.

No

archive list jrnl|mesg

Lists the archives present in the database for the specified entity where:

• jrnl represents events

• mesg represents complete messages

No

archive listtar jrnl|mesg <file_pathname>

Lists the archives present in a backup of the specified entity, in the tar filespecified in <file_pathname>.

Use only with backups that were created with an earlier version of AllianceAccess. This parameter is not available when a hosted database is usedinstead of an embedded database.

No

Alliance Access 7.0 - Solaris

304 Installation and Administration Guide

Parameter Description Mandatory?

archive remove jrnl|mesg <archive_name>

Removes the specified archive, <archive_name>, from the database.

You can also remove several archives of the same type, using a comma (,)to separate the names in <archive_name>. Do not include spaces.

No

archive backup jrnl|mesg <archive_name><file_pathname>

Performs a backup of the specified archive and stores the created backupunder the directory <file_pathname>.

You can also back up several archives of the same type, using a comma(,) to separate the names in <archive_name>. Do not include spaces.

For the hosted database, do not specify the <file_pathname> parameterbecause the backup is created in the eja (for events) or mfa (formessages) subdirectory of the shared directory specified by the LocationBackups parameter.

No

archive restore jrnl|mesg <file_pathname>

Restores the specified archive backup <file_pathname>.

In case of hosted database, <file_pathname> is the archive directory,which is MEAR_YYYYMMDD, or JRAR_YYYYMMDD for a single archivebackup. This directory must be located in the eja or mfa subdirectory of theshared directory specified by the Location Backups parameter.

No

archive restoretarjrnl|mesg<ArchiveName><file_pathname>

Restores the specified archive from the backup tar file specified in<file_pathname>.

Use only with backups that were created with an earlier version of AllianceAccess. This parameter is not available when a hosted database is usedinstead of an embedded database.

No

dbbackup<file_pathname>

Performs a complete backup of the database (excluding messages andevents). The command stores the backup as a directory under the directory<file_pathname>.

In case of hosted database, do not specify the <file_pathname>parameter because the backup is created in the db subdirectory of theshared directory specified by the Location Backups parameter.

No

dbintegrity [all|static]

Verifies the integrity of the Alliance Access database by checking that thereare no unauthorised updates.

all verifies the complete database, including messages and events.

static verifies the complete database, but excludes messages andevents.

No

integrity [short][<adk_component_names>

Verifies the integrity (absence of unauthorised updates) of the AllianceAccess software files.

This command launches the Integrity Verification Tool. The tool generatesa full integrity report that is compared to the last full integrity report whichwas produced during installation or upgrade.

Specify [short] to run a less-intense check.

Specify <adk_component_names>, to check only specific components of theAlliance Developers Toolkit. If you omit this parameter, then all componentsof the Alliance Developers Toolkit are checked.

The security parameter, Software Check at Startup, controls whether theIntegrity Verification Tool is run each time that Alliance Access is started.This parameter is available as of Alliance Access 7.0.10.

No

instance list Lists the instances that are installed on the host machine. No

instance rename Renames the current instance of Alliance Access. No

readlog<file_pathname> [-startdate <Date> [-starttime <Time>]] [-stopdate <Date> [-stoptime <Time>]]

Reads the events that belong to the specified period from the Event Journaland places them in a text file named in file_pathname.

No

Appendix B - Command Line Tool Syntax Reference

30 September 2011 305

Parameter Description Mandatory?

Specify dates and time as:

• Date: YYYYMMDD

• Time: HH:MM:SS

start housekeeping Starts Alliance Access in housekeeping mode.

You cannot start the servers while the database is being restored.

No

start operational Starts Alliance Access in operational mode.

You cannot start the servers if the database is being restored.

No

status [database|server]

Displays the status of the Alliance Access instance server or of thedatabase:

• Running

For the servers, the command also returns the mode: operational orhousekeeping.

• Not running or stopped

No

stop [force] Stops the Alliance Access server.

Use force to stop the Alliance Access server in a forced way. Theprocesses are killed at the operating system level instead of being stopped.

No

traceset<file_pathname>

Starts a trace using a configuration file <file_pathname> provided bySWIFT.

No

tracereset Stops the trace. No

Example: backup message archives

To back up two message archives, 20101231, and 20110101:

saa_system archive backup mesg 20101231,20110101 $ALLIANCE/usrdata/backup/mfa

Example: remove message archives

To remove two message archives, 20101231, and 20110101:

saa_system archive remove mesg 20101231,20110101

Example: restore a message archive

To restore a message archive:

saa_system archive restore mesg $ALLIANCE/usrdata/backup/mfa/MEAR_20101231_20110101

B.27 sa_splitOverview

The sa_split tool is used to split any large file into chunks. This can be used for outputs ofthe saa_supportinfo tool, or for any other files that Support may ask you to send on anexceptional basis.

Alliance Access 7.0 - Solaris

306 Installation and Administration Guide

Tool location

Solaris: <Alliance installation directory>/bin

Command syntax

sa_split [-size <size>] <filename> | -combine <filepath_name>

Parameters

Parameter Description Mandatory?

<filename> The name of the file to be split. No

-size Used to specify the size (in MB) of each chunk.

If you do not use this option, then each chunk has a default size of 2 MB.

The resulting files are named <filename>.xx, where xx is a sequencenumber (01..99).

No

-combine<filepath_name>

Combines chunks of a previously split file into a single file.

If the file specified already exists, then the tool returns an error.

No

To run the tool

1. From the System Administration application select xterm from the OS Configurationmenu.

2. In the xterm window, run the sa_split command with the required parameters.

B.28 swrpc_keytoolTool location

<Alliance installation directory>/BSS/bin/SunOS

Command syntax

swrpc_keytool

Prompts

The following table describes the prompts that you will receive. The default response ispresented in square brackets in the form [default]:

Step Prompt Response

a Do you want: 1: a self-signedcertificate 2: a certificate request[default, 1]:

If you select 1, then a self-signed certificate isgenerated, which is signed with itscorresponding private key. In this case, the CAcertificate and the certificate itself are identical.The subject and issuer of a self-signedcertificate are the same.

If you select 2 to generate a certificate request,then a PKCS-10 file (Request for Certificate) isgenerated. You must present this file to a CA(Certificate Authority) to receive a certificate. Inthis case, the subject and issuer of thecertificate are different. The subject is the DNyou entered in the certificate request and theissuer is the DN of the CA. To use server

Appendix B - Command Line Tool Syntax Reference

30 September 2011 307

Step Prompt Response

authentication in this case, you must receiveboth 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, thenthe file is created in the current directory.

c Enter a password of your choice: The key is password-protected. Select apassword that complies with your institution'spassword policy.

d Re-enter the password forverification:

Re-enter the password for verification: The newkey is now generated. Skip to prompt g.

e File name for the certificate: Enter the file name for your certificate. If the filealready exists, then you are prompted tooverwrite the file. If the file does not exist, thenskip to prompt j.

f Overwrite existing file? [default,n]:

Enter Yes (y) to overwrite an existing file, enterNo (n) to return to prompt h. You are nowprompted to enter the DN. For information aboutDN, see prompt l.

g File name for the certificaterequest:

Enter the file name for your certificate request. Ifthe file already exists, then you are prompted tooverwrite it. If not, then skip to prompt l.

h Overwrite existing file? [default,n]:

Enter Yes (y) to overwrite an existing file, enterNo (n) to return to prompt j.

i Enter the distinguished name (DN) tobe included in the certificate:Example:cn=SAA1,ou=department1,o=institution1.This DN will be needed if you want toconfigure authentication.

This DN can contain the following attributes:

• C for country

• ST for state or province

• L for location name

• O for organisation name

• OU for organisational unit

• CN for common name

• EMAIL for the e-mail address.

Enter the DN. A check is then performed on theDN.

For a certificate request, you are prompted forfurther input and for the key file and certificaterequest file.

j Number of days your certificate willbe valid [default, 30]:

Enter the number of days the certificate can beused. Default value: 30. Maximum: 3565.

B.29 systeminfoPurpose

The systeminfo tool is used to display information about the following items:

• system

Alliance Access 7.0 - Solaris

308 Installation and Administration Guide

• hardware configuration

• log files

• core file

• network status

Tool location

<Alliance installation directory>/BSS/bin/SunOS

Command syntax

systeminfo [2><error file>]

Parameters

Parameter Description Mandatory?

2><error file> Used to save the returned error in a file. No

To run the tool

1. From the System Administration application select xterm from the OS Configurationmenu.

2. In the xterm window, run the systeminfo command with the required parameters.

Result

The resulting file systeminfo.tar is located in $TMPDIR (if defined). The default path is /usr/tmp.

Appendix B - Command Line Tool Syntax Reference

30 September 2011 309

Legal Notices

Copyright

SWIFT © 2011. All rights reserved.

You may copy this publication within your organisation. Any such copy must include these legal notices.

Confidentiality

This publication may contain SWIFT or third-party confidential information. Do not disclose this publicationoutside your organisation without the prior written consent of SWIFT.

Disclaimer

SWIFT supplies this publication for information purposes only. The information in this publication maychange from time to time. You must always refer to the latest available version on www.swift.com.

Translations

The English version of SWIFT documentation is the only official version.

Trademarks

SWIFT is the trade name of S.W.I.F.T. SCRL. The following are registered trademarks of SWIFT: SWIFT,the SWIFT logo, the Standards Forum logo, 3SKey, Innotribe, Sibos, SWIFTNet, SWIFTReady, and Accord.Other product, service, or company names in this publication are trade names, trademarks, or registeredtrademarks of their respective owners.

Alliance Access 7.0 - Solaris

310 Installation and Administration Guide