Installation Guide 25 v1.1

TI PLUS/2.
5
INSTALLATION GUIDE
v1.1, May 2014
Copyright MISYS 1995-2014. ALL RIGHTS RESERVED. Registered in England No. 01360027. All rights reserved.
Registered Office: One Kingdom Street, Paddington, London W2 6BL, United Kingdom
TI Plus
Installation Guide v1.1
COPYRIGHT MISYS 1995-2014. ALL RIGHTS RESERVED.

Confidential - Limited Distribution to Authorized Persons Only, Pursuant to the Terms of the Misys License
Agreement through which you received your rights to use the Software associated with this guide. This guide
is protected as an unpublished work and constitutes a trade secret of Misys, One Kingdom Street,
Paddington, London, W2 6BL United Kingdom. Republication or redistribution, in whole or in part, of the
content of this guide or any other materials made available by Misys is prohibited without the prior written
consent of Misys. Any software, including but not limited to, the code, screen, structure, sequence, and
organization thereof, and documentation are protected by national copyright laws and international treaty
provisions. This guide is subject to U.S. and other national export regulations.
Misys does not guarantee that any information contained herein is and will remain accurate or that use of the
information will ensure correct and faultless operation of the relevant service or equipment. Misys, its agents,
and employees shall not be held liable to or through any user for any loss or damage whatsoever resulting
from reliance on the information contained herein or related thereto. This document contains information
proprietary to Misys. Misys does not undertake mathematical research but only applies mathematical models
recognized within the financial industry. Misys does not guarantee the intrinsic theoretical validity of the
calculation models used. It is the obligation of the customer to ensure that responsible decisions are taken
when using Misys products.
MISYS, MISYS CAPITAL MARKETS FUSION, MISYS KONDOR+, MISYS SUMMIT, MISYS SOPHIS,
MISYS KONDOR GLOBAL RISK, MISYS GLOBAL RISK, and the logos used with some of these marks, are
trademarks or registered trademarks of a member of the Misys group of companies in various countries
around the world. Any third party names or marks are the trademarks or registered trademarks of the
relevant third party.
For more information

Need more information? Read more about our products at http://www.misys.com/products.aspx. Or contact
your local Misys office at http://www.misys.com/contact-us.aspx.
Feedback
Do you have comments about our guides and online help? Please address any comments and questions to
your local Misys representative.
ii
TI Plus
CONTENTS
Chapter 1 System Overview
Architecture Summary
Hardware Components
Software Components
1
1
1
2
Chapter 2 Installing Software Prerequisites

Software Components
Recommended Installation Sequence
3
3
4
Chapter 3 Installation Summary

The TI Plus Software Distribution
Overall Installation Sequence
Installing the TI Plus Database
Configuring the TI Plus Application Archives
File System Resources
First Steps
5
5
5
5
5
6
6
Chapter 4 Database Setup

Creating the TI Plus Database
7
7
Chapter 5 Application Software

Software Distribution
13
14
Chapter 6 Application Topology

Configuring the Software
Application Server and Database
Application Communication
15
15
15
16
Chapter 7 Security
CAS Authentication
Pre-Authentication - x509
Pre-Authentication - General
Re-Authentication
17
17
18
19
19
Chapter 8 JNDI Resources

JNDI Patterns
JDBC Data Sources
JMS Resources
20
20
21
21
Chapter 9 Asynchronous Framework

Jobs and Steps
JMS Queues
Split Deployment
User Identification
22
22
23
24
24
Chapter 10 Notification Framework

Notifications
25
25
Chapter 11 Service Access

APIStubs
EJB
Plain JMS
Pseudo-Synchronous JMS
JMS Equation Interface
JMS Trade Portal Interface
Watch List Checker Interface
User Identification
26
26
27
27
28
29
30
31
31
iii
TI Plus
Bulk Message Handling Incoming

Bulk Message Handling Outgoing
32
32
Chapter 12 Cross Zone Dashboard

Cross-Zone Rebroadcaster
33
33
Chapter 13 Miscellaneous
UI Customisation
Document Window Recording
Amount in Words
PDF Document Watermarks
Deploying Help Text
Error Display
Local Module
File System Resources
35
35
36
36
37
37
37
37
38
Chapter 14 Application Server Specific

WebLogic - Configuring Session Cookie Domains
JBoss - Integrating Other JMS Providers
WebSphere Use Activation Specification
41
41
41
42
Chapter 15 Operating System Specific

Fonts for AIX and Linux
Graphics Support for Unix Without X-Windows
43
43
43
Chapter 16 WebSphere Setup

Initial Configuration
JDBC Configuration
JMS Configuration
Application Server Process Definition
Installing TI Plus 2 Software
Final Configuration Steps
44
44
44
44
48
49
49
Chapter 17 WebLogic Setup

JDBC Configuration
JMS Configuration
50
50
50
50
54
Chapter 18 JBoss 5.1 Setup

JDBC Configuration
JMS Configuration
55
55
56
57
65
Chapter 19 JBoss EAP 6.2 (AS 7.3) Setup

Pre-Requisite Software
Management Console
Defining Servers
Configuring Profiles
66
66
66
68
72
72
79
Chapter 20 First Steps

Starting the TI Plus Software
Installing TI Plus Products
Uploading the Document Templates
80
80
80
82
iv
TI Plus
PREFACE - INSTALLATION GUIDE

This Guide explains how to install, configure and deploy TI Plus. It assumes knowledge of the operating
systems, database management system and 3rd party products used during the installation process.
The User Guide contains the following chapters:
Chapter
Description
Chapter 1
provides an overview of the Trade Innovation system, summarising the individual hardware and
software components.
Chapter 2
discusses the software prerequisites and a recommended installation sequence.
Chapter 3
provides summary details on what is involved in creating the TI Plus database and deploying TI
Plus to an application server.
Chapter 4
details how to create the TI Plus database.
Chapters 5-14
provide information about various components of the TI Plus applications and the configuration
options associated with them.
Chapter 15
details operating system specific areas of set up.
Chapter 16
details how to set up WebSphere 7/8.5.
Chapter 17
details how to set up WebLogic 10.3.
Chapter 18
details how to set up JBoss 5.1.
Chapter 19
details how to set up JBoss EAP 6.2 (AS 7.3).
Chapter 20
details the first steps to perform after the software is deployed.
DOCUMENT CONVENTIONS
The convention used in the Guide for identifying links accessed via drop-down lists from other links is to cite
the name of the first link, followed by name of the second link separated from it by a '|' character - for
example, Other|FX Calculator'.
Note: This format is used for notes that contain information of more than usual significance, such as
warnings or hints on using the software.
In the tables listing fields in windows, a tick next to a field indicates that the field is mandatory.
FURTHER READING
TI Plus is supported by a comprehensive documentation set, which includes user guides for each TI Plus
product:
TI Plus Documentation Overview lists each of the documents in the set and explains what it covers.
TI Plus Common Facilities User Guide explains common screen elements shared by TI Plus
products and is referred to where required in this guide.
TI Plus
CHAPTER 1 SYSTEM OVERVIEW

This chapter provides an overview of the possible TI Plus 2 system architectures. It outlines the roles of the
main architecture components and summarises their hardware and software.
ARCHITECTURE SUMMARY
The following diagram illustrates the gross software architecture of the system showing the operation of
multiple processing zones (these are the zones of a 'global processing' architecture).
Global Application
Global Application
Database
Zone Database
Zone access
tiplus2 application
(Clusterable on J2EE)
HTTP(S)
HTTP
HTTP Server
Front Office
System
Content
Management
System
Back Office
System
Zone access
tiplus2 application
(Clusterable on J2EE)
Zone Database
As the diagram shows, the TI Plus 2 software consists of two enterprise applications:
Global application A management application providing user management and zone control
facilities
Zone access tiplus2 application The trade finance application. This application can be deployed
multiple times, each configured to use a dedicated zone database
Both types of application may be installed in a cluster, however for the global application, the number of
server instances in the cluster must be limited to two, and each must be on a separate host.
HARDWARE COMPONENTS
The table below lists and describes the function of the hardware components of the system.
Component
What it does
Network
Allows the individual components of the system to communicate
Database Servers
Acts as database storage for TI Plus business data
Application Servers
Runs the TI Plus Enterprise Application. This provides middleware services for
security and state maintenance, along with data access and persistence
1
TI Plus
Component
What it does
HTTP Server
Provides an access point for load balancing
Client PCs
Client PCs run a web browser (e.g. Internet explorer) to communicate with the
web/application server
SOFTWARE COMPONENTS
The table below lists and describes the software components of the system.
Component
What it does
Trade Innovation
application
Main application for TI Plus. This runs on the application server
Windows 2008 Server 64bit
Operating system for the Application and Web Server or Database Server
Solaris 64-bit
AIX 64-bit
Red Hat Linux Enterprise

Server 64-bit
Oracle 11g
Serves as the Database repository for the TI Plus 2 application. Installed on the
Database Server
DB2 v9.7
Serves as the Database repository for the TI Plus 2 application. Installed on the
Database Server
WebLogic 11g (10.3.6)
Serves as the Application server and hosts the TI Plus 2 enterprise applications
WebSphere 7.0/8.5
JBoss 5.1
JBoss EAP 6.2 (AS 7.3)
HTTP Server
The software choice for the HTTP server is largely driven by the chosen application
server. It may be that an existing HTTP server can be used
Microsoft Word
Used to create document templates which are uploaded to and utilised by the
application to produce associated documents during user transactions
Content Repository
Storage location of files used and managed by the application
Web Browser
Browser Software for accessing the TI Plus application on the application server.
TI Plus
CHAPTER 2 INSTALLING SOFTWARE PREREQUISITES

This chapter provides details of the software prerequisites and the order in which they should be installed
SOFTWARE COMPONENTS
The required software is broken down by the following components:
The Database Server
The Application Server
The HTTP Server
Client PCs
Note: This Guide does not provide instructions on installing software components supplied by a third party
vendor. All these products come with comprehensive installation guides which must be consulted prior to
implementation.
The Database Server

The database server contains the Trade Innovation application business data. Currently, Oracle 11g or DB2
v9.7 or later is the supported database software. It is essential that the data is backed up on a regular basis,
and a backup device and backup software are therefore required.
Solaris or Windows 2008 or equivalent
Oracle 11g/DB2 v9.7
The Application Server

The application server contains the WebLogic, WebSphere or JBoss application server software and the
main TI Plus application components.
AIX, Solaris, Red Hat Linux Enterprise Server or Windows 2008 Server or later based on the
application server support
JavaSE6 may be installed as part of the application server installation
WebLogic 11g, WebSphere 7.0/8.5 or JBoss 5.1/EAP 6.2 (AS 7.3)
HTTP Server
The software required for the HTTP Server is largely based on the choice of application server software. For
instance WebSphere, IBM's HTTP Server software is supplied as part of the software package.
The only prerequisite is that the HTTP server software is supported by the application server software.
Client PCs
Client PCs using a web browser will be used to access TI Plus. A plug-in for viewing PDF files will also be
required to view documents and reports.
TI Plus
RECOMMENDED INSTALLATION SEQUENCE
It is recommended that you perform installation and configuration in the following sequence.
Install the operating system and all necessary patches on the designated database server.
Install the database software.
Install the operating system and all necessary patches on the designated application server.
Install JavaSE6 on the Application server(s) if necessary.
Install WebSphere/WebLogic/JBoss software on the Application server(s).
TI Plus
CHAPTER 3 INSTALLATION SUMMARY

This chapter summarises the steps involved in installing, configuring and deploying the TI Plus software.
THE TI PLUS SOFTWARE DISTRIBUTION

The TI Plus software distribution consists of the following folders.
/csv contains product configuration files
/scripts contains the database scripts
/sdk contains tools and resources associated with the SDK
/software contains the application software
/ti contains various resources
/tools contains utilities
OVERALL INSTALLATION SEQUENCE

Once you have installed and configured all the third-party prerequisites, it is recommended that you take the
following approach to installing the TI Plus 2 software.
Create the TI Plus 2 database schemas and run the appropriate scripts
Set up the required topology of application server instances to deploy the TI Plus 2 software into
Configure and assemble the TI Plus 2 application archives
Configure the application server including setting up JNDI resources (JDBC, JMS etc)
Deploy help text
Set up remaining file system resources
Install the TI Plus2 application archives to the application servers
Perform the first steps of starting the servers, installing the products and uploading default document
templates
INSTALLING THE TI PLUS DATABASE

It is assumed that before starting on creating the TI Plus 2 database, you have already done/obtained the
following:
Administrator privileges on the Operating systems
Installed Oracle/DB2 on the database server
Login credentials with admin and DBA roles
CONFIGURING THE TI PLUS APPLICATION ARCHIVES

The delivered software includes configuration utilities allowing the following main options to be chosen:
Application names
Choice of application server to be used
Security to use
Choice of service access options, including an incoming EJB server, support for JMS-based access,
including the Trade Portal Interface, and a test utility to help familiarise with the service interfacing
operations
User interface customisation facilities including translation and control suppression
Integrating a local project when set up

5
TI Plus
FILE SYSTEM RESOURCES

There are some resources required that are currently expected to be stored on the file system of the
application server. Their location can be configured. They include:
Configuration files (CSV)
Folder for user interface customisation files in development
Translation files for Document data content.
FIRST STEPS
This section summarises the additional steps that must now be performed after the applications have
successfully started, but before the TI Plus applications can be run
Use the configuration application to initialise the TI Plus database
Grant capabilities to the supplied user SUPERVISOR
Review and configure the system options available
Use the Static Data application to add one or more branches and main banking entities
Set up teams roles and users as require, as well as setting up the users in the global application
Refer to the TI Plus Static Data Maintenance Guide, TI Plus System Tailoring Guide and TI Plus Security
Guide for more details.
TI Plus
CHAPTER 4 DATABASE SETUP

It is assumed that before starting on creating the TI Plus 2 database, you have already done/obtained the
following:
Administrator privileges on the Operating systems
Installed Oracle/DB2 on the database server
Login credentials with admin and DBA roles
Database creation scripts are supplied in the /scripts folder of the software release. Upgrade scripts are
also available where appropriate. For information on which upgrades scripts are appropriate, refer to the
release notes accompanying the software.
CREATING THE TI PLUS DATABASE

To set up the TI Plus database, several scripts included in the /scripts folder have to be executed. The
scripts are provided with .tpl extensions so they are not confused to be sql scripts that can be run with any
utility. If you need to generate standard sql scripts, they can be created using the SQLRunner utility
described in the next section.
SQLRunner
In the /tools folder of the software distribution is a utility called SQLRunner that allows you to
Execute a script against a nominated database
Provide parameter values to be substituted while executing the script
Save a copy of the script with the parameters replaced in order to run the script via a preferred utility
Run scripts from the command line
This utility is a Java Swing application, and requires JavaSE6 to be installed.

Unzip the software from /tools/sqlrunner into a local folder.
Open a command window and navigate to the folder containing the software. Enter the following command:
java jar com.misys.tiplus2.utils.sqlrunner.jar
This will bring up the first page of the utility:
TI Plus
This panel allows you to choose if the script is to be run against a database or simply saved after replacing
the parameters. The following steps illustrate executing a script against a database.
Enter the details:
Option
Description
Execute script
Driver
The name of the database driver to use
URL
The URL for the database. For Oracle this will be in the form:
jdbc:oracle:thin:@<host>:1521:<database>
whereas for DB2 it will be:
jdbc:db2://<host>:50000/<database>
User
User id
Password
Password of the user
Save script to folder

Folder
Folder where the substituted script will be saved the name of the script will be the
same as the script selected on the next panel
The Test button is available to verify that the connection details are correct.
Click Next.
Locate the script you wish to run. A description of the script will be displayed when it has been selected.
If the script is a template that extracts information from the database, then you must specify an output folder
and file extension.
Note: Note that this folder must already exist. If it contains any files, you will be prompted to confirm that
these files may be deleted.
TI Plus
Click Next.
This panel lists the parameters defined in the script and if applicable may already have default values
assigned. Selecting a parameter will provide a description with any special considerations that are required
for the values supplied.
Once the parameter values have been entered, click Next.
TI Plus
This panel summarises the information collected so far. Click Run to execute (or save) the script.
This panel shows the progress of the script, and when the script is finished, the following dialog is shown:
If an error is encountered then the following dialog is shown:
10
TI Plus
This shows the details of the exception, and provides four options in the dropdown box:
Ignore exception and continue
Ignore all further exceptions and continue
Stop execution
Stop execution and save remaining part of script
The last option allows you to provide a file name which will be used to save the remaining part of the script
still to be executed.
Once a script has been executed, by pressing the Back button, you will go back to the script selection panel.
Note that parameter values will be retained.
You can also call this utility from a command script and bypass the user interface. The parameters to pass
are as follows:
Option
Description
-c,--class <classname>
The database driver class
-d,--url <URL>
The database URL
-g,--cmd
Suppresses any UI
-h,--help
Print this message
-i,--input <file>
Input file of command options
-l,--log <file>
Log file location
-m,--mode <E=execute|S=save:<folder>>
The mode - execute or save
-n,--extn <extn>
Output file extension (default '.txt')
-o,--output <folder>
Output folder - for SQL selects
-p,--password <pwd>
The database user password
-q,--sql <file>
The database SQL script to run (*.sql)
-r,--param <property=value>
Parameters for substitution
-t,--quiet
Suppresses confirmation and other logs
-u,--user <id>
The database user id
-w,--onexceptionfile <file>
File to write remaining SQL on exception (-x S must exist)
-x,--onexception <I|S|W>
SQL exception handling I=ignore, S=stop, W=write

remaining SQL to file
Oracle
It is expected with Oracle, that separate schemas will be used in the same database. Create the schemas for
the global (TIGLOBAL) and zone (TIZONE1) tables by creating these two users.
Run the oGlobals-xxxx.tpl database script using the script runner. For the Schema Name for
Trade Innovation, use TIGLOBAL, instead of the default TRADEIN1
Run the database scripts below using the script runner. For the Schema Name for Trade Innovation,
use TIZONE1, instead of the default TRADEIN1.
oTIxxxx.tpl
oeqxxxx.tpl
oaf-xxxx.tpl
onf-xxxx.tpl
oCextxxxx.tpl
ocmsxxxx.tpl
Note: Note that with version G.1.1 of the database, a transition was made from using unique indexes to
11
TI Plus
using primary keys. To provide that transition, the scripts oDIxxxx.tpl and oCPKxxxx.tpl must also be
run after the rest of the scripts to delete the unique indexes and then create the primary keys.
Note that the TI Plus application accesses the database using an XA database driver. If the user used to
connect to the database does not have sufficient privileges, you may see XA exceptions in the application
logs. In this case, the following privileges need to be granted to the user:
grant select on pending_trans$ to <user>;
grant select on dba_2pc_pending to <user>;
grant select on dba_pending_transactions to <user>;
grant execute on dbms_xa to <user>;
DB2
It is expected that a database will be created for the global application and each of the zone applications.
Run the Globals-xxxx.tpl database script using the script runner
Run the following database scripts for each zone database using the script runner in sequence.
TIxxxx.tpl
eqxxxx.tpl
af-xxxx.tpl
nf-xxxx.tpl
Cextxxxx.tpl
CMSxxxx.tpl
Note: Note that with version G.1.1 of the database, a transition was made from using unique indexes to
using primary keys. To provide that transition, the scripts DIxxxx.tpl and CPKxxxx.tpl must also be run
after the rest of the scripts to delete the unique indexes and then create the primary keys.
Reporting Views
Reporting views are supplied in the scripts:
rvcxxxx.tpl
rvdxxxx.tpl
The first script creates the views, while the second script drops the views. So, during an upgrade process, it
is necessary to run the rvdxxxx.tpl script of the current version of the database. Once the upgrade
scripts have been run, the rvcxxxx.tpl script of the new version may then be run.
Note: These scripts may be run against both DB2 and Oracle databases.
12
TI Plus
CHAPTER 5 APPLICATION SOFTWARE

The TI Plus applications include both web and ejb modules that can be deployed on WebSphere, WebLogic
and JBoss, as well using DB2 or Oracle as the DBMS. The configuration options provided cover, among
other things, interfacing, security and customisation.
The interfacing options provided include:
Multiple incoming and outgoing JMS queues
Incoming RMI calls to an EJB session bean
Bank written components
The security options provided include:
Embedded single-signon capability using the open source CAS server
Pre-authentication scenarios such as client x509 certificates or network proxy-based systems
The customisation facility allows extra fields to be added for customer details, transaction master and event
details, and posting details. This extra data can be used in processing rules and referenced in customer
documents. The output of using this facility includes:
Database scripts
Web resources for UI
Generated java to handle the defined fields
Extensions to message definitions
Optionally extra hand-written business logic
In these three areas of interfacing, security and customisation:
New components/resources may need to be included
New JNDI resources may need to be defined
Deployment descriptors may need to be updated (both general JEE and application server specific)
Manifest classpath references altered
Configuration files created/updated (not just properties but spring configuration files as well)
The provided assembly mechanism for the enterprise archives driven by a declared configuration enables
this level of flexibility in our software. It also provides an additional level of security where if an external
access mechanism is not required (e.g. RMI access, or an alternate security configuration not requiring the
CAS server), it is not simply disabled - it is not included to be deployed at all.
Some of the properties defined may seem to tie an EAR file to a particular deployment environment,
however those properties are created as web.xml environment entries. These entries may then be changed
or overridden during or after deployment in one of the following ways (listed in the order that they are
loaded):
Defining them as system properties
Defining them in a property file called <deploymentId>.environment.properties located

externally on the classpath
Overriding the environment entries from the web.xml file
Overriding the web.xml environment entries is application server specific - in WebLogic it is done through
deployment plans, in WebSphere you can change them as part of deployment if you script the deployment,
or you can change them through the admin console. In JBoss it is less clear, as there is no inherent way of
doing this. So the remaining options must be used instead.
This means that when a final configuration is arrived at after all customisation is performed, the resulting
EAR files produced may be deployed to multiple systems through a promotion process resulting in the
production system, by updating these properties as appropriate.
13
TI Plus
SOFTWARE DISTRIBUTION
The /software folder in the main distribution has four main subfolders:
/applications - used as a target for software assembly
/components - holds the master software
/configuration - location of configuration files
/lib - tools used for assembling the software
When the application archives are assembled, the folders /assembly and /deploy are created under the
/applications folder. Once assembled, the enterprise archives are located in the /deploy folder.
The /components folder contains two subfolders, /modules and /system. /modules contains the
optional components that may be required, whereas /system contains the core software.
The /configuration folder contains master configuration property files used to drive the assembly
process.
The /lib folder contains utility code, including ant, which is used to perform the assembly.
Once the configuration options have been specified, the software is assembled by running the ant build
script from the root /software folder. For Windows, a build.bat file is supplied to auto-configure using ant
to run the build script. A build.sh script is supplied that runs on Linux, but can be adapted to the preferred
shell script format.
The following chapters provide information about various features of the applications and the configuration
options associated with them.
14
TI Plus
CHAPTER 6 APPLICATION TOPOLOGY

The TI Plus software consists of two JEE applications - the global application and the tiplus2 application. The
global application is a management application, whereas the tiplus2 application provides the trade finance
business functionality. When a user accesses a deployment of the tiplus2 application, they are connected to
a zone database.
A running system will consist of a single instance of the global application, and one or more deployments of
the tiplus2 application, providing access to one or more zone databases.
The global application provides control access to the tiplus2 application deployments, enabling zones to be
suspended and users accessing those zones to be logged off. This management communication facility
limits to two the number of servers in a cluster that the global application can be deployed - a primary and
secondary server. Moreover, these server instances must be bound to different host names/IP addresses.
A tiplus2 application on the other hand is not limited by the number of servers in the cluster it is deployed to.
CONFIGURING THE SOFTWARE

The assembly scripts allow for a single global application enterprise archive file, and multiple tiplus2
application enterprise archive files to be created at once. A property file must be configured for each.
In the /configuration folder, there are two master property files:
master.global.configuration.properties
master.tipus2.configuration.properties
Copy the master.global.configuration.properties file to be
global.configuration.properties, and for each tiplus2 deployment copy
master.tiplus2.configuration.properties to be
xxxxx.tiplus2.configuration.properties the value of xxxxx is not significant.
These files then need to be changed using a text editor. The properties are described in the following
sections.
Note that there are two formats of property names lowercase dot-separated, and camel-case. The
difference is that the camel-case properties are also added to the relevant web module deployment
descriptor as <env-entry> values.
APPLICATION SERVER AND DATABASE

The supported application servers are WebLogic, WebSphere and JBoss. The supported databases are DB2
and Oracle. For particular version support - see the Overview chapter.
Each application instance must have a name, and a URL context.
Configuration
The following properties can be defined in the global.configuration.properties file:
Property
Description
appserver.weblogic
appserver.websphere
appserver.jboss
Only one of these properties may be specified - indicating which application

server is being used
appserver.jee6
Setting this property provides support for JBoss EAP 6.2 (AS 7.3)
database.oracle
database.db2
Only one of these properties may be specified - indicating which database is

being used
global.app.name
Name that will be used for the global application archive the default is
tiplus2-global
GlobalAppContext
Used to define the context URL for the global web module the default is
tiplus2-global
GlobalURL
Full URL of the global application. This is used to navigate back to the global
application when exiting form the zone. Make sure the protocol is correct in
relation to the security configuration used
15
TI Plus
Property
Description
GlobalSchema
Schema name for the tables created for the global application - for DB2 this
would be TRADEIN1, for Oracle TIGLOBAL
The following properties can be defined in the tiplus2.configuration.properties file:

Property
Description
DeploymentId
Identifier for this tiplus2 deployment - defaults to TI1
tiplus2.app.name
Name that will be used for the tiplus2 application archive default is
tiplus2-deploy1
TIPlus2AppContext
Used to define the URL for the web module default is tiplus2-deploy1
ZoneId
Identifier of the zone used by this deployment
APPLICATION COMMUNICATION
The communication between the global application and multiple deployments of the tiplus2 application uses
JMX. As each server running a tiplus2 application deployment starts up, it will connect to the global
application and register itself, and its own configuration, enabling the global application to connect back to it.
As each user logs in and accesses a zone database, their access via a particular server in the cluster is
registered. When a zone is suspended, then those users accessing that zone database are prompted to log
off when they next send a request to the server.
The limitation of two servers to a global application cluster is due to the JMX protocol used, which does not
work in a federated environment. So one of the server instances is nominated as the primary server to which
all tiplus2 application servers connect to register. If the primary server is not available, or a connection to the
server is lost, then the attempts are made to connect to the secondary server. If the secondary server itself
loses contact with the primary server, then it promotes itself to be the primary server, and will accept the
incoming server registration requests.
As part of the registration request, details are passed so the global application can connect back to the
tiplus2 application server.
Configuration
In the global.configuration.properties file, the following properties are set:
Property
Description
JMXPrimaryHost
Host name of the primary global instance
JMXSecondaryHost
Host name of the secondary global instance (may be left blank)
JMXGlobalPort
Port number of the global instance
JMXProtocol
Protocol of JMX communication currently only RMI is supported.
These values are used by the global application as well as the tiplus2 application instances.
If failover is not required, then the JMXSecondaryHost may be left blank. Note that when the global
application starts it queries the host name from the network stack. The host name returned must match the
Primary or Secondary host names. It may be that the host name is returned with a domain suffix. If the global
application cannot match the host name, an error is logged during initialization together with the host name
returned from the network stack. This must then be used to update the host property.
In the tiplus2.configuration.properties file, the following properties are set:
Property
Description
JMXZonePortStart
Start port number
JMXZonePortEnd
End port number
While instances of the global application must be on separate hosts, there may be multiple server instances
of a tiplus2 application deployment on the same host - so a range is required. The number of ports available
in the range must be at least equal to the number of server instances that that application can have on a
single host.
16
TI Plus
CHAPTER 7 SECURITY
Since the TI Plus software consists of at least two applications, it requires a single-signon authentication
environment.
TI Plus was designed to integrate with different authentication environments. To achieve this, the spring
security framework is used to provide a chiefly configuration-based solution, to provide the highest flexibility.
Two single-signon models are supported:
Co-operative authentication
Pre-authenticated
The co-operative model relies on the configuration of an authentication server that can be redirected to and
also called directly to verify any token or ticket issued. This model is used to provide the default configuration
of the software by bundling an open source single-signon server (CAS - central authentication server) in the
global application.
The pre-authentication model relies on network or application server configuration to force authentication
before access is made to the application. If the user cannot be derived from the request, then access is not
allowed. Two configurations are provided to achieve this - one based on client certificates, and the other a
little more generic that can reference a configured HTTP header to extract the user id.
Note that whatever authentication mechanism used, the user must be defined in the user registry in the
global application database.
CAS AUTHENTICATION
An open source single-signon server is embedded in the global application, and both global and tiplus2
applications reference the server to issue tickets based on user authentication. These tickets are then
verified explicitly by a direct connection from the server being accessed to the CAS server.
By default, only the authentication part of the server access is via HTTPS, however it is possible to enforce
HTTPS for all access to the application.
Authentication is performed by presenting a login page, accepting a user id and password. The password is
checked against the password stored in the user registry in the global application database. The password is
stored using a one-way encryption algorithm.
An alternate configuration allows the credentials captured to be verified via Windows Active Directory server
using LDAP.
Note that if the global application is clustered, then there needs to be a trust relationship between the
application servers and the issuer of the SSL certificate of the HTTP server being used as the load balance
point of the global application.
Configuration
Property
Description
security.cas
This property must be defined to enable the CAS configuration
security.cas.https
Set this property to force all access to the application to be via HTTPS.
CASServerURL
This is the URL for the CAS server - as the CAS server is embedded in the
global application, this is the HTTPS URL for the global application https://<global-host>:[<port>]/tiplus2-global
CASServiceURL
This is the HTTPS URL of the application to be authenticated for - this turn
out to be the HTTPS URL of the global application https://<global-host>:[<port>]/tiplus2-global
In the tiplus2.configuration.properties file, the following properties are set:

Property
Description
CASServiceURL
This is the HTTPS URL of the application to be authenticated for - this turn
out to be the HTTPS URL of the tilus2 application https://<tiplus2-host>:[<port>]/tiplus2-deploy1
17
TI Plus
If authentication is required by a Window Active Directory server, then the following properties must be
defined in the global.configuration.properties file:
Property
Description
security.cas.ldap
This property must be defined to enable the LDAP configuration to be

applied
security.cas.ldap.host
Active Directory server name
security.cas.ldap.port
Port number for access to server (typically 389)
security.cas.ldap.base.dn
The base distinguished name and template for searching. This is of

the form:
<root_dn>?sAMAccountName?sub?(objectClass=*)
Where <root_dn> is the distinguished name of the active directory
domain name broken down into domain components. So if the
domain name is bank.domain.com, the <root_dn> is:
DC=bank,DC=domain,DC=com
A search user on the domain that has at least browse access. The
search user executes the search for the user to authenticate. The
credentials entered are then used to connect that effectively verifies
the password. It is specified in the form of an e-mail address:
security.cas.ldap.user
search_user@bank.domain.com
security.cas.ldap.password
Password of the search user
security.cas.ldap.search.base
Base node to start searching from (typically cn=users)
security.cas.ldap.search.filter
The search string to use. This must be compatible with the template
specified previously. Which is:
(&(sAMAccountName={0})(objectclass=user))
Note: The email format for users is not required when adding users or logging in.
The database creation script for the global application database has a pre-defined user called
SUPERVISOR. To set up other users you can do one of the following:
Configure the application not to use LDAP to start with, and add at least one user that is already
defined in the domain and make them a Security Officer. LDAP can then be enabled, and the new
user used to set up all of the others
Add SUPERVISOR to the active directory before first logging in with LDAP enabled
Update the creation script to change SUPERVISOR to a user already defined in the active directory
domain. The application can then have LDAP enabled.
PRE-AUTHENTICATION - X509
If authentication via client certificates is required (using smart cards for instance), then the configuration
relies on the HTTP server (or HTTP component of a single application server) being set to enforce client
certificates, and also to be responsible for checking that the certificate presented is not on a revocation list.
When the user access the application, the certificate is extracted from an HTTP header, and using a
configured regular expression, the user id is identified.
Configuration
Property
Description
security.x509
This property must be defined to enable the x509 configuration
security.x509.regexp
This property represents the regular expression required to extract the user
id. The default expression is CN=(.*?)$, which extracts the content of the
last CN= component at the end of the name sequence
18
TI Plus
PRE-AUTHENTICATION - GENERAL
If your network infrastructure relies on proxy servers to verify all HTTP access is authenticated, then the
configuration relies on the users user id being added as an HTTP header.
In this configuration, all authentication is expected to be performed before access to the application is
permitted. By default all access is assumed to be over HTTP. It is possible to fore all access to be via
HTTPS.
Configuration
Property
Description
security.preauth
This property must be defined to enable the pre-authentication

configuration
...preauth.https
If all access to the application needs to be via HTTPS, set this

property to yes
...preauth.principal.header
The name of the HTTP header that will contain the user id.
...preauth.credentials.header
If credentials are passed on a separate header, then it can be set

here - though it will not be used
Note: Note that the property names have had the security prefix omitted for readability.
RE-AUTHENTICATION
It is possible to configure TI Plus to require the user to re-enter their password when processing a
transaction after it has been input. Details of this functionality can be found in the System Tailoring Guide.
The re-authentication process is currently only supported when using the CAS single-signon configuration.
Note that when using this facility, it is necessary to control how the session cookies used by each application
are processed - keeping them separate for the global and tiplus2 applications.
Configuration
Property
Description
security.reauthenticator
This property must be set to activate the re-authentication

configuration
security.reauthenticator.cas
This property must be set to yes to also include the CAS

implementation
19
TI Plus
CHAPTER 8 JNDI RESOURCES

The TI Plus software uses JNDI to look up resources for
Database connections
JMS queue sessions for read/write
Email server sessions
Apart from message driven beans, the mapping of JNDI resources from a local name to a global name is not
defined in application deployment descriptors. This operation is performed on demand.
When defining JNDI resources, each application server (WebSphere, WebLogic and JBoss) have different
ways of targeting JNDI resources. For WebSphere, JNDI names can be defined at the Cell, Node, Cluster or
Server level, and when a resource is looked up, these levels are checked in order of specific (Server) to
general (Cell). So it is possible to define different resources with the same name for different servers.
WebLogic allows targeting of resources to particular servers or clusters, while JBoss expects all appropriate
resources to be defined for each server deployment.
Since it is possible to deploy multiple tiplus2 application instances to the same server (each accessing a
different zone), there also needs to be a mechanism for being able to provide different resources of the same
JNDI identifier in the same server.
JNDI PATTERNS
To be able to provide a local to global mapping facility that can work at a lower level than a particular server,
then JNDI patterns can be specified that at runtime will be used to resolve to the global JNDI name.
A JNDI identifier is made up of a category and name for instance jdbc/zone where jdbc is the category,
and zone is the name. The category is used to locate the pattern to be used. Patterns are defined in the
jndi.resource.locator.properties file.
Given a local JNDI name for instance jdbc/zone, then the following properties are checked in order until
one is encountered:
jndi.jdbc.zone
jdbc.pattern
jndi.pattern
There will always be a default in the form of jndi.pattern.

The pattern can be a fixed string, or text with parameters defined. The following parameters are available:
${deployment}
${zone}
${category}
${name}
The simplest of patterns is ${category}/${name} which simply maps the local name to be the global
name.
Configuration
A master.jndi.resource.locator.properties file is supplied with default patterns for the different
application servers. Copy or rename this file to be jndi.resource.locator.properties. Uncomment
the properties for the relevant application server where the properties have values.
For instance for WebLogic, uncomment the appropriate jndi.pattern property only.
For JMS-based resources, though it is possible to use ${zone} as a parameter it is more appropriate to use
${deployment} instead. Especially as this property file is used when creating the deployment descriptors
for message driven beans.
20
TI Plus
JDBC DATA SOURCES

The following JNDI names for JDBC datasources need to be defined using the appropriate XA database
drivers:
jdbc/global for access to the global application database
jdbc/zone for access to the zone application database
jdbc/reports for access to the zone application database for reports
jdbc/dlzone for access to the zone application database for departmental limits
Configure the connection pool sizes as follows:
for the global connection pool, configure twice the number of expected concurrent users
for the zone connection pool, configure twice times the number of concurrent users and add twice
the number of async framework slots.
JMS RESOURCES
JMS resources are discussed in subsequent chapters.
21
TI Plus
CHAPTER 9 ASYNCHRONOUS FRAMEWORK

The async framework component provides a means to execute long running processes in the background. It
is used by the following features:
Ad-hoc reporting
End of day
Transfer of postings/deal etc.
Transfer of SWIFT or corporate access system messages
Printing or emailing documents
Processing incoming service requests
The framework is an independent generic facility that the tiplus2 application makes use of and provides
function-specific enquiries to provide monitoring and control. There is also a generic lower-level enquiry that
provides access to some repair features not available at the functional level.
JOBS AND STEPS

The async framework models jobs that are made up of multiple steps that need to execute before the job is
deemed complete. The job is responsible for defining and managing the sequence in which the steps that
provide the business functionality are executed.
There are three types of job:
Those that must run in isolation (sequential)
Those that can run in parallel with each other (parallel)
Those that can run at any time (utility)
These rules can be applied at two levels at the zone level, or within a named stream. If a sequential job
needs to start at the zone level, then no other parallel or sequential job can already be running either at the
zone level or within a named stream. A sequential job can start in a named stream if no sequential job is
running at the zone level, and no other sequential or parallel job is running in the named stream.
There is a limit to the number of jobs that can be run at once. This is controlled via tuning parameters
defined in the global application for the deployment. When a deployment is defined in the global application,
a single tuning parameter is creating defining the total number of slots available for the async framework in
that deployment.
A slot represents a running step. By default the minimum number of slots a job can use is 1. So the default
tuning parameter provides the maximum number of jobs that can run at once inside a deployment. There are
other tuning parameters that may be set available:
Maximum number of slots at the zone level
Maximum number of slots for a particular job in a particular zone and optionally a particular stream
Maximum number of instances of a named parallel job that can run at the same time
Maximum number of named steps within a job that can run in parallel
Minimum number of slots to assign to a named job
As jobs start, they are allocated an equal share of available slots unless they are capped by the tuning
parameters by name. Some jobs only require a single slot as they are made up of one or more sequentially
running steps. In which case when they are initiated, they declare they are single stream. This then is taken
into account when sharing out the remaining slots.
The maximum number of slots at the zone level is really to limit the number of jobs that can be started for a
zone. So if there is a tuning parameter that sets the maximum number of slots for the zone to 5, then it will
limit the number of jobs that can be started not cap the number of slots for the zone. So if there are three
jobs running already each requiring a minimum of 1 slot, two more of the same type could be started
before jobs would have top wait until a running job finishes. If the number of slots defined at the deployment
level is 10, then the 5 jobs would run with 2 slots each.
The sequence in which steps for a job run, is based on a steps dependency. Steps with no dependency are
run first and as they complete, steps that are dependent on them are eligible to run. These steps are then
run in turn until there are no more steps left to run.
22
TI Plus
Steps can go into a waiting state, which means that after the call to the step object completes, the object is
thrown away, and a timer is set to a configurable period. After this period is complete, the step is re-created
and called to check if the step can complete. This mechanism is only used where the purpose of a step is to
initiate something, and then wait until it is complete.
If a step needs to be re-attempted at a later time, it can ask for the job to be postponed for a period of time.
Once that time is reached, the job is eligible to be restarted from where it left off.
The difference between the two features is that for waiting steps, the job is still executing, and may be
preventing other jobs from running.
Configuration
In the tiplus2.configuration.properties file, the following properties can be set:
Property
Description
monitor.period
This property represents the number of seconds to wait before

calling a step that is waiting to see if it can complete the default
is 300 seconds
transfer.postpone.period
When transferring postings, SWIFT messages or customer access

system messages, if the receiving system is unavailable, then the
transfer job will be postponed. This property represents the time in
seconds to wait before re-running the transfer job default 600
seconds
JMS QUEUES
Jobs and steps are processed by messages sent to JMS queues. There are three main queues:
Job lifecycle queue
Job execution queue
Step execution queue
The job lifecycle queue deals with initiating jobs, allocating slots to them and marking them as complete. The
job execution queue handles all messages to do with executing and completing steps, and managing which
steps should be executed next. The step execution queue handles messages to do with executing business
functionality.
Both the job lifecycle and job execution queues are fully transactional, so they may be configured with a
number of retries before being delivered to a fourth dead message queue. The step execution queue is not
fully transactional, however repair facilities are available to retry or bypass steps that have not completed
successfully.
Configuration
The JNDI names for the queues are:
queue/JobLifecycleQueue
queue/JobExecutionQueue
queue/StepExecutionQueue
queue/DeadMessageQueue
The JMS queue connection factory JNDI name is:
jms/QueueConnectionFactory
23
TI Plus
SPLIT DEPLOYMENT
Ordinarily, the async framework is deployed along with the rest of the tiplus2 application. A drawback of this
is that users accessing the system are competing for resources with these long running processes.
It is possible to deploy the async framework as a standalone application which can then be sized and
controlled independently from the rest of the application. The remaining tiplus2 application only requires
access to the JMS server used by the standalone deployment, and references to the job lifecycle and job
execution queues. The remaining queues are used by the async framework alone.
Configuration
Property
Description
deployment.split
Uncomment this property to enable the async framework to be deployed

independently
When the applications are assembled, if this property is set, this configuration will generate two enterprise
archives. One with the same name as usually expected, and the second ending with -async.
USER IDENTIFICATION
Jobs that are processed through the async framework will adopt a common user id. This is to focus the
security features for users on allowing to jobs to be initiated rather than what the jobs actually do.
Configuration
Property
Description
DefaultBatchUser
The user specified in this property will be used as the default user for async jobs
24
TI Plus
CHAPTER 10 NOTIFICATION FRAMEWORK

The TI Plus application provides transaction and system status information using a notification framework.
Information currently available for notification is:
Transaction event step status change (event-status)
Async framework Job status change (async-job)
Async framework Step status change (async-step)
These notifications are transactional in nature, so if status changes are rolled back, these notifications are
also rolled back.
NOTIFICATIONS
Notifications once generated are handled by a message driven bean and can be published as
Notifications.All service request messages.
Since notifications are informational in nature, it is possible to publish them using a JMS topic, rather than
queue see later section on service access.
Configuration
Property
Description
service.access.notification.async.job.status
Enable notification of async framework job

status changes
service.access.notification.async.step.status
Enable notification of async framework step

status changes
service.access.notification.event.step.status
Enable notification of transaction event step

status changes
A JMS queue is required to trigger transaction-based notifications. So where a transaction is rolled back, the
notifications will be as well.
The queue must be configured so that a number of delivery attempts are made. If those are exceeded, it
must be configured to use the dead message queue defined as part of the async framework.
The JNDI name for the queue is:
queue/NotificationQueue
The JMS queue connection factory is the same as the async framework:
25
TI Plus
CHAPTER 11 SERVICE ACCESS

The TI Plus application provides a set of services as well as interacting with a set of external services. There
are some alternate methods of allowing this access.
APIStubs a test-only facility to allow familiarisation with setting up message formats for service
access
EJB A stateless session bean made available for remote access for using services provided by TI
Plus
Plain JMS incoming and outgoing service access using XML messages via JMS where responses
are not required
Pseudo-Synchronous JMS incoming and outgoing service access using XML messages via JMS
with the ability to set a reply queue
JMS Equation interface a pre-configured set of queues and resources for interfacing to one or
more Equation units
JMS TPI a pre-configured set of queues and resources for interfacing to one or more instances of
the Misys Trade Portal Interface
JMS Watch List Checker - a pre-configured set of queues and resources for interfacing to one or
more instances of a Watch List Checker system such as Misys Trade Watch
For more information see the TI Plus Interface Services Guide.
APISTUBS
This is a test facility that allows the familiarisation of sending messages into TI Plus and providing
responses to messages originating from TI Plus.
With this enabled, three tables are created in the zone database APISERVER, APICLIENT and
APIRESPONSE.
The APISERVER table is checked for periodically to see if there are any messages to be sent into TI Plus.
Once processed, the item is updated with the response received.
Whenever a service request is made from TI Plus, the request message is stored in the APICLIENT table,
and the details of the request are used to match an entry in the APIRESPONSE table in order to send back a
targeted service response.
A client data entry utility is available in the /sdk/tools/apistubs distribution folder. For more details
refer to the TI Plus SDK Systems Interfacing Guide.
Configuration
Property
Description
service.access.apistubs
Uncomment this property to enable the apistubs utility
...apistubs.db.url
The JDBC URL of the database driver
...apistubs.db.user
User id
...apistubs.db.password
Plain text password for the user (this is not expected to be configured in the
production environment)
...apistubs.db.schema
The name of the schema where the apistubs tables will be created
Note: Note that service.access. has been omitted to improve readability
26
TI Plus
EJB
A stateless session bean called EnigmaServiceAccess is available to be called to pass an XML message
as a parameter, and receive the response on return.
The EJB is supplied in the com.misys.tiplus2.service.access-ejb.jar file, which can be used as
the remote client jar file as well. Note that this file does not contain stubs and ties for the EJB as these are
application server specific. Please generate these using the utilities appropriate to the application server you
are using.
Configuration
Property
Description
service.access.ejb
Uncomment this property to enable the EJB remote access facility. Note that
if this is not set, the EJB is not included in the assembly
PLAIN JMS
Plain JMS service access allows both incoming and outgoing service requests. This service access must
only be used where a response to the service request is not required.
Incoming and outgoing queue names are derived from queue name prefixes defined in the configuration. For
each incoming queue, the JNDI name of queue/<prefix>Incoming will be used. For each outgoing
queue, the JNDI name of queue/<prefix>Outgoing will be used. For each unique queue name prefix,
the JNDI name of jms/<prefix>QueueConnectionFactory will be used for the respective queue
connection factory.
For outgoing service requests, it is unlikely that all outgoing requests will be handled by the same interface.
So it is possible to list the service operation identifiers whose service requests are to be sent to the
corresponding queue.
As part of the global processing facilities, it is possible to interact with multiple external systems that provide
the same role for different parts of the branch hierarchy defined in the zone. For instance, there may be
multiple main banking entities, each of which will require interfacing to its own general ledger system.
Service request messages identify the target system as part of their request header which is available to
the middleware to enable routing the request to the correct system.
However if you simply want to assign a particular queue to a particular system, then prefix the service
operation identifiers with the name of the external system defined in TI Plus.
Configuration
Property
Description
service.access.jms
Uncomment this property to enable any JMS service access
service.access.jms.plain
Uncomment this property to enable plain JMS service access
...plain.server.queues
This property is a comma-separated list of queue prefix names that will be

used to accept messages from
...plain.client.queues
This property is a comma-separated list of queue prefix names that will be

used to send messages to
...plain.client.services
This property defines which service operations use which queue prefix when
sending service requests (see below)
...plain.client.xa
Set this property to yes to enable XA processing when writing messages to

queues
Note: Note that service.access.jms has been omitted to improve readability.
27
TI Plus
The format of the service.access.jms.plain.client.services property is as follows:

<prefix1>=<service.operation>;<prefix2>=<service.operation>,<...
It may look strange having multiple = signs on the same line, however this is the way the property will be
broken down. If a particular prefix will interact with a particular external system, then an entry may be:
<prefix1>=<system.service.operation>,<system.service.operation>
So, if I have a client queue prefix called europe and it is to send the batch of postings and deals generated
by a transaction to an external system called BOGeneralLedger1, then the format of the client services
property for this would be
europe=BOGeneralLedger1.BackOffice.Batch
For each server queue prefix name the following JNDI resource is expected
queue/<prefix>Incoming
For each client queue prefix name, the following JNDI resource is expected
queue/<prefix>Outgoing
For each queue prefix the following JNDI resource is expected
jms/<prefix>QueueConnectionFactory
PSEUDO-SYNCHRONOUS JMS
Pseudo-synchronous JMS service access is similar to plain JMS access, except that messages sent can
wait for responses. Similarly if messages received contain a reply to queue, then the response is sent to that
queue.
When a message is sent, a reference to a reply queue and a correlation id is placed in the JMS header of
the JMS message. The interface then reads from the reply queue for messages that contain the correlation
id. The read from the reply queue is performed for a configured time period, and if the response is not picked
up, a response will be returned with a status of UNAVAILABLE.
It is the responsibility of the receiving interface to send the reply to the specified queue with the correlation
id. Also, the message should have a time to live attribute set to the same value as the timeout. This means it
will be removed from the queue automatically, and so there will not be a build-up of slow response
messages on the reply queue.
It is also possible to define a simple transformation of request and response messages. See the Interface
Services Guide for more details.
As for plain JMS, incoming and outgoing queue names are derived from queue name prefixes defined in the
configuration. For each incoming queue, the JNDI name of queue/<prefix>Incoming will be used. For
each outgoing queue, the JNDI name of queue/<prefix>Outgoing will be used. The JNDI name for the
reply queue queue/<prefix>OutgoingReply For each unique queue name prefix, the JNDI name of
jms/<prefix>QueueConnectionFactory will be used for the respective queue connection factory.
For purely outgoing messages that dont require responses, it is possible to publish them via topics.
The cross reference of service operations to queue prefix names works in the same way as for plain JMS.
Configuration
Property
Description
service.access.jms
service.access.jms.sync
Uncomment this property to enable pseudo-synchronous JMS

service access
...sync.server.queues
This property is a comma-separated list of queue prefix names

that will be used to accept messages from
...sync.server.transform

that have configured transformation plugins
...sync.server.timetolive
This property is a time in milliseconds to set the time to live

attribute for the response message
...sync.send.client.queues

that will be used to send messages to without any required
28
TI Plus
Property
Description
response
...sync.send.client.topics
This property is a comma-separated list of topic prefix names

that will be used to publish messages without any required
response
...sync.send.client.transform

...sync.sendrecv.client.queues

that will be used to send messages to, and wait for their
response on the reply queue
...sync.sendrecv.client.transform

...sync.sendrecv.timeout
This property is the time in milliseconds that the response will

be waited for
...sync.client.services
This property defines which service operations use which queue

prefix when sending service requests (see plain JMS
configuration)
...sync.xa
Set this property to yes to enable XA processing when writing

messages to queues

For each server prefix name the following JNDI resource is expected
queue/<prefix>Incoming
For each client topic prefix name, the following JNDI resource is expected
topic/<prefix>Outgoing
For each client queue prefix name, the following JNDI resource is expected
queue/<prefix>Outgoing
For each client queue prefix for send/receive, the following JNDI resource is expected
queue/<prefix>OutgoingReply
For each prefix the following JNDI resource is expected
jms/<prefix>QueueConnectionFactory
JMS EQUATION INTERFACE

The Equation interface is implemented as a Meridian 4.3 repository. The repository is designed to cope with
a single TI Plus zone linking to multiple Equation units. For more information on this, see the Equation
Interface Installation Guide.
The interface consists of requests from users (e.g. account balance requests) as well as the transfer of
postings and deals. By default these are assumed to be sent to different queues, and so can be processed
independently. However if the JNDI names are actually mapped to the same physical queue, then a users
enquiry request may be slowed down by a set of postings being transferred. This can be helped by
specifying different priorities for the enquiry messages vs. the transfer messages.
In this configuration, it is assumed that the Misys Message Manager is being used to handle SWIFT
messages, though this can be overridden, and those SWIFT messages handled by an alternate process.
Configuration
Property
Description
service.access.jms
service.access.jms.eqi
Uncomment this property to enable the interface
...eqi.enquire.priority
JMS priority for all enquiry-based messages

29
TI Plus
Property
Description
...eqi.enquire.timeout
Time to wait for a response for an enquiry message
...eqi.transfer.priority
JMS priority for all transfer-based messages
...eqi.transfer.timeout
Time to wait for all transfer-based messages
...eqi.swift
If an alternate SWIFT process is required, set to N default is Y

The JNDI resources generated for the Equation interface are:
JNDI name
Target queue
queue/eqEnquireOutgoing
TIPLUS2.BO.ENQUIRY
queue/eqEnqureOutgoingReply
TIPLUS2.BO.REPLY
queue/eqTransferOutgoing
TIPLUS2.BO.TRANSFER
queue/eqTransferOutgoingReply
TIPLUS2.BO.REPLY
queue/eqSwiftOutgoing
TIPLUS2.BO.TRANSFER
queue/eqIncoming
TIPLUS2.BO.REPLICATION
jms/eqEnquireQueueConnectionFactory
jms/eqTransferQueueConnectionFactory
jms/eqQueueConnectionFactory
JMS TRADE PORTAL INTERFACE

The Trade Portal Interface is implemented as a Meridian 3.5.x repository. The repository is designed to route
messages to and from a single instance of Misys Trade Portal.
Transaction details are sent through the Trade Portal Interface for a customer if they have a corporate
access system assigned to them. It is possible to have multiple corporate access systems defined though
a customer can only be served by one of them.
If multiple corporate access systems are defined, whether they are all instances of MTP, or at least one of
them is, then this must be taken into account in the configuration.
Configuration
Property
Description
service.access.jms
service.access.jms.tpi
...tpi.xa
Set to yes to enable the use of XA when writing messages to the queue
...tpi.systems
This property must be set if there are more than one corporate access
systems defined. For those systems that correspond to instances of MTP, then
this property must contain a comma separated list of their identifiers
...tpi.client.services
By default the GATEWAY.DOCS service operation is mapped which will cause

all gateway documents to be sent to MTP and this property will not need to
be set. If gateway documents are used for other purposes, then it may be
easier to restrict the list of documents explicitly. This property is a comma
separated list of service operations to be sent through TPI in the form
GATEWAY.<document>.

30
TI Plus
The JNDI resources generated for the trade portal interface are:
queue/meridian<system>Outgoing
queue/meridian<system>Incoming
jms/meridian<system>QueueConnectionFactory
WATCH LIST CHECKER INTERFACE

As part of TI Plus transaction event workflow, it is possible to perform a watch list check. This is implemented
by sending a message to a configured Watch List Checker product, and once the response is received,
either automatically proceed on success, or require user intervention on failure.
A configuration has been supplied that has been tested to work with TradeWatch.
Configuration
In the tiplus2.configuration.properties file, the following properties can be:
Property
Description
service.access.jms
service.access.jms.wlc
...wlc.xa
Set to yes to enable the use of XA when writing messages to the queue
...wlc.systems
This property must be set if there are more than one watch-list check
systems defined. For those systems that correspond to instances of watchlist checker systems, then this property must contain a comma separated
list of their identifiers
...wlc.client.services
By default the GATEWAY.DOCS service operation is mapped which will cause

all gateway documents to be sent to the watch list checker and this
property will not need to be set. It is preferable to nominate those
messages that are required. The
master.tiplus2.configuration.properties file supplied lists those
that are provided in the default configuration

The JNDI resources generated for the watch list checker interface are:
jms/wlc<system>Outgoing
jms/wlc<system>Incoming
jms/wlc<system>QueueConnectionFactory
USER IDENTIFICATION
When the TI Plus software needs to use an external service, it will adopt a nominated user id representing
TI Plus in the system being accessed. The expectation is that TI Plus is controlling when it is appropriate for
the TI user to access the external service, and so it will not be necessary to restrict the service use based on
the individual TI users.
Configuration
In the tiplus2.configuration.properties file, the following property can be set:
Property
Description
DefaultServiceUser
For outgoing service requests, this user id is used to represent service access
from TI Plus
31
TI Plus
BULK MESSAGE HANDLING INCOMING

If a bulk message is received by TI Plus, and a reply is not required, or is received by a pseudo-synchronous
JMS transport server, then the message will be processed to the async framework. Each individual message
will be processed separately in parallel, and once all have been processed, a response is returned if
required.
It is possible to override this process, so the individual messages are processed sequentially.
Configuration
Property
Description
override.no.split.bulk.message
If specified, bulk message content will be processed sequentially.
BULK MESSAGE HANDLING OUTGOING

TI Plus sends bulk messages to back office systems consisting of, for instance, postings, exposures and FX
deals. Where the interface for those systems are not able to handle these batches, the items within a batch
can be sent individually. When this facility is enabled, each message is processed in turn once the preceding
one is finished.
Configuration
Property
Description
service.access.split.batch
This is a list of External system identifiers that require the

BackOffice.Batch message to be split into its individual messages.
32
TI Plus
CHAPTER 12 CROSS ZONE DASHBOARD

In the tiplus2 application, the cross-zone dashboard aggregates information from multiple zones. The central
component to this is the cross-zone rebroadcaster which is part of the global application.
This should only be considered if multiple zones are to be deployed.
CROSS-ZONE REBROADCASTER
Global Server
Global application deployment
Rebroadcaster
c
Incoming
d1
TI1Broadcast
h1
h2
BroadcastReply
d2
TI2Broadcast
i
b
OutgoingReply
Outgoing
e1
g1
Incoming
f1
g2
e2
Incoming
Outgoing
OutgoingReply
f2
Zone 1 Access
Zone 2 Access
TI1 tiplus2 application deployment
TI1 Server
TI2 Server
The sequence of requests are as follows:

a. From the cross zone-dashboard, a message is sent to the TI1 outgoing queue
b. The outgoing queue maps to the incoming queue of the cross-zone rebroadcaster
c. The rebroadcaster reads the message
d. (1+2) the message is duplicated and sent to each zone via a deployment-based queue
e. (1+2) the broadcast queues are mapped to incoming queues of the particular deployments
f. (1+2) each deployment reads from its incoming queue and passes the message to the zone-based
application code
g. (1+2) the responses are placed on the same reply queue
h. (1+2) the messages are read and merged
i. The merged response is sent to the originators reply queue
j. The reply is read and the cross-zone enquiry is populated with the results.
Note that in the diagram, the queues that are made up of dashed lines may not actually exist as queues,
they may simply map to their targets.
Two types of request are currently supported:
relay request and aggregate response
split request and aggregate response
The difference between them is the first will send the same request to all zones the user is authorised to that
are online, whereas the second contains a set of zone-based requests that are split into zone-specific
requests. This may be a subset of zones that the user is authorised to.
33
TI Plus
As responses are received, the data is aggregated using the original sort sequence requested. Each zone
request is limited to return a maximum number of rows. This limit will also be applied to the aggregated
response.
The use of this facility relies on the pseudo-synchronous JMS facility.
Configuration
Property
Description
use.cross.zone.dashboard
This property must be set to include the cross-zone rebroadcaster

component
cross.zone.dashboard.useXA
Set to yes if XA is required (Note this must always be set to no for

WebLogic)
cross.zone.dashboard.timeout
Set this to the amount of time (in milliseconds) the rebroadcaster

will wait for responses from individual zones default is 15000
The rebroadcaster expects the following JNDI resources to be defined:

queue/rebroadcasterIncoming
queue/rebroadcasterOutgoingResponse
Also, for each tiplus2 deployment, there will also be:
queue/<deploymentId>BroadcastIncoming
In each of the tiplus2.configuration.properties files, the following properties are set:
service.access.jms=yes
service.access.jms.sync=yes
service.access.jms.sync.server.queues=enquiry
service.access.jms.sync.sendrecv.client.queues=enquiry
service.access.jms.sync.client.services=enquiry=Broadcast.Dashboard,Broadc
ast.ReallocateTransactions
The values can add to any already defined for other purposes. For further information see the section on
Pseudo-Synchronous JMS Service Access.
The following JNDI resources then need to be defined for each tiplus2 deployment:
queue/enquiryIncoming
queue/enquiryOutgoing
queue/enquiryOutgoingReply
jms/enquiryQueueConnectionFactory
34
TI Plus
CHAPTER 13 MISCELLANEOUS
UI CUSTOMISATION
The tiplus2 application user interface can be customised to allow literals to be translated, and screen
controls to be suppressed where not used. These facilities are defined by XML files.
With the workflow orchestration features of the application, it is possible to introduce new Log steps. Since it
may be preferable to show different sets of fields for different log steps, it is now possible for a Log step to
allow all fields to be entered equivalent to an Input step.
To provide Log step pages similar to what was available previously, a set of XML files are included. These
files will be used during application assembly by default. They are located in the
/software/components/modules/ui/conf/log folder.
When configuring the system to use these features, it is necessary to be able to see the effects of
translation, or control suppression quickly. So, for each facility, it is possible to specify the XML file (or folder
in the case of UI control files) and a reload period. This allows the files to be updated and reloaded every so
often. The minimum period is 15 seconds.
Once they are defined, these files can be placed in the appropriate folders:
/software/components/modules/ui/conf/literals
/software/components/modules/ui/conf/fragments
and they will be included in the tiplus2 deployment.
Property
Description
ui.customisation
This property needs to be uncommented to enable the UI

customisation facility
...show.page.context
Set to true to show the page context information in the web

browser status bar default is false
...literals.file
Location of the literals XML file when complete this will be the
name of the file with classpath: as a prefix this will be
copied from the
/software/components/modules/ui/conf/literals
folder
...literals.reload
Period in milliseconds before the file will be re-loaded. If the file

is on the classpath, then this should be 0. Note that a minimum of
15000 will be applied if a lower figure is specified
...fragments.exclude.log.steps
Exclude the pre-delivered log step configuration files
...fragments.merge
Merge the files in from the

/software/components/modules/ui/conf/fragments
folder as well as the delivered files in the
/software/components/modules/ui/conf/log
folder. The delivered files will not be included if the
ui.customisation.fragments.exclude.log.steps
configuration option is defined
...fragments.file
Location of the GUI fragments XML file this can be a folder or a

file. This is only used if the
ui.customisation.fragments.merge parameter is not
specified.
...fragments.reload
Period in milliseconds before the file will be re-loaded. If the file

is on the classpath, then this should be 0. Note that a minimum of
15000 will be applied if a lower figure is specified
35
TI Plus
Note:
1. Note that ui.customisation has been omitted to improve readability.
2. Also, if the fragments location is set to a folder during fragments configuration, the log step files will not
be included, and must be copied to the folder if they are required.
3. If a folder is being monitored, then it must contain at least one file, and not become empty while the
application is running, as the monitoring will cease.
DOCUMENT WINDOW RECORDING

To enable TI Plus to keep track of document windows that have been opened in the context of a transaction,
so that they can all be closed once the master summery page is exited from.
For documents that are not handled by a browser plugin, and empty window/tab may be opened and an
application launched to handle the document type. When the browser window is closed, the application that
was launched will not be closed as it is not controlled by the browser.
Property
Description
override.document.window.recording
If set to true, then document windows opened during transaction

processing will be recorded, and the windows closed when the user
exits from the relevant Master Summary screen.
It is also possible to override how the javascript functions that control how the windows are opened and
closed. For more information refer to the TI Plus SDK Application Extension Guide.
AMOUNT IN WORDS
The TI Plus software has the facility to edit a monetary amount as words. The algorithm used has some
options that can be varied:
Add the minor currency unit description to the end
Add a phrase to the end of the amount if it is a whole number of major currency units
Define a phrase that will prefix the amount if it is negative
Use fractions rather than words for minor currency units

Property
Description
override.sayas.minor.units.description
Add the minor currency unit description (such as 'cents')

to the output - default is true
override.sayas.whole.number.suffix
Specifies the phrase to use if the amount is a whole

number of major currency units (e.g. 'Only' for Three
Pounds Sterling Only)
override.sayas.negative.amount.prefix
Specifies what to put in front of an amount if it is

negative default is Minus
override.sayas.use.fractions
Rather than use words for minor currency units, output

them as fractions of major currency units - default is
false
36
TI Plus
PDF DOCUMENT WATERMARKS

During input and review stages of customer document production, the PDFs generated may have a
watermark added to them to show that they are for review only. For further details on this see the System
Tailoring Guide. The colour, font size and rotation angle can be specified for the watermark.
Property
Description
override.watermark.colour
Colour of the text used for the watermark default #C0C0C0
override.watermark.font.name
Font to use for the watermark text default Helvetica
override.watermark.font.size
Size of font for watermark text default 60
override.watermark.rotation
Degree of rotation of watermark text default 320
DEPLOYING HELP TEXT

The help text itself is delivered as a set of static web resources that can be served by an http server alone.
Since it is likely that multiple instances of the same software will be deployed (for instance a test version,
training version and production version), it is easier to deploy the help text only once, and allow the multiple
systems to reference the same help text.
The help text is delivered as a zip file in the /ti/help_text folder. Simply unzip the contents to a folder
served by the http server. The URL this folder corresponds to must end with an uppercase version of the
relevant locale. The default of this is EN_GB. If the http server the help text is deployed to is only used for this
purpose, then a page is supplied which can be used as the response to a page not found error condition
called. It is called PageNotFound.htm.
Property
Description
HelpTextURL
The URL of help text folder that is the parent of the locale folder
ERROR DISPLAY
When an unexpected error is encountered, the Error page shows as much information as it can. This is
useful during acceptance testing to quickly diagnose the issue. However in a production environment it may
be preferable to suppress the diagnostic information on the page (though it will still be logged).
The following property may be set in the global.configuration.properties file:
Property
Description
ShowSummaryErrorDetails
Set this property to true if only a summary of details are required

to be shown when an exception is encountered default false
LOCAL MODULE
In the /components/modules folder, there is a /local folder reserved for local overrides to the assembly
process. Sample build-global.xml and build-tiplus2.xml scripts are supplied that illustrates some
of the facilities available. These include:
Copying classpath configuration files
Including extra jar files
Include extra web resources
Overriding a spring definition
It is also possible to include an EJB jar file in the application see the build-tiplus2.xml script in the
/ejb-service-access module as an example.
For more information see the Interface Services Guide
37
TI Plus
Set the following property in the tiplus2.configuration.properties file:

Property
Description
local.overrides
Uncomment this property so that components included in the

/local folder will form part of the assembly
FILE SYSTEM RESOURCES

The following file system resources need to be set up on the application server that hosts the zone
application. The folder names used are based on the default definition in the master configuration file.
The folders are relative to the C: drive on a Windows file system.
Create the CSV import and export folders /tiplus2/csv/import and /tiplus2/csv/export
Create the translations folder /tiplus2/translations
Report Resource Folder

Reports that are configured to produce a file will output them relative to the configured property:
resource.file.handler.outputdir.uri
If not specified, then the value of csv.export.dir will be used instead.
The file name declared on a report can reference subfolders of this folder, however, the first character must
not be a folder separator. So if a report was to be produced and written to a file in the subfolder
outstanding, then the file name on the report profile would be:
outstanding/report-name
Note that the file extension corresponding to the format of the report will be added automatically.
If your application server is clustered, then this location will need to be in a shared area.
A temporary folder is also used, and will default to the report resource folder. However, if the application is
clustered, it is better to configure this folder to be a local folder that is available on each node in the cluster,
rather than a shared area.
The name of the file can have the time appended to it if required. This is achieved by setting the
configuration parameter:
resource.file.handler.append.time=true
Rich Text Formatting for Editable Document Fields

Editable document fields can now be entered in a rich text formatted. By default this facility is disabled.
Adding the property
override.enable.rich.text=true
will enable it.
Since editing fields using a rich text formatter may take longer to prepare than a typical server request, the
browser will communicate with the server every so often to ensure that the user's session is not closed and
so the editing lost. This communication process is controlled by two configuration parameters that can be
overridden:
Property
Description
override.max.keep.alives
Maximum number of times the browser will communicate with the

server while a field is being edited (default 10)
override.keep.alive.interval
Time in seconds between server communications (default 60)
With the default settings, the browser will keep the user's session alive for 10 minutes before their session
timeout will re-activate. So if the session timeout is set to 20 minutes, it will be effectively extended to 30
minutes while editing document fields with these settings.
38
TI Plus
Enabling Document E-Mail Support

By default, the e-mail document production handler is not enabled. The supplied handler directly connects to
an SMTP server and constructs an email with the relevant documents as attachments, and sends it to the email addresses that are resolved by the content of the #EMAIL clause.
Note: For further information about special clauses (#FAX, #EMAIL and #MAIL) see Designing Customer
Documents.
The content of the #EMAIL clause is examined and the following data is extracted if the relevant keywords
are detected at the start of a line:
Keyword
Description
FROM:
Originating e-mail address(es) if multiple addresses declared, they

must be separated by a ;
TO:
Receiving e-mail address(es)
CC:
E-mail address(es) to send a copy to
BCC:
E-mail address(es) to send a blind copy to
SUBJECT:
Becomes the e-mail subject line
TEXT:/HTML:
Body of e-mail message either in text format or html format
For example, the clause text could be:

FROM:<<USER,u,y>>
TO:<<CADR,p,y>>
SUBJECT:Product - <<PLN,s,%>> - Ref: <<MST,r,%>>
TEXT:Dear Sir/Madam,
We are pleased to attach details regarding the following <<PLN,s,%>>
Regards
TF Dept
<<BOB,b,1>>
During testing, the TO: field should be set to a hard-wired e-mail address so test documents are not
inadvertently sent to a customer. Alternatively make sure that the SMTP server used is not able to forward emails outside of the banks network.
To enable the handler add the following property to the tiplus2.configuration.properties file:
Property
Description
override.use.email
Enable the provided email handler (set to yes)
In the application server administration console, configure a mail session resource with a JNDI name of
mail/zone. Only details for outgoing mail needs to be configured.
FTP Attempts
Where a resource is to be transferred via FTP, it is possible to specify the number of attempts that are to be
made before the transfer is considered a failure. Set the property resource.ftp.handler.attempts to
the number required. The default value is 3.
39
TI Plus
Using CMS
CMS by default will only accommodate attachments of 1MB for DB2 and 10MB for Oracle. It is up to the
users to change this by applying the alter command below.
For DB2
ALTER TABLE CMS_ITEM ALTER COLUMN ITEM set data type blob(XXX)
For Oracle
ALTER TABLE CMS_ITEM MODIFY BLOB (ITEM) (STORAGE (NEXT XXX))
Where XXX is the size you want e.g. 10M for 10 MB, 1G for 1 GB
40
TI Plus
CHAPTER 14 APPLICATION SERVER SPECIFIC

This chapter covers any configuration option available that is specific to a particular application server for a
particular reason.
WEBLOGIC - CONFIGURING SESSION COOKIE DOMAINS

For WebLogic, there is no easy way to define what domain and URL a session cookie is restricted to through
the administration console. It can be specified in the WebLogic-specific deployment descriptor for each web
module.
Add a property to the global.configuration.properties and
tiplus2.configuration.properties file for each web module identified by its context URL as
follows:
override.weblogic.domain.<context url>=<domain name>
Where <context url> is the value specified by either GlobalAppContext or TIPlus2AppContext,
and the <domain name> is the domain of the URL used to access the application.
For example for the global application, if the default context URL is used, and the domain name is
test.domain, then the property would be specified as:
override.weblogic.domain.tiplus2-global=test.domain
JBOSS - INTEGRATING OTHER JMS PROVIDERS

Different JMS providers may integrate with JBoss in different ways to allow them to be used to drive
message driven bean processing. To facilitate this, there are a few properties that can be set in the
tiplus2.configuration.properties file to affect the jboss.xml deployment descriptor for the
associated message driven bean these properties apply to a specific message driven bean whose name
needs to be included in the property.
Property
Description
Invoker binding
To be able to specify an explicit invoker-binding name, then the property

jboss.<MDB name>.invoker.binding.name=<name>
may be specified
Resource adapter
To reference a particular resource adapter

jboss.<MDB name>.resource.adapter.name
may be specified
Activation config properties
By default, the deployment descriptors will have both a destination

activation property and a destination-jndi-name element. To add extra
activation config properties
jboss.<MDB name>.activation.config.<name>=<value>
may be specified.
Note that if you supply an explicit destination activation config property, then
this will suppress the destination-jndi-name element in the jboss.xml
file.
See later section detailing how to configure JBoss to use WebSphere MQ.
41
TI Plus
WEBSPHERE USE ACTIVATION SPECIFICATION

When a foreign JMS server is used to provide queues for a particular interface the default handling of
these interfaces for incoming messages is to use a listener port in WebSphere to bind to the relevant
message driven bean. If you have configured your foreign JMS server through a Bus, then an activation
specification will be used instead.
For each queue this is required for, add the following property to the
tiplus2.configuration.properties file:
override.<queue>.use.websphere.activation=Y
Where <queue> is the full queue name converted to lower case. So, for instance, for meridianIncoming,
this would be:
override.meridianincoming.use.websphere.activation=Y
42
TI Plus
CHAPTER 15 OPERATING SYSTEM SPECIFIC

This chapter details areas that are operating system specific.
FONTS FOR AIX AND LINUX

Fonts for documents are provided in the /software/components/modules/fonts folder. If you are
running on an AIX or Linux system, there may not be any fonts compatible with the reports provided. This
can be addressed as follows.
The actual font files are located in the subfolder /resources/fonts. This folder also contains a file
(fonts.scale) that lists those fonts in a format recognised by the java runtime.
To allow Crystal Reports to use these fonts, they must be installed in the relevant folder in the java runtime.
For WebSphere, this folder is:
.../WebSphere/AppServer/java/jre/lib/fonts
otherwise it is in:
/usr/java/jdk1.6.x/jre/lib/fonts
To do this, the following steps need to be taken:
Create a backup of the fonts folder. By default this folder will contain a set of Lucida-based fonts.
Copy the fonts provided into this folder
Update the fonts.dir file located in this folder as follows:
The first line of this file declares the number of lines following it.
This must be increased by the number of lines declared on the first line of the fonts.scale file
already located in the folder
So if the first line of fonts.dir is 80, this must be increased by the equivalent number on the first
line of the fonts.scale file - currently 509 - so in this example it would become 589. The rest of
the fonts.scale file after the first line then needs to be copied to the end of the fonts.dir file.
Save the file.
Note this file must be saved in a unix format - so the merge should be performed in a text editor on
the target machine.
Restart the application server.
Repeat for each machine where an application server instance is used.

Any reports run will now pick up these fonts.
GRAPHICS SUPPORT FOR UNIX WITHOUT X-WINDOWS

If the unix system you are using does not have an X-Windows component installed, then to support the
dynamic charts available on the cross-zone dashboard, the following must be added to the command line for
the application server:
-Djava.awt.headless=true
43
TI Plus
CHAPTER 16 WEBSPHERE SETUP

This chapter summarises what WebSphere setup is needed before the TI Plus software can be deployed
and started.
It is assumed that separate application server instances will be created for the global application and tiplus2
applications. Setting up clustering is not covered here, but the only difference to what is covered in this
chapter will only be requiring JNDI resources to be defined at a different scope.
All links referred to below are for the WebSphere Administration Console.
INITIAL CONFIGURATION
EJBDeploy (WebSphere 7 Only)
While the TI Plus software does not have many EJBs, there are quite a number of jar files, that may cause
the ejbdeploy tool to run out of memory when trying to install an instance of the tiplus2 application.
To remedy this, the memory setting for the tools can be increased by editing the following file:
<install>/WebSphere/AppServer/deploytool/itp/ejbdeploy.bat
Note if you are running on AIX, this would be ejbdeploy.sh.
In the file, look for the JAVA_CMD variable, and find the Xmx parameter for maximum heap size, and
increase it. The value of 512m will be enough.
JDBC CONFIGURATION
JDBC resources can be set up from the Resources->JDBC->JDBC Providers and Resources->JDBC->Data
sources links.
Only jdbc/global is required for the global application, whereas all jdbc resources are required for the
tiplus2 application deployment servers.
If you are using DB2, then for each datasource, select the Custom properties link, and set the
webSphereDefaultIsolationLevel to 2 (Read Commited).
JMS CONFIGURATION
The areas of the application that use JMS are:
Async and Notification Frameworks
Service Access
Cross-zone dashboard

A service bus is required to be set up to define the queues for the async and notification frameworks. If
multiple tiplus2 applications are to be deployed, then they could share the same bus instance, but it is not a
requirement.
Note: However if you are configuring for a split deployment, then the user access application and the async
framework application must share the bus.
Create a Bus from the Service integration->Buses link
Add the server to the bus using the Bus members link. Note it will be necessary to restart the server
before installing the TI Plus software to allow the bus member to start
44
TI Plus
Add the async framework queues to the bus using the Destinations link:
JOB.LIFECYCLE.QUEUE
JOB.EXECUTION.QUEUE
STEP.EXECUTION.QUEUE
NOTIFICATION.QUEUE
DEAD.MESSAGE.QUEUE
For the job lifecycle, job execution and notification queues, edit their definitions, and change the
Exception destination details. Specify the DEAD.MESSAGE.QUEUE as the target, and the Maximum
failed deliveries per message as 5.
Create the JMS resources for the server, starting with a queue connection factory using the
Resources->JMS->Queue connection factories link, selecting the bus name, and using the JNDI
name jms/QueueConnectionFactory
Create five Queues using the Resources->JMS->Queue link, specifying the appropriate JNDI name,
and selecting the relevant destination queue from the bus. The JNDI names are:
Create five Activation specifications to map the queues to the message driven beans that use them,
using the Resources->JMS->Activation specifications link. The JNDI names to use are
listener/<queue name>. Associate them with the respective queues
If a split deployment is configured, then the steps described correspond to the async framework server. For
the user access server, the only resources that need to be set up are the connection factory, and queue
resources for the job lifecycle, job execution and notification queues.
As far as other JMS resources are concerned, both the user access and async framework servers need to
be configured in the same way unless otherwise stated.
Service Access
JMS Service access is usually configured using an external JMS provider, such as WebSphere MQ. This
section describes how to configure MQ to be used with WebSphere. The example used to describe the
configuration is for the TPI interface whose JNDI resources are:
queue/meridianIncoming
queue/meridianOutgoing
jms/meridianQueueConnectionFactory
Note that is possible to link WebSphere MQ to a service bus. If this is the case, then follow similar steps to
the async framework, as the relevant queues will appear as bus-located resources. In this circumstance, you
can also use the WebSphere specific configuration option to use activation specifications, rather than listener
ports which are described below.
45
TI Plus
Configuring WebSphere MQ Connection Factory

In the navigation tree, click the link Resources->JMS->Queue connection factories and set the scope
appropriately.
Click New, select WebSphere MQ messaging provider as a provider then click OK.
Enter the following details and click Next.

Field
Value
Name
MeridianQCF
JNDI Name
Select Enter all the required information into this wizard and click Next.
Enter the Queue manager name and click Next.
Enter the following details and click Next.

Field
Value
Transport
Client
Hostname
<WebSphere MQ server name>
Port
<queue manager listener port>
Server connection channel
SYSTEM.DEF.SVRCONN
Test the connection and if successful, click Next.
Click the Finish button and then click on Save link.
Configuring Queues
In the navigation tree, click the link Resources->JMS-> Queues and set the appropriate scope.
Click New and select WebSphere MQ messaging provider as a provider then click OK.
Enter the following details.

Field
Value
Name
MeridianIncomingQ
JNDI Name
Queue name
TI.GWY.IN.<N>
Queue manager
<WebSphere MQ Queue Manager name>
Click the OK button and then click on the Save link.
Select the queue and click on WebSphere MQ connection properties. Enter the following and click
OK and then on the Save link
Field
Value
Queue manager host
<WebSphere MQ server name>
Queue manager port
<queue manager listener port>
Server connection channel name
SYSTEM.DEF.SVRCONN
Repeat the steps above for the outgoing queue with following details:
Field
Value
Name
MeridianOutgoingQ
JNDI Name
Queue name
TI.GWY.OUT.<N>
46
TI Plus
The remaining details are the same as the first queue
Configuring Listener Ports

In the navigation tree, click on the Servers>Server Types->WebSphere application servers link. Click on the
appropriate tiplus2 application server.
Click on the Communications->Messaging->Message listener service link
Click on the Listener Ports link.
Click on New and enter the following details:
Field
Value
Name
listener_meridianIncoming
Connection factory JNDI Name
Destination JNDI name
Click the OK button and then click on the Save link.
Cross-Zone Dashboard
For WebSphere, these queues are defined on a bus that has the global and each tiplus2 server as bus
members. If the same bus is used by the tiplus2 servers for the async framework queues, then simply add
the global server as a destination, otherwise create a new bus and add all servers as bus members.
Global Server
Rebroadcaster
Bus
Incoming
TI1Broadcast
REBROADCASTER.INCOMING
Outgoing
TI2Broadcast
REBROADCASTER.REPLY
TI1.ENQUIRY.INCOMING
TI1.ENQUIRY.REPLY
OutgoingReply
BroadcastReply
Incoming
Incoming
TI2.ENQUIRY.REPLY
Outgoing
OutgoingReply
Zone 1 Access
Zone 2 Access
TI1 Server
TI2 Server
The solid lines are JNDI mappings, whereas the dashed lines are references due to the queue being defined
as the reply-to attribute on an originating message in these cases no JNDI mapping is required.
The following steps assume you are creating a new bus, and that there are two zones - AMERICA
(deployment TI1) and EUROPE (deployment TI2).
Create a Bus called TIDashboard from the Service integration->Buses link
Add the global and tiplus2 servers to the bus using the Bus members link
Add the following queues using the Destinations link, referencing the relevant bus member as appropriate:
Queue name
Bus member
Global server
REBROADCASTER.REPLY
Global server
47
TI Plus
Queue name
Bus member
TI1 server
TI1.ENQUIRY.REPLY
TI1 server
TI2 server
TI2.ENQUIRY.REPLY
TI2 server
Create the following connection factories, queues and activation specifications from the Resources->JMS> links
For the global application server:
queue/rebroadcasterIncoming mapping to REBROADCASTER.INCOMING
listener/rebroadcasterIncoming activation specification referencing

queue/rebroadcasterOutgoingResponse mapping to REBROADCASTER.REPLY
queue/ti1BroadcastIncoming mapping to TI1.ENQUIRY.INCOMING
queue/ti2BroadcastIncoming mapping to TI2.ENQUIRY.INCOMING
For the TI1 deployment server:
queue/enquiryIncoming mapping to TI1.ENQUIRY.INCOMING
listener/enquiryIncoming activation specification referencing queue/enquiryIncoming
queue/enquiryOutgoing mapping to REBROADCASTER.INCOMING
queue/enquiryOutgoingReply mapping to TI1.ENQUIRY.REPLY
For the TI2 deployment server:
queue/enquiryIncoming mapping to TI2.ENQUIRY.INCOMING
listener/enquiryIncoming activation specification referencing queue/enquiryIncoming
queue/enquiryOutgoing mapping to REBROADCASTER.INCOMING
queue/enquiryOutgoingReply mapping to TI2.ENQUIRY.REPLY
When the EAR files are deployed, the message driven bean mapping for the Incoming queue will default to
a listener port being defined.
This needs to be overridden to use an activation specification as referred to in the previous chapter. Add the
following to the tiplus2.configuration.properties file:
override.enquiryincoming.use.websphere.activation=Y
APPLICATION SERVER PROCESS DEFINITION

This only applies to WebSphere 8.5.
For each of the application servers that have been defined, a command-line property must to be added:
-Dorg.apache.el.parser.SKIP_IDENTIFIER_CHECK=true
This is set in the Generic JVM arguments field on the page Application servers-><server>->Process
definition->Java Virtual Machine.
48
TI Plus
INSTALLING TI PLUS 2 SOFTWARE

Click on the Applications->Application Types->WebSphere enterprise applications link.
Click on Install.
Click on Browse, and locate the EAR file of the application you wish to deploy.
You should be able to click Next on all pages without changing anything, except for the Manage Modules
page where you target the server/cluster the application is to be deployed to. Make sure all components of
an application are referencing the same target. On the final summary page, click Finish.
The application will be deployed, and once finished, click on the Save link.
WebSphere 8.5 Configuration

After each application has been deployed, select the application from the Applications->Application Types>Websphere enterprise applications list in turn and set the following:
In Details Properties->Class Loading and update detection
Set Class loader order to be Classes loaded with local class loader first (parent last)
Set War class loader policy to be Single class loader for application
In Web Module Properties->JSP and JSF options
Set JSF Implementation to SunRI1.2
Once finished, click Save.
FINAL CONFIGURATION STEPS

Session Cookies
To segregate session cookies, click on the Applications->Application Types->Websphere enterprise
applications link and select the global application.
Click on the Session management link
Make sure Enable cookies is checked, and click its link
Enter the domain and path from the URL used to access the global application
Click OK and then click the Save link.
Repeat these steps for each tiplus2 application.
49
TI Plus
CHAPTER 17 WEBLOGIC SETUP

This chapter summarises the WebLogic setup required before the TI Plus software can be deployed and
started.
It is assumed that a user domain with separate application server instances will be created for the global
application and tiplus2 applications.
Links referred to below are for the WebLogic Administration Console.
Shared Libraries
Before installing the TI Plus software, two shared libraries must be installed
Click on the Deployments link from the left-hand menu
Click the Install button, and navigate to the

<weblogic>/wlserver_10.3/common/deployable-libraries folder. The libraries to install
are jsf-1.2.war and jstl-1.2.war.
Select to Install this deployment as a library option and target the servers the applications are going
to be installed to.
Locate the jar files glassfish.jstl_1.2.0.x.jar and javax.jsf_1.2.0.x.jar from the

<weblogic>/modules folder (where x is the highest value available) and copy them to the
<domain>/lib folder if you have set up a domain, or to each <server>/lib folder if you have set
up individual servers. It will be necessary to restart the servers affected.
JDBC CONFIGURATION
JDBC resources can be set up from the Services->JDBC->Data Sources link.
The jdbc/global datasource must target all servers, whereas the zone-based datasources need only
target the tiplus2 application servers.
If you are using Oracle as your DBMS, make sure on the Connection Pool tab under the Advanced link, the
check box for Remove Infected Connections Enabled is unchecked. If this is enabled, then connections will
be created and destroyed continually, negating the advantage the connection pool provides. The TI Plus
software access the Oracle connection directly in order to provide more robust CLOB/BLOB handling so
the connections are fine to be reused.
Do not set an XA transaction timeout on the JDBC resource let it default to the JTA timeout.
If you are using DB/2, make sure that the option Keep Connection After Local Transaction is not set.
Both of these settings can be found on the Transaction tab of the JDBC resource.
JMS CONFIGURATION
Service Access

For each tiplus2 application server:
Create a JMS server using the Services->Messaging->JMS Servers link. Target the server that the
tiplus2 application will be deployed to.
Create a new JMS module using the Services->Messaging->JMS Modules link.
50
TI Plus
Create a Subdeployment in the JMS module from the Subdeployments tab.
From the Configuration tab of the JMS Module, add the queues and connection factory linking them
to the subdeployment:
Note: Note that when creating the queue connection factory, make sure that the XA Connection Factory
Enabled field on the Transactions tab is checked.
If you are creating a split deployment, then these steps apply to the async server. The user access server
needs to reference the JMS server just defined as a Foreign Server. Only the connection factory and the job
lifecycle, job execution and notification queues need to be included in the foreign server definition.
Service Access
section describes how to configure MQ to be used with WebLogic. The example used to describe the
Setting up the Classpath

Copy the following jar files from the JMS server <install>/WebSphere MQ/Java/lib folder into the
<weblogic-domain>/lib folder:
com.ibm.mq.jar
com.ibm.mqjms.jar
com.ibm.mq.pcf-6.1.jar
connector.jar
dhbcore.jar
mqcontext.jar
Add a java property to the startup command line for each tiplus2 application server:
Click on the Environment->Servers link and select a relevant application server
Click on the Server Start tab
In the Arguments field add the following:

-Duser.name=<valid username on the MQSeries machine>
Note: The username is defined because the WebSphere MQ server will only grant access to a valid user
defined on the machine that the MQ Server is running.
51
TI Plus
Configure a Foreign JMS Server in WebLogic

Create a JMS Foreign Server as follows:
Click on the Services->Messaging->JMS Modules link. Click on the JMS module for the tiplus2
server
Click the New button, select the Foreign Server radio button, and then click the Next button. Give the
Foreign Server a name and click the Next button. Ensure that the targeting is set to the
subdeployment click the Finish button.
Click on the newly created resource, and enter the following value in the JNDI Initial Context Factory
textbox:
com.ibm.mq.jms.context.WMQInitialContextFactory
Then enter the following value into the JNDI Connection URL textbox:
<JMS-Server-hostname>:<queuemanager-port>/SYSTEM.DEF.SVRCONN
Click Save.
Create Destinations
In the JMS Foreign Server, select the Destinations tab, and for each queue
Click the New button to create a new Foreign Destination.
Give the destination a Name, a Local JNDI Name, and a Remote JNDI Name. Finally, Click OK.
The following queues should be defined.
Local JNDI name
Remote JNDI name
TI.GWY.IN.<N>
TI.GWY.OUT.<N>
Note: The Remote JNDI Name must match the name given to the queue created within the WebSphere MQ
Server.
Create Connection Factories
In the JMS Foreign Server, select the Connection Factories tab.
Click the New button to create a new Foreign Connection Factory.
Give the foreign connection factory a Name, a Local JNDI Name, and a Remote JNDI Name. Finally,
Click OK.
Field
Value
Local JNDI Name
Remote JNDI Name
TIMQMGR
Note: Ensure that the username and password fields on the Foreign Connection Factory are left blank as
this will cause problems.
52
TI Plus
The approach for the cross zone dashboard configuration for WebLogic is to have a single JMS server on
the global application server that hosts the queues, and the zone applications treat that JMS server as a
foreign server. The names of the resources referred to below are suggestions, however any JNDI name
specified must be used.
Global Server
Rebroadcaster
JMS Server
Incoming
TI1.ENQUIRY.REPLY
TI1Broadcast
OutgoingReply
TI2.ENQUIRY.REPLY
BroadcastReply
TI2Broadcast
Outgoing
OutgoingReply
Incoming
Incoming
IncomingResponse
IncomingResponse
Outgoing
Foreign JMS Server
Foreign JMS Server
Zone 1 Access
Zone 2 Access
TI1 Server
TI2 Server
The dotted lines for queues indicate they are placeholders for the actual queues that reside in the global
JMS server. The following steps assume that there are two zones - AMERICA (deployment TI1) and EUROPE
(deployment TI2).
For the global application:
Create a JMS server called GlobalJMSServer using the Services->Messaging->JMS Servers link.
Target the server the global application will be deployed to.
Create a new JMS module called GlobalModule using the Services->Messaging->JMS Modules
link
Add a Subdeployment to the GlobalModule using the Subdeployments tab, targeting the
GlobalJMSServer
From the Configuration tab in the GlobalModule, add the following queues and connection factory,
linking them to the subdeployment
Resource name
Type
JNDI name
QueueConnectionFactory
Connection
Factory
Queue
REBROADCASTER.REPLY
Queue
Queue
queue/ti1BroadcastIncoming
TI1.ENQUIRY.REPLY
Queue
queue/ti1BroadcastOutgoingResponse
Queue
TI2.ENQUIRY.REPLY
Queue
Note that the xxx.ENQUIRY.REPLY queues will not be accessed directly by the global application via these
JNDI names, however they will be used to link to the relevant zone JMS configuration.
53
TI Plus
For each of the AMERICA(TI1) and EUROPE(TI2) zones:
Create a new JMS module called TI1Module using the Services->Messaging->JMS Modules link
targeting the server that the AMERICA zone is to be accessed from
From the Configuration tab create a Foreign Server called GlobalForeignServer, setting the
JNDI Initial Context Factory to weblogic.jndi.WLInitialContextFactory and JNDI
Connection URL to t3://<global server>:<global http port>
On the Destinations tab, add the following:
Resource name
Local JNDI
Remote JNDI
Incoming
queue/
enquiryIncoming
queue/
ti1BroadcastIncoming
IncomingResponse
queue/
enquiryIncomingResponse
queue/
rebroadcasterOutgoingResponse
Outgoing
queue/
enquiryOutgoing
queue/
rebroadcasterIncoming
OutgoingReply
queue/
enquiryOutgoingReply
queue/
ti1BroadcastOutgoingResponse
On the Connection Factories tab, add the following:

Resource name
Local JNDI
Remote JNDI
ConnectionFactory
jms/
enquiryQueueConnectionFactory
jms/
QueueConnectionFactory
Repeat this configuration for the EUROPE zone.

Click on the Deployments link from the left-hand menu.
Click on Install.
Locate the EAR file of the application you wish to deploy and click Next.
Select Install this deployment as an application and click Next.
Check the appropriate server where the software will be installed to and click Next.
Click Finish.
The software will now be installed. If the target server is already running, then the software will be started
automatically, so it is advisable to make sure the server you are installing to has been stopped.
54
TI Plus
CHAPTER 18 JBOSS 5.1 SETUP

This chapter summarises the JBoss setup required before the TI Plus software can be deployed and started.
It is assumed that a separate server environment will be configured for global application and each tiplus2
application.
All configuration is expected to be performed via editing configuration files using a text editor.
JBoss has the following folder structure:
Folder
Content
/bin
Control scripts
/client
Jar files required to run a JEE client
/common/lib
Common jar files for all configurations
/docs
DTD and schema definitions as well as sample configuration files
/lib
Server jar files
/server
Folder containing individual server definitions
/server/all
Full configuration supporting clustering
/server/default
Default configuration
/server/xxx
Further configurations that are not appropriate for running TI Plus 2
To create an instance of an application server, then a server configuration folder must be used as a basis.
If clustering is required, start with /server/all, otherwise start with /server/default.
The name of the subfolder of /server will become the name of the server configuration for example
/server/global-server1 would represent an application server for running the global application.
Startup Scripts
To start an application server, create a script in the /bin folder called run-<config>.bat. (or run<config>.sh on Linux). The script should contain:
set RUN_CONF=C:\jboss\bin\run.<config>.conf.bat
run.bat -c <config> -b hostname
Where hostname is the host name of the machine.

This script references a configuration script to call - run.<config>.conf.bat. These are created by
copying run.conf.bat.
To make sure that each application server on the same host does not use the same ports as each other, the
debug port and service binding system property must be set uniquely. In the run.<config>.conf.bat
file, change the debug port (defaults to 8787) and add the following line near the bottom:
set JAVA_OPTS="%JAVA_OPTS% -Djboss.service.binding.set=ports-nn"
Where nn starts as 01. While the first configuration does not need to specify this each subsequent
configuration by specifying ports-nn has a set of port numbers offset by 100 x nn.
So, for instance the first configuration would use port 8080 for http. When specifying ports-01, this would
become 8180.
This script also contains the memory requirements for the application server, and so it must be set
accordingly.
If clustering support is required, make sure that all of the servers that are to be used in a cluster share the
same UPD IP number and that other application servers do not. This IP address is specified by setting the
jboss.partition.udpGroup property:
set JAVA_OPTS="%JAVA_OPTS% -Djboss.partition.udpGroup=228.11.11.12"
Those servers participating in the cluster must all specify the same IP address.
55
TI Plus
Default Datasource
A JBoss application server has a default data source that is used for identity tracking, and the default JMS
implementation. It is pre-configured using hsqldb. Use a database created specifically for JBoss using your
chosen DMBS. Update the /server/<config>/deploy/default-ds.xml to reference the database
you nominate. All of the relevant tables will be created on demand.
Examples of this file are in /jboss/docs/examples/jca based on the DBMS used.
Setting up SSL
Create the folder /common/conf and open a terminal at this location.
To create a certificate for each application server, execute the following command for each configuration:
keytool -genkey -alias <mykey> -keyalg RSA -validity 3650 -keystore
mykeys.keystore
setting the <mykey> value to one that represents the configuration.
Also create a trust store with the certificates, by first exporting them:
keytool -export -alias <mykey> -keystore mykeys.keystore -file <mykey>.cer
and then importing them:
keytool -import -alias <mykey> -file <mykey>.cer -keystore mykeys.truststore
You will be prompted for password and identity information. When asked for first and last name, enter the
host name of the url associated with the application server.
Update the configuration of the embedded tomcat server to reference the certificates as follows:
Open the server.xml file in the /server/<config>/deploy/jbossweb.sar folder
Uncomment the <Connector> definition for https
Set the keystoreFile and keystorePass attributes
Add a keyAlias attribute
The definition should look something like:

<Connector protocol="HTTP/1.1" SSLEnabled="true"
port="8443" address="${jboss.bind.address}"
scheme="https" secure="true" clientAuth="false"
keystoreFile="C:/jboss/common/conf/mykeys.keystore"
keystorePass="password" keyAlias="<mykey>" sslProtocol="TLS" />
Note that the keystoreFile attribute should reference the file using an absolute path.
Update the run.<config>.conf.bat file to reference the truststore by adding the following two lines near
the bottom:
set JAVA_OPTS="%JAVA_OPTS% -Djavax.net.ssl.trustStore=C:/jboss/common/conf/mykeys.truststore"
set JAVA_OPTS="%JAVA_OPTS% -Djavax.net.ssl.trustStorePassword=<password>"
Default JMS Provider

The default JMS provider uses a database to handle the message store. The tables to create for this facility
are DBMS-specific. The default hsqldb-based definition must be removed (hsqldb-persistenceservice.xml) and a DBMS-specific one replace it.
Sample files are available in /jboss/docs/examples/jms place the respective file in
/server/<config>/deploy/messaging folder.
JDBC CONFIGURATION
For each datasource a separate configuration XML file is required. Examples of the format of these files are
in the /jboss/docs/examples/jca folder based on the DBMS used. For example, the following
represents the definition of a DB2 global database:
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<xa-datasource>
<jndi-name>jdbc/global</jndi-name>
<xa-datasource-class>com.ibm.db2.jcc.DB2XADataSource</xa-datasource-class>
<xa-datasource-property name="ServerName">host</xa-datasource-property>
56
TI Plus
<xa-datasource-property name="DatabaseName">TIGLOBAL</xa-datasource-property>
<xa-datasource-property name="User">TRADEIN1</xa-datasource-property>
<xa-datasource-property name="Password">TRADEIN1</xa-datasource-property>
<xa-datasource-property name="DriverType">4</xa-datasource-property>
<xa-datasource-property name="currentLockTimeout">-1</xa-datasource-property>

<xa-datasource-property name="PortNumber">50000</xa-datasource-property>

<isSameRM-override-value>false</isSameRM-override-value>
<track-connection-by-tx/>
<transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
<max-pool-size>50</max-pool-size>

<metadata>
<type-mapping>DB2</type-mapping>
</metadata>
</xa-datasource>
</datasources>
It is worth applying a naming convention for each datasource definition. For instance:
tiplus2-global-db2-jcc-xa-ds.xml
JMS CONFIGURATION
Service Access

The async and notification frameworks will use the supplied default JMS provider. The global JNDI name of
the default queue connection factory is java:/JmsXA. This means that it is necessary to add the property:
jndi.jms.QueueConnectionFactory=java:/JmsXA
to the jndi.resource.locator.properties file.
To define the JobLifecycleQueue, JobExecutionQueue, StepExecutionQueue,
NotificationQueue and DeadMessageQueue resources, create a new file called tiplus2-asyncservice.xml to the /server/<zone-config>/deploy/messaging folder of the appropriate
application servers. For each queue add an <mbean> definition as shown in the following snippet
<server>
. . .
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=JobQueue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
</mbean>
. . .
</server>
For JobLifecycleQueue, JobExecutionQueue and NotificationQueue a delivery retry configuration

must be added to attempt delivery up to 5 times before re-directing the message to the
DeadMessageQueue. To specify this, add the following <attribute> elements to the queue definition:
<attribute name="DLQ">
jboss.messaging.destination:service=Queue,name=DeadMessageQueue</attribute>
<attribute name="MaxDeliveryAttempts">5</attribute>
If you are setting up a split deployment, then this definition corresponds to the async framework server.
For the user access server, then only the JobLifecycleQueue, JobExecutionQueue and
NotificationQueue definitions are required though the re-delivery configuration is not required for
these definitions.
57
TI Plus
To link these two queues to the async framework server, then a messaging bridge needs to be set up in the
user access server to push messages from the job lifecycle, job execution and notification queues to the
equivalent queues in the async framework server. This will require:
A foreign JNDI server definition
Messaging bridge definition
The details of this configuration are not shown here. Review the section on the cross-zone dashboard, and
base your configuration on that example. This scenario is simplified because there is only one-way traffic.
Service Access
section describes how to configure MQ to be used with JBoss. The example used to describe the
Install the WebSphere MQ resource adapter

The WebSphere MQ resource adapter libraries are packed in the wmq.jmsra.rar file. This is found in the
WebSphere MQ installation folder %MQ_JAVA_LIB_PATH%/jca.
Copy this file to the JBoss server folder where the tiplus2 application is deployed
%JBOSS_HOME%/server/<tiplus2-server>/deploy.
Note that the resource adapter is available only for WebSphere MQ version 6.0.2.1 or higher.
Update the JBoss JCA
The JBoss EAP 5.0.1 released a patch for the JCA jars. This can be downloaded from the site
https://issues.jboss.org/browse/JBPAPP-7203. These contain fixes for the unsupported
activation properties in the WebSphere MQ resource adapter.
Download, copy and replace the jboss-jca.jar located in the %JBOSS_HOME%/common/lib folder
Download, copy and replace the jboss-jca-deployer.jar in the
%JBOSS_HOME%/server/<tiplus2-server>/deployers/jboss-jca.deployer folder.
Install the WebSphere MQ Extended Transaction Client
XA support for the WebSphere MQ resource adapter requires the deployment of the Extended Transaction
Client. This is sold as a separate package and there are license costs associated with distributing the
Extended Transaction Client on each JBoss server.
The Extended Transaction Client is a file named com.ibm.mqetclient.jar. This is packed in the
WebSphere MQ update installer for version 6.0.2.1 or higher. The file can be found in the folder where the
update installer was expanded and saved when first installed, that is the
<install>/IBM/Source/WebSphere MQ 6.0.2.11 EnUs folder.
Copy the com.ibm.mqetclient.jar to the %JBOSS_HOME%/server/<tiplus2-server>/lib
directory.
Configure inbound messaging
All inbound messages are handled by the MDB using the resource adapter to acquire the JMS destination
from the JBoss JNDI context.
Create a wmq.jmsra-ds.xml file in the %JBOSS_HOME%/server/<tiplus2server>/deploy/messaging folder.
58
TI Plus
This file will take the form:

<?xml version=1.0 encoding=UTF-8?>
<connection-factories>

<tx-connection-factory></tx-connection-factory>

<mbean></mbean>
</connection-factories>
This will create and bind the remote connection factory and queues to the JBoss JNDI context.
In the wmq.jmsra-ds.xml file, define an <mbean> of the admin object for the incoming queue.
<mbean code="org.jboss.resource.deployment.AdminObject"
name="jboss.jca:service=WASDestination,name=meridianIncoming">
<depends optional-attributename="RARName">jboss.jca:service=RARDeployment,name='wmq.jmsra.rar'</depends>
<attribute name="JNDIName">queue/meridianIncoming</attribute>
<attribute name="Type">javax.jms.Queue</attribute>
<attribute name="Properties">
baseQueueManagerName=<value>
baseQueueName=TI.GWY.IN
</attribute>
</mbean>
Where:
The local JNDIName for the incoming queue is queue/meridianIncoming.
The baseQueueManagerName <value> is the name of the remote WebSphere MQ queue

manager.
The baseQueueName is the name of the remote WebSphere MQ incoming queue.
Configure outbound messaging

In the wmq.jmsra-ds.xml file, define an <mbean> of the admin object for the outgoing queue.
<mbean code="org.jboss.resource.deployment.AdminObject"
name="jboss.jca:service=WASDestination,name=meridianOutgoing">
<depends optional-attributename="RARName">jboss.jca:service=RARDeployment,name='wmq.jmsra.rar'</depends>
<attribute name="JNDIName">jms/meridianOutgoing</attribute>
<attribute name="Type">javax.jms.Queue</attribute>
baseQueueManagerName=<value>
baseQueueName=TI.GWY.OUT
</attribute>
</mbean>
Where:
The local JNDIName for the outgoing queue is queue/meridianOutgoing.
The baseQueueManagerName <value> is the name of the remote WebSphere MQ queue manager.
The baseQueueName is the name of the remote WebSphere MQ outgoing queue.
In the wmq.jmsra-ds.xml file, define the transaction connection factory.

<tx-connection-factory>
<jndi-name>jms/meridianQueueConnectionFactory</jndi-name>
<xa-transaction/>
<rar-name>wmq.jmsra.rar</rar-name>
<connection-definition>javax.jms.QueueConnectionFactory</connection-definition>
<config-property type="java.lang.String" name="channel">SYSTEM.DEF.SVRCONN</config-property>
<config-property type="java.lang.String" name="hostName"><value></config-property>
<config-property type="java.lang.String" name="port"><value></config-property>
<config-property type="java.lang.String" name="queueManager"><value></config-property>
<config-property type="java.lang.String" name="transportType">CLIENT</config-property>
<security-domain-and-application>JmsXARealm</security-domain-and-application>
</tx-connection-factory>
59
TI Plus
Where:
The local jndi-name is jms/meridianQueueConnectionFactory.
Set the hostName <value> to the server where WebSphere MQ is hosted.
Set the port <value> of the WebSphere MQ queue manager. By default this is set to 1414.
Set the queueManager <value> to the name of the remote WebSphere MQ queue manager.
Finally, locate the jms-ds.xml file in the %JBOSS_HOME%/server/<tiplus2server>/deploy/messaging folder. In the <tx-connection-factory> definition for JmsXA, update
the property SessionDefaultType to be javax.jms.Queue.
To access the connection factory, you will need to add the following property to the
jndi.jms.meridianQueueConnectionFactory=java:jms/meridianQueueConnectionFactory
Configure the Message Driven Bean
To link the message driven bean to the WebSphere MQ queue, add the following properties to the
jboss.meridianIncoming.invoker.binding.name=message-inflow-driven-bean
jboss.meridianIncoming.resource.adapter.name=wmq.jmsra.rar
jboss.meridianIncoming.activation.config.useJNDI=true
jboss.meridianIncoming.activation.config.channel=SYSTEM.DEF.SVRCONN
jboss.meridianIncoming.activation.config.hostName=<value>
jboss.meridianIncoming.activation.config.port=<value>
jboss.meridianIncoming.activation.config.transportType=CLIENT
For more information, see the section on JBoss Integrating Other JMS Providers.
For JBoss, each server will reference queues defined locally to that server, but the zone servers will also use
the JBoss Messaging Bridge facility to pass messages between servers. It is possible to define the bridge
definitions on either the global server or the zone server. In our case, it is more appropriate to set the bridge
definition on the zone server so messages are only pushed and pulled when the zone server is running.
Global Server
Rebroadcaster
Incoming
Messaging Bridge
OutgoingReply
Incoming
Outgoing
IncomingResponse
BroadcastReply
TI2Broadcast
Local JMS
Pull
Push
Pull
TI1Broadcast
TI2.ENQUIRY.REPLY
Push
TI1.ENQUIRY.REPLY
Messaging Bridge
Incoming
IncomingResponse
OutgoingReply
Outgoing
Local JMS
Local JMS
Zone 1 Access
Zone 2 Access
TI1 Server
TI2 Server
60
TI Plus
In order to use the JBoss Messaging Bridge facility, it is necessary to make sure that each JBoss messaging
server has a unique ServerPeerID value. To set this value, add a system property to each of the server
startup scripts:
JAVA_OPTS="$JAVA_OPTS -Djboss.messaging.ServerPeerID=<id>"
The value is simply a number starting from zero. Make sure each server has a unique number. In the
diagram, the dotted lines for queues are acting as staging queues that simply have their messages
transferred to another JMS server.
The following steps assume that there are two zones - AMERICA (deployment TI1) and EUROPE
(deployment TI2).
Global Application Server
In the global application, define a JMS queue connection factory with the JNDI name of
jms/QueueConnectionFactory:
<tx-connection-factory>
<jndi-name>jms/QueueConnectionFactory</jndi-name>
<use-java-context>false</use-java-context>
<xa-transaction/>
<rar-name>jms-ra.rar</rar-name>
<connection-definition>org.jboss.resource.adapter.jms.JmsConnectionFactory</connectiondefinition>
<config-property name="SessionDefaultType"
type="java.lang.String">javax.jms.Topic</config-property>
<config-property name="JmsProviderAdapterJNDI"
type="java.lang.String">java:/DefaultJMSProvider</config-property>
<depends>jboss.messaging:service=ServerPeer</depends>
</tx-connection-factory>
The following queues need to be defined:

Resource name
JNDI Name
REBROADCASTER.REPLY
TI1.ENQUIRY.REPLY
TI2.ENQUIRY.REPLY
Each queue is defined as follows:

<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=REBROADCASTER.INCOMING"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<attribute name="JNDIName">queue/rebroadcasterIncoming</attribute>
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
</mbean>
tiplus2 Application Server

For each of the servers where the AMERICA and EUROPE zones are accessed (TI1 and TI2 respectively),
define the queue connection factory jms/enquiryQueueConnectionFactory and the following queues:
Resource name
JNDI Name
REBROADCASTER.REPLY
TI1.ENQUIRY.OUTGOING
TI1.ENQUIRY.REPLY
Repeat this for the EUROPE zone.
61
TI Plus
The JBoss Messaging Bridge allows queues defined in different servers to be linked using their JNDI names.
In order to do this, it is necessary to provide a linkage from each tiplus2 server to the JNDI context in the
global application. This requires an ExternalContext referencing the global JNDI context to be declared
for each tiplus2 server. To do this, locate the conf/jboss-service.xml file for each tiplus2 server and
add the following:
<mbean code="org.jboss.naming.ExternalContext"
name="jboss.jndi:service=ExternalContext,jndiName=global">
<attribute name="JndiName">global</attribute>
java.naming.provider.url=jnp://<ip address>:port
</attribute>
</mbean>
Where <ip address> is the IP address of the machine where the global application is deployed and the
port number is the listening port of the JNDI NamingContext. Declaring the above enables us to access the
global JNDI context in the global application by prefixing the JNDI references with global/.
Next we need to define a remote JMS provider for the bridge to connect to push message to or pull
messages from for each tiplus2 server. This is declared by adding the following definition:
<mbean code="org.jboss.jms.jndi.JMSProviderLoader"
name="jboss.jms:service=GlobalAppJMSProviderLoader,name=GlobalAppJMSProvider">
<attribute name="ProviderName">GlobalAppXAConnectionFactory</attribute>
<attribute name="ProviderAdapterClass">org.jboss.jms.jndi.JNDIProviderAdapter</attribute>
<attribute name="FactoryRef">global/XAConnectionFactory</attribute>
<attribute name="QueueFactoryRef">global/XAConnectionFactory</attribute>
<attribute name="TopicFactoryRef">global/XAConnectionFactory</attribute>
<depends>jboss.jndi:service=ExternalContext,jndiName=global</depends>
</mbean>
Finally the JBoss Messaging Bridge definition needs to be added. The following mappings are required for
the AMERICA zone server TI1:
Source
Target
global/queue/rebroadcasterIncoming
global/queue/rebrodcasterOutgoingResponse
global/queue/ti1BroadcastIncoming
global/queue/ti1BroadcastOutgoingResponse
The equivalent mappings for the EUROPE zone server TI2 - are:
Source
Target
global/queue/rebrodcasterOutgoingResponse
These mappings are configured as follows in the messaging-secure-socket-service.xml file:

<!-Example deployment descriptor for a message bridge
$Id: messaging-secure-socket-service.xml 2737 2007-05-29 17:56:49Z timfox $
Whitespace added to some element values to improve readability
-->
<server>
<mbean code="org.jboss.jms.server.bridge.BridgeService"
name="jboss.messaging:service=TI1-enquiryOutgoing-Bridge,name=JMSBridge-ti1enquiryOutgoing"
xmbean-dd="xmdesc/Bridge-xmbean.xml">

<depends optional-attribute-name="SourceProviderLoader">
jboss.messaging:service=JMSProviderLoader,name=JMSProvider
</depends>
62
TI Plus

<depends optional-attribute-name="TargetProviderLoader">
jboss.jms:service=GlobalAppJMSProviderLoader,name=GlobalAppJMSProvider
</depends>

<attribute name="SourceDestinationLookup">queue/enquiryOutgoing</attribute>
<attribute name="TargetDestinationLookup">
</attribute>

-->
-->
-->

<attribute name="QualityOfServiceMode">2</attribute>


<attribute name="MaxBatchSize">1</attribute>

<attribute name="MaxBatchTime">-1</attribute>



<attribute name="FailureRetryInterval">30000</attribute>

<attribute name="MaxRetries">-1</attribute>

<attribute name="AddMessageIDInHeader">false</attribute>
</mbean>
<! Comments removed from remaining definitions -->
name="jboss.messaging:service=TI1-enquiryIncoming-Bridge,name=JMSBridge-ti1enquiryIncoming"
</depends>
</depends>
<attribute name="SourceDestinationLookup">
</attribute>
<attribute name="TargetDestinationLookup">queue/enquiryIncoming</attribute>
63
TI Plus
<attribute
<attribute
<attribute
<attribute
name="SourceUsername">guest</attribute>
name="SourcePassword">guest</attribute>
name="TargetUsername">guest</attribute>
name="TargetPassword">guest</attribute>
<attribute name="QualityOfServiceMode">2</attribute>
<attribute
<attribute
<attribute
<attribute
name="MaxBatchSize">1</attribute>
name="MaxBatchTime">-1</attribute>
name="FailureRetryInterval">30000</attribute>
name="MaxRetries">-1</attribute>
<attribute name="AddMessageIDInHeader">false</attribute>
</mbean>
name="jboss.messaging:service=TI1-rebroadcasterOutgoingResponse-Bridge,name=JMSBridge-ti1rebroadcasterOutgoingResponse"
</depends>
</depends>
</attribute>
<attribute name="TargetDestinationLookup">
global/queue/rebroadcasterOutgoingResponse
</attribute>
<attribute
<attribute
<attribute
<attribute
<attribute
<attribute
<attribute
<attribute
<attribute
<attribute
</mbean>
name="QualityOfServiceMode">2</attribute>
name="AddMessageIDInHeader">false</attribute>
name="jboss.messaging:service=TI1-RebroadcasterOutgoingResponse-Bridge,name=JMSBridgeti1-RebroadcasterOutgoingResponse"
</depends>
</depends>
</attribute>
<attribute name="TargetDestinationLookup">queue/enquiryOutgoingReply</attribute>
<attribute
<attribute
<attribute
<attribute
<attribute
<attribute
<attribute
<attribute
<attribute
<attribute
name="QualityOfServiceMode">2</attribute>
name="AddMessageIDInHeader">false</attribute>
</mbean>
</server>
A similar configuration is required for the EUROPE zone. Effectively scan for ti1 and replace with ti2.
64
TI Plus

To install software to a JBoss application server, make sure that the server is running, and move the EAR file
into the %JBOSS_HOME%/server/<tiplus2-server>/deploy folder. JBoss will detect the presence of
the software and install and start the software.
You can restart the server without changing the software, however if you want to uninstall the software, then
it should be done while the software is running by deleting the EAR file.
This will ensure any work areas set up for the application are cleared and re-created correctly.
Similarly if you change configuration and want to re-deploy, delete the deployed EAR first and then deploy
the new EAR.
65
TI Plus
CHAPTER 19 JBOSS EAP 6.2 (AS 7.3) SETUP

This chapter summarises the JBoss EAP 6.2 (AS 7.3) setup required to deploy the TI Plus software.
Note: At the time of writing, JBoss AS 7.3 has not been made available as an independent download. Due to
some significant changes after JBoss 7.1, the earliest version supported for this platform is EAP 6.2
For the rest of this chapter, JBoss 7 will mean JBoss EAP 6.2 (AS 7.3).
With previous versions of JBoss, servers were set up independently, with most configurations being defined
by creating/updating various XML files. In JBoss 7, servers may still be set up individually referred to as
standalone servers or may be set up within domains using the new Management Console or Management
CLI tool.
While the new Management Console provides the means to configure the majority of what is required, the
XML configuration will still need to be updated for particular things.
One of the main differences is that now a single XML file controls the configuration, for both domain and
standalone configurations.
The rest of this chapter will concentrate on setting up a domain with separate servers for the global
application and the tiplus2 application. The steps may switch from using the management console to editing
the xml file(s) directly, however this is due to the management console not being able to provide the full
configuration facilities.
Please refer to the JBoss Enterprise Application Platform 6.2 Administration and Configuration Guide from
the Red Hat website for more details on JBoss 7.
PRE-REQUISITE SOFTWARE
Java
The minimum version of Java required is Java 1.6; this must be installed before JBoss 7 can start. The latest
version of 1.6 should be used.
JBoss 7 has the following folder structure:
Folder
Content
/appclient
Configuration files, deployment content, and writable areas used by the

application client container run from this installation.
/bin
Start up scripts, start up configuration files and various command line utilities
like vault, add-user and Java diagnostic report available for Unix and Windows
environments
/bin/client
Jar files required to run a JEE client
/bundles
Location of OSGi bundles
/docs
DTD and schema definitions as well as sample configuration files
/domain
Configuration files, deployment content, and writable areas used by the domain
mode processes run from this installation
/modules
JBoss 7 is based on a modular classloading architecture. The various modules

used in the server are stored here
/standalone
Configuration files, deployment content, and writable areas used by the single
standalone server run from this installation
/welcome-content
Default welcome page content
66
TI Plus
The /appclient, /domain and /standalone folders act as templates for creating the respective
environments.
Note: For the rest of this chapter, the identifier JBOSS will be used to represent the folder where the JBoss 7
software has been installed.
The /domain folder contains the following subfolders:
Folder
Content
/configuration
Configuration files for the domain and for the Host Controller and any servers
running off of this installation. All configuration information for the servers
managed within the domain is located here and is the single place for
configuration information
/content
An internal working area for the Host Controller that controls this installation.
This is where it internally stores deployment content. This directory is not meant
to be manipulated by end users.
Note that a domain does not support deploying content based on scanning a file
system
/lib/ext
Location for installed library jars referenced by applications using the ExtensionList mechanism
/log
Location where the Host Controller process writes its logs. The Process
Controller, a small lightweight process that actually spawns the other Host
Controller process and any Application Server processes also writes a log here.
/servers
Writable area used by each application server instance that runs from this
installation. Each application server instance will have its own subfolder, created
when the server is first started. In each server's subdirectory there will be the
following subfolders:
/data -- information written by the server that needs to survive a restart of the
server
/log -- the server's log files
/tmp -- location for temporary files written by the server
/tmp
Location for temporary files written by the domain/host controller
/tmp/auth
Special location used to exchange authentication tokens with local clients so they
can confirm that they are local to the running process
The /standalone folder contains the following subfolders:

Folder
Content
/configuration
Configuration files for the standalone server that runs off of this installation. All
configuration information for the running server is located here and is the single
place for configuration modifications for the standalone server.
/data
Persistent information written by the server to survive a restart of the server
/deployments
End user deployment content can be placed in this directory for automatic
detection and deployment of that content into the server's runtime.
NOTE: The server's management API is recommended for installing deployment
content. File system based deployment scanning capabilities remain for
developer convenience.
/lib/ext
Location for installed library jars referenced by applications using the ExtensionList mechanism
/log
Standalone server log files
/tmp
Location for temporary files written by the server
/tmp/auth
Special location used to exchange authentication tokens with local clients so they
can confirm that they are local to the running AS process
It is recommended that the folders /domains and /servers are added to the JBoss 7 folder to contain the
specific configurations to be created.
67
TI Plus
For this chapter, copy the /domain folder to be a subfolder of /domains called /tiplus2.
Management User
In order to use the management console for configuring/controlling the domain, a management user needs
to be created for the domain configuration. This is done by executing the following command from the
JBOSS/bin folder:
add-user.bat dc ../domains/tiplus2/configuration
This will prompt for the type of user take the default of a.
Enter the Username and Password when prompted. Note that the password must be at least 8 characters
long and contain at least one digit and one non-alphanumeric character.
Take the default when prompted for the groups the user should be added to and answer no to whether the
user is to be used for a remote server to access a local server.
Startup Scripts
Create startup scripts by copying domain.bat and domain.conf.bat (or domain.sh and domain.conf
based on the OS you are using). For the rest of the chapter, it is assumed that JBoss 7 is running on
Windows.
Name the files domain-tiplus2.bat and domain-tiplus2.conf.bat respectively.
Edit the file domain-tiplus2.bat, and add the following environment variable declarations at the
beginning of the file:
set
set
set
set
"JBOSS_HOME=<JBOSS installation folder>"

"JBOSS_BASE_DIR=%JBOSS_HOME%\domains\tiplus2"
"JBOSS_CONFIG_DIR=%JBOSS_BASE_DIR%\configuration"
"DOMAIN_CONF=%JBOSS_HOME%\bin\domain-tiplus2.conf.bat"
Edit the domain-tiplus2.conf.bat and locate the JAVA_HOME reference. Uncomment the reference
and set the variable to the location of where the java software has been installed.
To reference the correct configuration folder, add the following java option towards the end of the file:
set "JAVA_OPTS=%JAVA_OPTS% -Djboss.domain.base.dir=%JBOSS_BASE_DIR%"
By default, the management console is bound to the localhost so is not available remotely. To bind it to the
local machine name instead, add the following java option towards the end of the file:
set "JAVA_OPTS=%JAVA_OPTS% -Djboss.bind.address.management=<machine-name>"
To start the domain controller, run the following command from the JBoss 7 /bin folder:
domain-tiplus2.bat
MANAGEMENT CONSOLE
To use the management console, open a browser and navigate to the URL:
http://localhost:9990/console (or reference the machine name if this has been set)
You will be prompted to enter a user id and password. Enter the credentials configured earlier.
Note: If no users have been set up, you will not be able to access the management console.
This proves that the initial setup is correct.
As part of the initial configuration, there are sample servers and server-groups included. These may be
deleted from the Hosts tab.
68
TI Plus
Profiles, Socket Binding Groups and Server Groups

The JBoss 7 domain configuration depends on the three definitions of:
Profiles Define resources such as data sources, queues, web container settings etc
Socket Binding Group a collection of named ports based on the set of JEE features you intend to
use
Server Group defines a combination of profile and socket binding, and some default properties for
servers assigned to the group. Can also be thought of as a cluster definition
In order to create a server instance, you must have a server group to define it in. The server group must
reference both a profile and a socket binding group.
The standalone configuration has a single profile and socket binding group definition the concept of server
group does not match, as the configuration applies to a single server.
In the default domain configuration provided, there are four sample profiles and socket binding groups. For
each deployment of software, a unique profile is required based on one of the samples supplied.
A deployment of software is the set of applications that will be deployed to a server group. So for instance if
you intend to deploy the global application and zone application to a single server within a server group, your
profile needs to contain all of the resources.
For the rest of this chapter, we will need a profile for the global application and a profile for the tiplus2
application. For the moment we will use a shared socket binding group, however this could be separated as
well.
The profile we will use as a starting point will be the full profile, so we need to make a few changes to the full
profile before we copy it.
JDBC Drivers
JDBC drivers can be deployed to individual servers or server groups, but it makes more sense to make them
a core module, and reference them as a global module. Otherwise each application would need to reference
the module as a dependency.
For instance, to install a driver in a jar file called ojdbc6_11.2.0.3.jar as a core module called
com.oracle you need to do the following:
Create the folder JBOSS_HOME/modules/com/oracle/main
Copy the ojdbc6_11.2.0.3.jar file into the folder created
Create the following module.xml file:

<module xmlns="urn:jboss:module:1.1" name="com.oracle">
<resources>
<resource-root path="ojdbc6_11.2.0.3.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.servlet.api" optional="true"/>
</dependencies>
</module>
This then needs to be set as a global model. Make sure the domain management server is not running, and
open the domain.xml file in a text editor.
Find the <profile> whose name is full
Find the <subsystem> whose xmlns is urn:jboss:domain:ee:1.1
Add the following at the beginning of this element

<global-modules>
<module name="com.oracle"/>
</global-modules>
The profile then needs to reference this module as an available JDBC driver:
Find the <subsystem> whose xmlns is urn:jboss:domain:datasources:1.1
In the <drivers> element, add the following:

69
TI Plus
<driver name="oracle" module="com.oracle"/>
A similar process can be used to register a module called com.db2 if that is the DBMS you are using. In this
case, the jar files and the module.xml file would be placed in the JBOSS/modules/com/db2/main folder.
Creating Profiles
To create the profiles for the global and tiplus2 applications, simply copy the <profile> called full for
each one, naming them full-global and full-<deployment id> (e.g. the default deployment id is
ti1, so the profile would be called full-ti1).
Note: This is a suggested naming convention for illustration purposes.
JMX and Remoting

As part of JBoss 7, RMI was no longer supported as a JMX transport, so the management communication
between the global application and tiplus2 application instances now uses the JBoss remoting API. For this,
the ports to be used must be reserved.
These are:
The JMXGlobalPort
A port for each tiplus2 instance based on the deployment id
Start the domain management server.

From the Profiles tab, select Socket Binding from the General Configuration section on the left hand side.
Select the View link for the full-sockets group this is the group we will be using for both applications. If
you need to use separate ones, then copy the definition in the domain.xml file as we did for profiles.
Add the following socket bindings:
Name
Port
Binding-group
remoting-global
4448
full-sockets
remoting-ti1
4449
full-sockets
The JMXGlobalPort property must be set to the same value as the remoting-global port in the
global.configuration.properties file.
The remoting-ti1 port will be discovered at runtime when a server instance starts.
Note: The deployment id is converted to lowercase, and the remoting name derived accordingly
This means that the JMXZonePortStart and JMXZonePortEnd properties do not need to be set for JBoss
7.
To link these port reservations to the remoting service, each profile must add a reference to the new port.
Make sure the domain controller is not running. Open the domains.xml file and change the following:
Find the <profile> whose name is full-global
Find the <subsystem> whose xmlns value is urn:jboss:domain:remoting:1.1
Add a new <connector> child

<connector name="remoting-connector-global"
socket-binding="remoting-global"/>
Find the <profile> whose name is full-ti1
Find the <subsystem> whose xmlns value is urn:jboss:domain:remoting:1.1
Add a new <connector> child (replace ti1 with your deployment id converted to lower case)
<connector name="remoting-connector-ti1" socket-binding="remoting-ti1"/>
70
TI Plus
Server Groups
From the Hosts tab, create two server groups one for the global application and one for the tiplus2
application.
Select Server Groups from the Server section on the left hand side. Add the following two groups:
Name
Profile
Socket Binding
group-global
full-global
full-sockets
group-ti1
full-ti1
full-sockets
You can edit these groups to add default JVM settings. Any servers added to the server group will use these
unless overridden.
Web Container
By default, the profiles are not configured to use SSL.
From the Profiles tab, select the full-global profile from the drop-down, and expand Web in the
Subsystems section. Select Servlet/HTTP, and then click on the Connectors mini tab.
Click Add, and enter the following:
Property
Value
Name
https
Socket Binding
https
Protocol
HTTP/1.1
Scheme
https
Enabled
checked
Click Save.
Note: This is not the complete configuration for SSL, as not all settings can be entered through the domain
management console see later section
The sample configuration also provides a virtual server definition with some aliases that should be replaced.
Click on the Virtual Servers mini tab.
Select default-host and click on Edit.
Replace the aliases with an appropriate value.
This must be repeated for the full-ti1 profile.
Setting up SSL
Create the folder JBOSS/domains/common and open a terminal at this location.
To create a certificate for each application server, execute the following command for each configuration:
keytool -genkey -alias <mykey> -keyalg RSA -validity 3650 -keystore
mykeys.keystore
setting the <mykey> value to one that represents the configuration.
Also create a trust store with the certificates, by first exporting them:
keytool -export -alias <mykey> -keystore mykeys.keystore -file <mykey>.cer
and then importing them:
keytool -import -alias <mykey> -file <mykey>.cer -keystore mykeys.truststore
You will be prompted for password and identity information. When asked for first and last name, enter the
host name of the URL associated with the application server.
To reference the certificates, the domains.xml file must be updated. Make sure the domain controller is not
running.
Open the domains.xml file and make the following changes:
Find the full-global profile, and locate the <subsystem> with the xmlns value of
urn:jboss:domain:web:1.5
71
TI Plus
Add the attribute secure=true to the <connector> whose name is https
Add a child element of <ssl> as follows:

<connector name="https" protocol="HTTP/1.1" scheme="https"
socket-binding="https" secure="true" enabled="true">
<ssl name="ssl" key-alias="full-global" password="<password>"
certificate-key-file="${jboss.home.dir}/domains/common/mykeys.keystore"
verify-client="false"/>
</connector>
Repeat this for the full-ti1 profile.

Start the domain controller. For each server group from the Hosts tab, edit the JVM Configuration to define
JVM Options:
-Djavax.net.ssl.trustStore=${jboss.home.dir}/domains/common/mykeys.truststore
-Djavax.net.ssl.trustStorePassword=<password>
DEFINING SERVERS
Just before creating new servers, add two common JVM Options to each of their server groups:
-Dorg.apache.el.parser.SKIP_IDENTIFIER_CHECK=true
-Dorg.jboss.as.logging.per-deployment=false
Create a server definition for each of the global and tiplus2 applications global-server and ti1server. Reference the relevant server group and the full-sockets socket binding group.
Since we are using the same socket binding group, each server must provide a port offset to make the set
unique.
Note: If you create a global server, make sure the port offset is 0 in a clustered environment, there must
only be one global server instance per IP address up to a maximum of two instances
For each server define the JVM Option:
-Djboss.bind.address=<host name>
CONFIGURING PROFILES
Some of the remaining resources to be defined require servers to be running. From the Runtime tab, hover
over each server and click the link Start server.
JDBC Configuration
From the Profiles tab, select the relevant profile from the dropdown and then Datasources under Connector
in the Subsystems section on the left hand side.
Select the XA Datasources tab.
For each datasource, click Add, and enter the following information:
Property
Value
Name
Global
JNDI Name
java:/jdbc/global
Click Next and select the Detected Driver mini tab:

Property
Value
Name
oracle
XA Data Source Class
oracle.jdbc.xa.client.OracleXADataSource
Click Next and add the following XA Property:

Key
Value
URL
jdbc:oracle:thin:@<host>:1521:<db>
Click Next and enter the following information:

72
TI Plus
Property
Value
Username
TIGLOBAL (or applicable)
Password
TIGLOBAL (or applicable)
Click Done.
Review the connection pool properties from the Pool mini tab.
Once defined, select the data source and enable it.
Repeat the process for each of the data sources that need to be defined for each server group.
For the global application, this is:
java:/jdbc/global
For the tiplus2 application, this is:
java:/jdbc/global
java:/jdbc/zone
java:/jdbc/dlzone
java:/jdbc/reports
JMS Configuration
Service Access

The async and notification frameworks will use the supplied default JMS provider. The global JNDI name of
the default queue connection factory is java:/JmsXA. This means that it is necessary to add the property:
jndi.jms.QueueConnectionFactory=java:/JmsXA
to the jndi.resource.locator.properties file.
From the Profiles tab, select the full-ti1 profile from the dropdown and the Destinations from Messaging
in the Subsystems section on the left hand side.
Click the View option for the default JMS Messaging Provider.
From the Queues/Topics mini tab, click Add.
Enter the Name and JNDI name for each queue:
Name
JNDI Name
JobLifecycleQueue
java:/queue/JobLifecycleQueue
JobExecutionQueue
java:/queue/JobExecutionQueue
StepExecutionQueue
java:/queue/StepExecutionQueue
NotificationQueue
java:/queue/NotificationQueue
DeadMessageQueue
java:/queue/DeadMessageQueue
For the JobLifecycleQueue, JobExecutionQueue and NotificationQueue a delivery retry

configuration must be added to attempt delivery up to 5 times before re-directing the message to the
DeadMessageQueue.
Select the Address Settings mini tab.
For each of the three queues add an Addressing Setting specifying the Pattern, Dead Letter Address and the
Max Delivery Attempts to 5 as follows:
Pattern
Dead Letter Address
JobLifecycleQueue
DeadMessageQueue
JobExecutionQueue
DeadMessageQueue
73
TI Plus
Pattern
Dead Letter Address
NotificationQueue
DeadMessageQueue
If you are setting up a split deployment, then this definition corresponds to the async framework server.
For the user access server, then only the JobLifecycleQueue, JobExecutionQueue and
NotificationQueue definitions are required though the re-delivery configuration is not required for
these definitions.
To link these two queues to the async framework server, then a messaging bridge needs to be set up in the
user access server to push messages from the job lifecycle, job execution and notification queues to the
equivalent queues in the async framework server. This will require:
A foreign JNDI server definition
Messaging bridge definition
The details of this configuration are not shown here. Review the section on the cross-zone dashboard, and
base your configuration on that example. This scenario is simplified because there is only one-way traffic.
Service Access
section describes how to configure MQ to be used with JBoss 7. The example used to describe the
The minimum version of IBM WebSphere MQ Series required is 7.0.7.
Install the WebSphere MQ resource adapter

The WebSphere MQ resource adapter libraries are packed in the wmq.jmsra.rar file. This is found in the
WebSphere MQ installation folder java/lib/jca.
For XA support, the WebSphere MQ Extended Transaction Client is required. This is usually in the adapter
file. If not, then it will be in the java/lib folder, and may be added to the .rar file for convenience.
This adapter can now be deployed.
Select the Manage Deployments option from the Runtime tab, and add the wmq.jms.rar file. Then assign it
to the appropriate server groups in this case to group-ti1.
Configure Resource Adapter

Make sure the domain controller is not running.
Open the domains.xml file and make the following changes:
Find the <profile> whose name is full-ti1
Find the <subsystem> with the xmlns value of urn:jboss:domain:resource-adapters:1.1
Usually this is an empty tag. If so, replace it as follows otherwise merge the definitions:
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
<resource-adapters>
<resource-adapter id="wmq.jmsra.rar">
<archive>wmq.jmsra.rar</archive>
<transaction-support>XATransaction</transaction-support>
<connection-definitions>
<connection-definition
class-name="com.ibm.mq.connector.outbound.ManagedQueueConnectionFactoryImpl"
jndi-name="java:/jms/meridianQueueConnectionFactory"
pool-name="java:jms/meridianQueueConnectionFactory">
<config-property name="port">1414</config-property>
<config-property name="hostName">MQSERVER</config-property>
74
TI Plus
<config-property name="channel">SYSTEM.DEF.SVRCONN</config-property>
<config-property name="transportType">CLIENT</config-property>
<config-property name="queueManager">QMGR</config-property>
</connection-definition>
</connection-definitions>
<admin-objects>
<admin-object
class-name="com.ibm.mq.connector.outbound.MQQueueProxy"
jndi-name="java:/queue/meridianIncoming"
pool-name="java:/queue/meridianIncoming">
<config-property name="baseQueueName">TI.GWY.IN</config-property>
<config-property name="baseQueueManagerName">QMGR</config-property>
</admin-object>
<admin-object
class-name="com.ibm.mq.connector.outbound.MQQueueProxy"
jndi-name="java:/queue/meridianOutgoing"
pool-name="java:/queue/meridianOutgoing">
<config-property name="baseQueueName">TI.GWY.OUT</config-property>
<config-property name="baseQueueManagerName">QMGR</config-property>
</admin-object>
</admin-objects>
</resource-adapter>
</resource-adapters>
</subsystem>
Where
The hostname is the name of the machine where the WebSphere MQ server is running
The queueManager is the name of the remote WebSphere MQ queue manager
The baseQueueManagerName is the name of the remote WebSphere MQ queue manager
The baseQueueName is the name of the relevant remote WebSphere MQ queue
Configure the Message Driven Bean

To access the connection factory, you will need to add the following property to the
jndi.jms.meridianQueueConnectionFactory=java:jms/meridianQueueConnectionFactory
To link the message driven bean to the WebSphere MQ queue, add the following properties to the
jboss.meridianIncoming.resource.adapter.name=wmq.jmsra.rar
jboss.meridianIncoming.activation.config.useJNDI=true
jboss.meridianIncoming.activation.config.channel=SYSTEM.DEF.SVRCONN
jboss.meridianIncoming.activation.config.hostName=<value>
jboss.meridianIncoming.activation.config.port=<value>
jboss.meridianIncoming.activation.config.transportType=CLIENT
For more information, see the section on JBoss Integrating Other JMS Providers.
75
TI Plus
For JBoss 7, each server will reference queues defined locally to that server, but the zone servers will also
use the JBoss7 JMS Bridge facility to pass messages between servers. It is possible to define the bridge
definitions on either the global application server or the tiplus2 application server. In our case, it is more
appropriate to set the bridge definition on the tiplus2 application server so messages are only pushed and
pulled when the zone server is running.
Global Server
Rebroadcaster
Incoming
Messaging Bridge
Incoming
OutgoingReply
Outgoing
BroadcastReply
TI2Broadcast
Local JMS
Pull
Push
Pull
TI1Broadcast
TI2.ENQUIRY.REPLY
Push
TI1.ENQUIRY.REPLY
Messaging Bridge
Incoming
IncomingResponse
IncomingResponse
OutgoingReply
Outgoing
Local JMS
Local JMS
Zone 1 Access
Zone 2 Access
TI1 Server
TI2 Server
The following steps assume that there are two zones - AMERICA (deployment TI1) and EUROPE
(deployment TI2).
Global Application Server

The queues in the global application need to be accessible remotely so must have multiple JNDI names, one
for internal use, and one for remote use.
Define the following queues:
Resource name
JNDI Names
REBRAODCASTER.INCOMING
java:/queue/rebroadcasterIncoming
java:jboss/exported/queue/rebroadcasterIncoming
REBROADCASTER.REPLY
java:/queue/rebroadcasterOutgoingResponse
java:jboss/exported/queue/rebroadcasterOutgoingResponse
java:/queue/ti1BroadcastIncoming
java:jboss/exported/queue/ti1BroadcastIncoming
TI1.ENQUIRY.REPLY
java:/queue/ti1BroadcastOutgoingResponse
java:jboss/exported/queue/ti1BroadcastOutgoingResponse
java:/queue/ti2BroadcastIncoming
java:jboss/exported/queue/ti2BroadcastIncoming
TI2.ENQUIRY.REPLY
java:/queue/ti2BroadcastOutgoingResponse
java:jboss/exported/queue/ti2BroadcastOutgoingResponse
76
TI Plus
The queue connection factory needs to be XA compliant. The easiest way of doing this is to add another
JNDI entry to the hornetq-ra <pooled-connection-factory> for the group-global profile. The
XML section should look like:
<pooled-connection-factory name="hornetq-ra">
<transaction mode="xa"/>
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<entry name="java:/JmsXA"/>
<entry name="java:/jms/QueueConnectionFactory"/>
</entries>
</pooled-connection-factory>
tiplus2 Application Server

For each of the servers where the AMERICA and EUROPE zones are accessed (TI1 and TI2 respectively),
define the following queues:
Resource name
JNDI Name
java:/queue/enquiryIncoming
REBROADCASTER.REPLY
java:/queue/rebroadcasterOutgoingResponse
TI1.ENQUIRY.OUTGOING
java:/queue/enquiryOutgoing
TI1.ENQUIRY.REPLY
java:/queue/enquiryOutgoingReply
The queue connection factory needs to be XA compliant. The easiest way of doing this is to add another
JNDI entry to the hornet-ra <pooled-connection-factory> for the full-ti1 profile. The XML
section should look like:
<pooled-connection-factory name="hornetq-ra">
<transaction mode="xa"/>
<connectors>
<connector-ref connector-name="in-vm"/>
</connectors>
<entries>
<entry name="java:/JmsXA"/>
<entry name="java:/jms/enquiryQueueConnectionFactory"/>
</entries>
</pooled-connection-factory>
Repeat this for the EUROPE zone (TI2 deployment, full-ti2 profile).
Configuring the JMS Bridge

The JMS Bridge allows queues defined in different servers to be linked using their JNDI names. In order to
do this, it is necessary to provide a linkage from each tiplus2 server to the JNDI context in the global
application.
This involves four <jms-bridge> entries added to the messaging <subsystem> after the <hornetqserver> for the relevant profile.
<jms-bridge name="ti1-enquiryOutgoing-bridge">
<source>
<connection-factory name="/ConnectionFactory"/>
<destination name="/queue/enquiryOutgoing"/>
</source>
<target>
<connection-factory name="/jms/RemoteConnectionFactory"/>
<destination name="/queue/rebroadcasterIncoming"/>
<user>user name</user>
<password>password</password>
<context>
<property key="java.naming.factory.initial"
value="org.jboss.naming.remote.client.InitialContextFactory"/>
<property key="java.naming.provider.url" value="remote://hostname:4447"/>
</context>
</target>
<quality-of-service>AT_MOST_ONCE</quality-of-service>
<failure-retry-interval>10000</failure-retry-interval>
77
TI Plus
<max-retries>-1</max-retries>
<max-batch-size>500</max-batch-size>
<max-batch-time>500</max-batch-time>
<add-messageID-in-header>true</add-messageID-in-header>
</jms-bridge>
<jms-bridge name="ti1-rebroadcasterOutgoingResponse-bridge">
<source>
<destination name="/queue/rebroadcasterOutgoingResponse"/>
</source>
<target>
<destination name="/queue/rebroadcasterOutgoingResponse"/>
<context>
</context>
</target>
</jms-bridge>
<jms-bridge name="ti1-enquiryIncoming-bridge">
<source>
<destination name="/queue/ti1BroadcastIncoming"/>
<context>
</context>
</source>
<target>
<destination name="/queue/enquiryIncoming"/>
</target>
</jms-bridge>
<jms-bridge name="ti1-enquiryOutgoingReply-bridge">
<source>
<destination name="/queue/ti1BroadcastOutgoingResponse"/>
<context>
</context>
</source>
<target>
<destination name="/queue/enquiryOutgoingReply"/>
78
TI Plus
</target>
</jms-bridge>
You may be required to configure a user name and password in order to send or consume messages from
remote queues. The default hornet settings require users with the guest role. Create a user in a similar
way to the administration user referred to earlier in the Application Realm with a role of guest.
A similar configuration is required for the EUROPE zone. Effectively scan for ti1 and replace with ti2.

Before creating the application enterprise archives, the following properties must be defined in the
global.configuration.properties file:
appserver.jboss=yes
appserver.jee6=yes
Once assembled, they can be deployed as follows:
From the Runtime tab, select Manage Deployments in the Domain section on the left hand side.
Click Add, and locate the EAR file to deploy. Once deployed, select the application and click
Assign. Check the appropriate server group and click Save.
It is recommended that the global application is deployed first, and then the user log on to verify the
deployment configuration. Once checked, the tiplus2 application may then be deployed.
79
TI Plus
CHAPTER 20 FIRST STEPS

Once the software is installed, the following first steps must be performed:
Start the global application server, check the deployment and zone configuration and then start the
first tiplus2 application server
Install TI Plus products
Upload document templates
STARTING THE TI PLUS SOFTWARE

Start the global application server.
Once the global application has started, log in using SUPERVISOR/SUPERVISOR1 and make sure the
deployment and zone definitions are consistent with the configuration options used when assembling the
enterprise archives.
The tiplus2 application server for the zone may now be started.
INSTALLING TI PLUS PRODUCTS

TI Plus product definitions are provided as .csv files in the /csv distribution folder . They are installed by
importing the definitions using the Configuration application in the zone.
Extract and copy the files to the configured /tiplus2/csv/import folder on the application server.
Login to TI Plus using SUPERVISOR/SUPERVISOR1 and navigate to the zone.
Launch the Configuration application. Once the configuration application has started, you will see the
following issues screen showing basic missing data.
Click Close to continue to the configuration menu and select the Installation|Import menu option.
After clicking the Import option, TI Plus will validate the existence of the .csv files needed at this stage. If
the .csv files are not present in the required folder, you will get a validation message of Failed to open
import file in the validation column. Confirm that the .csv files exist in the required folder and/or confirm that
you have created the correct folder.
A successful validation will provide information in the columns of version, created, unit and user. It is now
possible to import the .csv configuration files and provide the base configuration
TI Plus displays information for products that should be present using the Configuration Import window
80
TI Plus
TI Plus displays information for each configuration file that should be present under the following headings. If
any file that should be present is not found, TI Plus displays information under the first two headings only.
Heading
What it shows
Code
A unique code.
Product
A description identifying the type of configuration information.
Version
The version of TI Plus used to create the configuration file for the product.
Created
The date on which the configuration file was created.
Unit
The mnemonic of the unit from which the configuration file was created. Note that files
supplied by Misys will have a dummy unit of S/A.
User
The user
Validation
If appropriate, a text message detailing any problems TI Plus encountered when

attempting to open the configuration file.
Import?
Indicates whether the product is selected for processing or not. This is initially N (not
selected) for all products
A separate button is available to import the security capabilities. This must be run first.
The first files to import are the general non-product-specific files GEN, CDE and REP. Select each one in turn
and then press Do selected.
Note that if you are importing these files for a TI Plus system that is to interface to an Equation system, then
for GEN and CDE, press Options, and select only the following optional items:
GEN TI General Configuration
Documents
CDE Static codes
Incoterms
Locales
This will also create the SUPERVISOR user. Exit the application until you see the global application list of
zones, and navigate back to the zone. You need to go to the Security application and give SUPERVISOR all
capabilities using the Capabilities map menu option.
Launch the Security application and on the Capabilities map page, refresh and highlight SUPERVISOR and
press Select. Then scroll down to Unassigned access authorities and press Assign All. Do this before
continuing with the product-specific imports.
Exit from the zone application this will refresh the capabilities of the user.
Return to the Installations|Import section of the Configuration application and select each of the required
product-specific files in turn (either singularly, altogether, or in small batches).
TI Plus processes the selected products, providing messages advising you of its progress and informing you
when processing has finished
81
TI Plus
Import all the .csv files for the products you intend to use except for the first three that you have already
imported and the SSD.
Note: Only import those products you will be using when you initially go live. Do not import products that will
be implemented after the initial live date, as this will complicate the subsequent implementation of these
products in the live environment.
The ODC.CSV file holds information used by all four collection order products. Therefore, if you import any of
the four collection order products you must import both the product-specific .CSV file and the ODC.CSV file.
If you are going to import the supplied SSD file, then a new system option must be created. Run the System
Tailoring application, and select the Zone options menu. Add a new System option by pressing the New
button, calling the new option SSD and setting it to All. Finally, return to Configuration application, and
import the SSD.csv file.
Once imported, in the System Tailoring application, take the Branch options/Service mappings link, and
select the branch shown and click Assign services. Refresh the list, and assign them all to the branch.
UPLOADING THE DOCUMENT TEMPLATES

The Standalone Template Utility is designed to generate a zip file (templates.zip) suitable for uploading to a
zone application. However, to upload the default templates, you may use the provided templateshtml.zip from the /ti/templates distribution folder.
Start the System Tailoring application and select the Documents menu and then select the Upload
Templates menu on the left hand side.
Click Browse.. and locate the relevant templates.zip file. Click the OK button of the file chooser dialog
box.
Click OK. The upload template facility will show a list detailing the templates that have been uploaded
82

Installation Guide 25 v1.1

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Installation Guide 25 v1.1

Diunggah oleh

Hak Cipta:

Format Tersedia

TI PLUS/2.

COPYRIGHT MISYS 1995-2014. ALL RIGHTS RESERVED.

For more information

Chapter 2 Installing Software Prerequisites

Chapter 3 Installation Summary

Chapter 4 Database Setup

Chapter 5 Application Software

Chapter 6 Application Topology

Chapter 8 JNDI Resources

Chapter 9 Asynchronous Framework

Chapter 10 Notification Framework

Chapter 11 Service Access

Bulk Message Handling Incoming

Chapter 12 Cross Zone Dashboard

Chapter 14 Application Server Specific

Chapter 15 Operating System Specific

Chapter 16 WebSphere Setup

Chapter 17 WebLogic Setup

Chapter 18 JBoss 5.1 Setup

Chapter 19 JBoss EAP 6.2 (AS 7.3) Setup

Chapter 20 First Steps

PREFACE - INSTALLATION GUIDE

discusses the software prerequisites and a recommended installation sequence.

details how to create the TI Plus database.

details operating system specific areas of set up.

details how to set up WebSphere 7/8.5.

details how to set up WebLogic 10.3.

details how to set up JBoss 5.1.

details how to set up JBoss EAP 6.2 (AS 7.3).

details the first steps to perform after the software is deployed.

CHAPTER 1 SYSTEM OVERVIEW

Allows the individual components of the system to communicate

Acts as database storage for TI Plus business data

Provides an access point for load balancing

Main application for TI Plus. This runs on the application server

Windows 2008 Server 64bit

Red Hat Linux Enterprise

WebLogic 11g (10.3.6)

JBoss EAP 6.2 (AS 7.3)

Storage location of files used and managed by the application

CHAPTER 2 INSTALLING SOFTWARE PREREQUISITES

The Database Server

The Application Server

The HTTP Server

The Database Server

Solaris or Windows 2008 or equivalent

Oracle 11g/DB2 v9.7

The Application Server

JavaSE6 may be installed as part of the application server installation

WebLogic 11g, WebSphere 7.0/8.5 or JBoss 5.1/EAP 6.2 (AS 7.3)

RECOMMENDED INSTALLATION SEQUENCE

Install the database software.

Install JavaSE6 on the Application server(s) if necessary.

Install WebSphere/WebLogic/JBoss software on the Application server(s).

CHAPTER 3 INSTALLATION SUMMARY

THE TI PLUS SOFTWARE DISTRIBUTION

/csv contains product configuration files

/scripts contains the database scripts

/sdk contains tools and resources associated with the SDK

/software contains the application software

/ti contains various resources

/tools contains utilities

OVERALL INSTALLATION SEQUENCE

Configure and assemble the TI Plus 2 application archives