TIBCO Managed File Transfer Command Center User's Guide€¦ · TIBCO® Managed File Transfer...

TIBCO® Managed File Transfer CommandCenterUser's GuideSoftware Release 8.0.1August 2016

Two-Second Advantage®

Important Information

SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCHEMBEDDED OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (ORPROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THEEMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANYOTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE.

USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS ANDCONDITIONS OF A LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTEDSOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THECLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOADOR INSTALLATION OF THE SOFTWARE (AND WHICH IS DUPLICATED IN THE LICENSE FILE)OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR CLICKWRAP END USERLICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE “LICENSE” FILE(S) OF THESOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, ANDYOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BEBOUND BY THE SAME.

This document contains confidential information that is subject to U.S. and international copyright lawsand treaties. No part of this document may be reproduced in any form without the writtenauthorization of TIBCO Software Inc.

TIBCO, Two-Second Advantage, TIBCO Managed File Transfer, TIBCO Managed File TransferCommand Center, TIBCO Managed File Transfer Internet Server, TIBCO Managed File TransferPlatform Server, TIBCO Managed File Transfer Platform Server Agent, and TIBCO Slingshot are eitherregistered trademarks or trademarks of TIBCO Software Inc. or its subsidiaries in the United Statesand/or other countries.

All other product and company names and marks mentioned in this document are the property of theirrespective owners and are mentioned for identification purposes only.

THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOTALL OPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASEDAT THE SAME TIME. SEE THE README FILE FOR THE AVAILABILITY OF THIS SOFTWAREVERSION ON A SPECIFIC OPERATING SYSTEM PLATFORM.

THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSOR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.

THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICALERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESECHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCOSOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S)AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY TIME.

THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY ORINDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE,INCLUDING BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES.

Copyright ©2003-2016 TIBCO Software Inc. All rights reserved.

TIBCO Software Inc. Confidential Information

2

TIBCO® Managed File Transfer Command Center User's Guide

Contents

TIBCO Documentation and Support Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Product Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Administrator Browser Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Accessing the Administrator Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Add User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Available Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Manage Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Transfer Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

Add Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Manage Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Departments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

Add Department . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

Manage Departments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Add Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Manage Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Server Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Add Server Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Manage Server Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

Add Logon Event Alert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

Add Transfer Event Alert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Add Transfer Non-Event Alert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Manage Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

Manage DNI Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

Connection Manager Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

Add Connection Manager Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

Manage Connection Manager Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Manage Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Collection Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Collection Service Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

Configure Collection Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Scheduler Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

Scheduler Service Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3


Configure Scheduler Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Status Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Status Service Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Configure Status Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

JMS Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

JMS Service Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Configure JMS Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

Platform Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Add/Execute Platform Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

Manage Platform Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Manage Platform Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Add Platform Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Manage Platform Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Add Platform User Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

Manage Platform User Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

Add Platform Responder Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Manage Platform Responder Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Add Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Manage Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63

View Active Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Add Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Manage Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Global Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Password Reset and Self Registration Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Global Password Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Transfer Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Local Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Global Lockout Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Global PGP Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Global FTP Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Global SSH Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71

Global HTTPS Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Global Platform Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

File Share . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4


Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72

Archive Server Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Platform Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Platform Server Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Configure Platform Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Protocol Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Add Public Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Create System Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Kerberos KeyTabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Import KeyTab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Manage KeyTabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Trusted Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

Add Trusted Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

Manage Trusted Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80

PGP Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

PGP Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Add PGP Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Manage PGP Public Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

PGP System Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82

Create PGP Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Import SAML IDP MetaData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Configure SAML SP MetaData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84

Generate SAML SP MetaData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Active Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86

Internet Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Authenticators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Add Authenticator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Manage Authenticators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

LDAP Sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Manual Sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Scheduled Sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Automatic Sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97

Lockout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Lockout Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98

Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Search Audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5


Delete Audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100

Audit Search Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Add Audit Search Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Manage Audit Search Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

View Active Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101

Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Alert History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Search Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Delete Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104

Search Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Delete Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Server Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105

Database Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Adding Custom Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Error Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Search Error Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109

Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Delegated Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111

Administrative Functions and Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111

Active Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112

Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112

Audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Collector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Database Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Departments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114

FTP Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Platform Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Platform Responder Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Platform Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Platform User Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119

Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119

Server Credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .120

Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

6


Platform Server Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Platform Server Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123

Software Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Node Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Security Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Security Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

MFTCC Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

MFTCC Server Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

MFTCC Server Credential Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

MFTCC User ID and Password Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

User IDs and Passwords within Platform Server Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Extended Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Admin Client Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Calling Admin Client Utility from Platform Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131

Executing Admin Client Utility from Platform Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Executing Admin Client Utility as Platform Server Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132

Executing MFTCC Commands Using Platform Server for z/OS Batch Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Executing MFTCC Commands as Part of Platform Server for UNIX Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Executing Internet Server File Transfer as a Post Processing Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135

Configuring the Target MFTCC System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135

Configuring Windows Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Configuring UNIX Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Template Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137

MFTCC SOAP API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Using MFTCC Administrator Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Using MFTCC File Transfer Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Java Applet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Applet Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Required Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

Getting the Directory File List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Using Applet Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Class Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143

Directory Transfers Using Platform Transfer Client Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Directory Download Request Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Directory Upload Request Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Email Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Configuring MFTCC for Email Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Configuring Email Notification for Transfer Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Configuring Email Notification for File Transfer Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .149

7


Configuring Alert Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Email Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

File Availability Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Tokens Supported in the File Availability Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Transfer Completion Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Tokens Supported in Transfer Completion Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Alert Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Tokens Supported in the Alert Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

File Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159

Multi-Language Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159

Updating the Database Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Sample JMS XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

JMS XML Schema Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

XML Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

Using JMS XML Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

ID Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Appendix A. Connection Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Connection Manager Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .168

Connection Manager Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Performance Implications of Using Connection Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

Connection Manager High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171

Configuring High Availability Using the Administrator Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .172

Connection Manager Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Configuring Connection Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Adding Connection Manager Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Managing Connection Manager Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

Updating CMA Configuration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Updating CMS Configuration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Updating Internet Server Configuration Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

Connection Manager Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Firewall Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185

Connection Manager Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .186

CMS Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

CMS Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187

CMA Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

CMA Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .189

Internet Server Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Internet Server Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .190

Configuring Internal Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191

8


Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .191

Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

Appendix B. Configuring RADIUS Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193

Updating the Trace Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Defining RADIUS Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Sample web.xml RADIUS Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195

Setting the RADIUS Primary and Backup Secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196

Restarting the MFT Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Appendix C. web.xml Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

Security Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197

Miscellaneous Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Connectivity and Protocol Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

RADIUS Authentication Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

OEM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205

Database Driver Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Database Pooling Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

9


TIBCO Documentation and Support Services

Documentation for this and other TIBCO products is available on the TIBCO Documentation site. Thissite is updated more frequently than any documentation that might be included with the product. Toensure that you are accessing the latest available help topics, please visit:

https://docs.tibco.com

Product-Specific Documentation

Documentation for TIBCO products is not bundled with the software. Instead, it is available on theTIBCO Documentation site at https://docs.tibco.com/products/tibco-managed-file-transfer-command-center.

The following documents for this product can be found on the TIBCO Documentation site:

● TIBCO Managed File Transfer Command Center Installation

● TIBCO Managed File Transfer Command Center Quick Start Guide

● TIBCO Managed File Transfer Command Center User's Guide

● TIBCO Managed File Transfer Command Center Command Line Utilities Guide

● TIBCO Managed File Transfer Command Center API Guide

● TIBCO Managed File Transfer Command Center Release Notes

How to Contact TIBCO Support

For comments or problems with this manual or the software it addresses, contact TIBCO Support:

● For an overview of TIBCO Support, and information about getting started with TIBCO Support,visit this site:

http://www.tibco.com/services/support

● If you already have a valid maintenance or support contract, visit this site:

https://support.tibco.com

Entry to this site requires a user name and password. If you do not have a user name, you canrequest one.

How to Join TIBCOmmunity

TIBCOmmunity is an online destination for TIBCO customers, partners, and resident experts. It is aplace to share and access the collective experience of the TIBCO community. TIBCOmmunity offersforums, blogs, and access to a variety of resources. To register, go to the following web address:

https://www.tibcommunity.com

10


https://docs.tibco.com

https://docs.tibco.com/products/tibco-managed-file-transfer-command-center

https://docs.tibco.com/products/tibco-managed-file-transfer-command-center

http://www.tibco.com/services/support

https://support.tibco.com

https://www.tibcommunity.com

Product Overview

TIBCO® Managed File Transfer Command Center provides a single point of control to manage all ofyour enterprise file transfers, both inside and outside the enterprise and across all major platforms(from Windows to the mainframe). It serves as the digital dashboard into your entire network; using astandard web browser, administrators can review and control all file-transfer activities, whether theyare internal or external.

The following figure shows the MFTCC system:

MFTCC provides the following benefits:

● Centralized management

Browser-based, single-point-of-control for all enterprise file-transfer activities.

● Security

Complete data security and support for the world’s most stringent encryption standards.

● Full audit and reporting

A full suite of online inquiry tools for powerful audit and reporting functionality.

● Delegated administration

Users empowered based on their role within the organization.

● High availability and clustering

Support for clustering for failover and reliability.

● Real-time alerts

Messages and alerts sent via phone, email, or mobile device.

In TIBCO Managed File Transfer (MFT) Command Center documentation set, MFTCC is used torepresent TIBCO MFT Command Center.

11


Administrator Browser Configuration

You can configure MFTCC for use through the Administrator web pages.

Accessing the Administrator BrowserAfter installing and configuring MFTCC, you can access the Administrator web pages.

Procedure

1. Use the following URL to log in by substituting the areas of the URL with your installconfigurations:https://[DNS_HostName]:[httpsPort]/cfcc/control?view=view/admin/start.jsp

Where, the application server is the embedded server and the default port is 8443.

2. Input the administrator default user name and password, admin and changeit, when you areprompted for a user ID and password.

3. Click Sign on and the MFTCC main web page is displayed, as follows.

UsersYou can define and manage users, transfer groups, and transfer departments through the Users option.

Add UserYou can add user definitions to the MFTCC database to allow these users to use MFTCC to transfer filesthrough the Add User page which can be accessed by clicking Users > Add User.

To add a user, you must have AdministratorRight or UpdateTransferUserRight.

The following figure shows the Add User page:

12


You can add a user by using the Add From Existing User link at the top of this page. Five templateusers are automatically added into the database during the MFTCC installation process. After clickingthe Add From Existing User link, a list of those predefined users are displayed. You can click thedesired user ID to copy the predefined user definition to a new user definition. The new user definitionhas the same available rights and contain the same Optional User Properties settings of the userdefinition that is selected. The only thing left to do is to create a unique user ID, input the full name,and create a password for the user. After finishing the configuration, click Add to add the new user tothe database. You can edit any of the predefined user definitions before clicking Add. As new userdefinitions are added, more template user definitions are available to choose from.

The following table lists the template users that are automatically added during the installation processwith their assigned rights:

13


Template User ID Assigned Rights

admin AdministratorRight

TransferRight

ArchiveUser No rights assigned.

AS2TraceUser No rights assigned.

AuditorUser ViewAlertRight

ViewAuditRight

ViewGroupRight

ViewServerCredentialRight

ViewServerRight

ViewTransferDefinitionRight

ViewUserRight

Collector No rights assigned.

HelpDeskUser HelpDeskRight

UpdateSessionRight

ViewAlertRight

ViewAuditRight

ViewGroupRight

ViewUserRight

Scheduler DeleteAuditRight

ViewAuditRight

TransferUser TransferRight

Collector and ArchiveUser IDs are also added by default. These IDs are used to create servercredentials for servers that also have the collection and archive option turned on. No rights are given tothese IDs.

If you do not want to use any of the template user definitions available, you can create a new userdefinition manually by setting the parameters on the Add User page and then clicking Add.

The Add User page is divided into the following four sections:

Required User InformationDefines the fields that are required to create a user record.

Authentication OptionsDefines a user's client authentication method for FTP, SSH, HTTPS, and Platform Server clientconnections. These settings override the global settings found in the system configurations. Use theCertificate DN field when trusted certificates are being added by Administration > Protocol Keys >Trusted Certificates > Add Trusted Certificate.

14


Optional User PropertiesDefines a variety of parameters that are not required.

PGP InformationDefines the PGP settings that can be configured for the user.

15


By default, the Allow User to Add PGP Key parameter is set to Default and the systemconfigurations are used. For more information of system configurations, see System Configuration. Bysetting the Allow User to Add PGP Key parameter to Yes, you allow the user to add PGP public keysto the MFTCC database.

For detailed description of each field available to be configured on this page, see the online help page.

Available Rights

In total, 39 rights can be assigned to an MFTCC user.

The following table lists the rights along with a description of what each right is for and how it workswhen using and not using delegated administration (departments):

Right DescriptionDescription for Using DelegatedAdministration

AdministratorRight

With this right, you can perform alladministrative functions within theMFTCC system.

This right does not includeTransferRight or FTTransferRight orany functions that correspond to theserights.

With this right, you can perform alladministrative functions within yourdepartment and within the departmentsthat you can manage.

The departments that adepartment administrator canmanage are defined in theManage Department field inthe Optional User Propertiessection in the user definition.

This right does not include TransferRightor FTTransferRight or any functions thatcorrespond to these rights. Departmentadministrators cannot update server orserver credentials unless givenUpdateServerRight andUpdateServerCredentialRight.

DBReportRight With this right, you can log in, view,and generate MFTCC databasereports through the Reports >Database Reports option.

With this right, you can log in, view, andgenerate MFTCC database reportsthrough the Reports > Database Reportsoption.

DeleteAuditRight

With this right, you can delete auditrecords.

With this right, you can delete auditrecords. Department checking will notbe done.

FTAdminRight With this right, you can view andupdate menu items through theManagement > Platform Transfersoption; however, you cannot executePlatform transfers.

If this right is assigned along withViewServerRight, you can also viewand update all the items in theManagement > Manage PlatformFunctions option.

With this right, you can view and updatemenu items from the Management >Platform Transfers option; however, youcannot execute Platform transfers.

If this right is assigned along withViewServerRight, you can also view andupdate all the items in the Management> Manage Platform Functions option.

16



FTTransferRight

With this right, you can view andexecute menu items from theManagement > Platform Transfersoption; however, you cannot updatePlatform transfers.

With this right, you can view andexecute menu items from theManagement > Platform Transfersoption; however, you cannot updatePlatform transfers.

HelpDeskRight With this right, you can changeanother user’s password, turn on andoff the disable flag for a user, and turnon and off the lock flag for a user.

With this right, you can change anotheruser’s password, turn on and off thedisable flag for a user, and turn on andoff the lock flag for a user.

OnDemandTransferRight

With this right, you can use theDesktop Client Site Manager to set upand conduct on-demand transfers.

With this right, you can use the DesktopClient Site Manager to set up andconduct on-demand transfers.

TransferRight With this right, you can execute MFTInternet transfers.

With this right, you can execute MFTInternet transfers.

UpdateAlertRight

With this right, you can update alertrecords and view alerts occurred.

With this right, you can update alertrecords and view alerts occurred.

UpdateCheckpointRight

With this right, you can access theMFT Internet Checkpoints page anddelete checkpoints taken.

With this right, you can access the MFTInternet Checkpoints page and deletecheckpoints taken for your department.

UpdateFTTransferRight

With this right, you can updatePlatform transfers defined underManagement > Platform Transfers >Manage Platform Transfers;however, you cannot execute Platformtransfers.

With this right, you can update Platformtransfers defined under Management >Platform Transfers > Manage PlatformTransfers; however, you cannot executePlatform transfers.

UpdateGroupRight

With this right, you can view andupdate MFT group records.

With this right, you can view and updateMFT group records.

UpdateOnDemandRight

With this right, you can add orremove on-demand sites.

With this right, you can add or removeon-demand sites assigned to other userswithin your department.

UpdatePGPKeyRight

With this right, you can add andmanage the configurations of PGPpublic keys.

With this right, you can add and managethe configurations of PGP public keys.

UpdatePGPSystemKeyRight

With this right, you can add andmanage the configurations of PGPsystem keys.

With this right, you can add and managethe configurations of PGP system keys.

UpdatePublicKeyRight

With this right, you can add andmanage the configurations of FTPS,SFTP, Platform Server, and HTTPSpublic keys.

With this right, you can add and managethe configurations of FTPS, SFTP,Platform Server, and HTTPS public keys.

17



UpdateSchedulerRight

With this right, you can add andmanage scheduled transactions.

With this right, you can add and managescheduled transactions.

UpdateServerCredentialRight

With this right, you can view orupdate MFT server credential records.

With this right, you can view or updateMFT server credential records.

UpdateServerRight

With this right, you can view orupdate MFT server records.

With this right, you can view or updateMFT server records in your owndepartment; however, you cannot addnew servers.

UpdateSessionRight

With this right, you can view anddelete active user sessions.

With this right, you can view and deleteactive user sessions.

UpdateSystemKeyRight

With this right, you can add andmanage the configurations of AS2,FTP, SFTP, Platform Server SSL, HTTP,and SAML system keys through theAdministration > Protocol Keys >System Keys option, and manageKeyTab files through theAdministration > Protocol Keys >Kerberos KeyTabs option.

With this right, you can add and managethe configurations of AS2, FTP, SFTP,Platform Server SSL, HTTP, and SAMLsystem keys through the Administration> Protocol Keys > System Keys option,and manage KeyTab files through theAdministration > Protocol Keys >Kerberos KeyTabs option.

UpdateTransferDefinitionRight

With this right, you can view andupdate MFT Internet transferdefinitions.

With this right, you can view and updateMFT Internet transfer definitions.

UpdateTransferUserRight

With this right, you can view andupdate MFT user records.

You can only assign TransferRightand OnDemandTransferRight to auser unless you are an administrator.Super administrators can assign anyright to a user.

When assigning this rightto a user, you must alsoassign eitherViewGroupRight orUpdateGroupRight to theuser.

With this right, you can view and updateMFT user records.

Unless you are an administrator, you canonly assign TransferRight andOnDemandTransferRight to a user.Department administrators can assignany rights to a user within theirdepartments or within the departmentsthat they can manage exceptUpdateServerRight andUpdateServerCredentialRight.

The departments that adepartment administrator canmanage are defined in theManage Department field inthe Optional User Propertiessection in the user definition.

When assigning this right to a user, youmust also assign either ViewGroupRightor UpdateGroupRight to the user.

18



ViewAlertRight

With this right, you can view alertrecords and view alerts occurred.

With this right, you can view alertrecords and view alerts occurred.

ViewAuditRight

With this right, you can view auditrecords and update the audit searchfilter.

With this right, you can view auditrecords and update the audit searchfilter.

ViewCheckpointRight

With this right, you can access theMFT Internet Checkpoints page andview checkpoints taken.

With this right, you can access the MFTInternet Checkpoints page and viewcheckpoints taken for your department.

ViewFTTransferRight

With this right, you can view Platformtransfers defined under Management> Platform Transfers > ManagePlatform Transfers; however, youcannot add, update, or executePlatform transfers.

With this right, you can view Platformtransfers defined under Management >Platform Transfers > Manage PlatformTransfers for your department; however,you cannot add, update, or executePlatform transfers.

ViewGroupRight

With this right, you can view MFTgroup records.

With this right, you can view MFT grouprecords.

ViewOnDemandRight

With this right, you can view MFT on-demand site records.

With this right, you can view MFT on-demand site records.

ViewPGPKeyRight

With this right, you can view PGPpublic keys.

With this right, you can view PGP publickeys.

ViewPublicKeyRight

With this right, you can view MFTFTP, SSH, and HTTPS public keys.

With this right, you can view MFT FTP,SSH, and HTTPS public keys.

ViewSchedulerRight

With this right, you can viewscheduled transactions.

With this right, you can view thescheduled transactions for yourdepartment.


With this right, you can view MFTserver profile records.

With this right, you can view MFT serverprofile records.

ViewServerRight

With this right, you can view MFTserver records.

With this right, you can view MFT serverrecords.

ViewSessionRight

With this right, you can view activeuser sessions.

With this right, you can view active usersessions.


With this right, you can view MFTInternet transfer records.

With this right, you can view MFTInternet transfer records.

ViewUserRight With this right, you can view MFTuser records and the rights associatedwith those users.

With this right, you can view MFT userrecords and the rights associated withthose users.

19


Manage UsersYou can list, search, update, and delete users through the Manage Users page which can be accessed byclicking Users > Manage Users.

To manage user definitions, you must have AdministratorRight or UpdateTransferUserRight.

The following figure shows the Manage Users page with the eight template users (see Add User fordetails of the template users) that are automatically added into the database during the installationprocess:

This page can contain a list of the first 100 defined users. If more than 100 users are defined, you canclick List Next 100 > to access the next 100 user definitions. You can click Back to see the previousdefinitions.

You can set selection criteria (any combination of the User Id, Full Name, Assigned Right, Group, andDepartment fields) in the Selection Criteria section on this page to display a list of particular users. Thepercent sign (%) can be used as a wildcard character.

To update a user definition, click the user ID of the user definition that you want to change; makenecessary changes and click Update to update the definition.

To delete a user definition, select the check box next to the user that you want to delete and click Delete.Multiple user definitions can be deleted at one time.

You can use the Navigation box on the left of the page to refresh the Manage Users list.

20


Transfer GroupsYou can add and manage transfer groups through the Users > Transfer Groups option.

Add Group

You can add new groups to the MFTCC system through the Add Group page which can be accessed byclicking Users > Transfer Groups > Add Group.

To add a group, you must have AdministratorRight or UpdateGroupRight.

The following figure shows the Add Group page:

This page is divided into the following two sections:

Required Group InformationDefines fields that must be entered to create a group.

Assign User to GroupDefines which users will be in the defined group.


21


Manage Groups

You can update or delete a group definition through the Manage Groups page which can be accessedby clicking Users > Transfer Groups > Manage Groups.

To manage group definitions, you must have AdministratorRight or UpdateGroupRight.

The following figure shows the Manage Groups page with six sample groups that are created and canbe managed:

This page can contain a list of the first 100 defined groups. If more than 100 groups are defined, you canclick List Next 100 > to access the next 100 group definitions. You can click Back to see the previousdefinitions.

To update a definition, click the group ID of the group definition that you want to change; makenecessary changes and click Update to update the definition.

To delete a group definition, select the check box next to the group that you want to delete and clickDelete. Multiple group definitions can be deleted at one time.

You can use the Navigation box on the left of the page to refresh the Manage Groups list.

DepartmentsYou can add and manage departments through the Users > Departments option.

For more information of how to use departments, see Delegated Administration.

Add Department

You can add new departments to the MFTCC system through the Add Department page which can beaccessed by clicking Users > Departments > Add Department.

Departments can only be added by an administrator who has access to the entire MFTCC system. Thisadministrator is not assigned to any department and is known as a super administrator. This feature isused for delegated administration (for more information, see Delegated Administration).

The following figure shows the Add Department page:

22


This page only contains a single section, Required Department Information, which defines fields thatmust be defined to create a department.


Manage Departments

You can update or delete a department in the MFTCC system through the Manage Departments pagewhich can be accessed by clicking Users > Departments > Manage Departments.

To manage departments, you must have AdministratorRight.

The following figure shows the Manage Departments page with six departments that are created andcan be managed:

This page can contain a list of the first 100 defined departments. If more than 100 departments aredefined, you can click List Next 100 > to access the next 100 department definitions. You can click Backto see the previous definitions.

To update a department definition, click the department name of the department definition that youwant to change; make necessary changes and click Update to update the definition.

To delete a department definition, select the check box next to the department that you want to deleteand click Delete. Multiple department definitions can be deleted at one time.

You can use the Navigation box on the left of this page to refresh the Manage Departments list.

23


ServersTIBCO MFT Command Center can communicate with TIBCO® Managed File Transfer Platform Servers.The server definition defines how the client can gain access to a file. You can add and manage serverdefinitions in TIBCO MFT Command Center through the Servers option.

Add ServerYou can add remote servers to MFTCC system through the Add Server page which can be accessed byclicking Servers > Add Server.

To add a server, you must have AdministratorRight or UpdateServerRight.

The following figure shows the Add Server page:

24


You can create a new server definition manually by setting the parameters on the Add Server page andthen clicking Add.

The Add Server page is divided into the following eleven sections:

Required Server InformationDefines the required parameters to create a server record.

When defining FTP or SFTP servers located on Windows, specify UNIX because most FTP and SFTPservers use UNIX format commands. FTP server on IBM iSeries is not supported.

Platform Server OptionsDefines server options that are used only when the Server Type field in the Required Server Definitionsection is defined as Platform Server.

FTP OptionsDefines server options that are used only when the Server Type field in the Required Server Definitionsection is defined as FTP.

SSH OptionsDefines server options that are used only when the Server Type field in the Required Server Definitionsection is defined as SSH.

25


HTTP OptionsDefines server options that are used only when the Server Type field in the Required Server Definitionsection is defined as HTTP.

AS2 OptionsDefines server options that are used only when the Server Type field in the Required Server Definitionsection is defined as AS2.

26


HDFS OptionsDefines server options that are used only when the Server Type field in the Required Server Definitionsection is defined as HDFS.

When the Authentication field is set to Simple, the parameter required for performing simpleauthentication to the remote HDFS server is displayed.

When the Authentication filed is set to Kerberos, parameters required for performing Kerberosauthentication to the remote HDFS server are displayed.

27


Internet Server OptionsDefines the Internet Server context when the Server Type field in the Required Server Definitionsection is defined as Internet Server. You must indicate whether the port being defined for theInternet Server is a secure port (that is HTTPS) or not.

Server OptionsPredefines a default path that file uploads and downloads will use. This can be very helpful whendefining transfer definitions. For example, you can define a path in this section and then in the transferdefinition, you can define file name tokens without defining a path in the Server File Name field.

This field cannot be overridden.

Server CredentialsDefines a default user ID and password to be used for this server. These credentials are used fortransfers and Platform Server audit collection purposes (for more information about collectingPlatform Server audits, see Collection Service).

These credentials can be overridden for transfers from a transfer definition or a Platform Servertransfer definition.

Additional Server PropertiesDefines parameters specific for this server, such as department, description, and trace level.

28


Management OptionsThis section contains two subsections. In the Management Option for All Servers subsection, you canuse the Check Server Status parameter to define whether MFTCC monitors whether the port definedfor the server being added to the system (the Status service must be configured to use this service) isin good connection.

The Platform Server Management Option subsection is used when the Server Type field in theRequired Server Definition section is defined as Platform Server. If you want to collect PlatformServer audit records, select the Manage Platform Server check box; then set the Collect PlatformServer History, Collection Interval, and Collect History fields. After setting these fields, you areprompted to restart the Collection service if you have it running already. For more information aboutcollecting audit logs from a Platform Server, see Collection Service. If you want to manage DNI(Directory Named Initiation) from the MFTCC DNI port, you must define the DNI Management Userid and DNI Management Password fields. TIBCO MFT Command Center and TIBCO® Managed FileTransfer Internet Server both distribute the DNI perl programs, templates, and instruction manualwithin the dni.tar file located in the following installation directory: <MFT_Install>\distribution\dni. To extract the files from the dni.tar file, issue the following command from your commandprompt: tar –xvf dni.tar.

PGP InformationDefines the PGP Information that can be associated with a server.

29


If the server being defined will be used to conduct file transfers with PGP encrypted files, you mustdefine the PGP keys that will be used to encrypt (file uploads) or decrypt (file downloads) files. ThePGP keys can either be generated by MFTCC or imported into the system by an administrator throughthe TIBCO MFT Command Center or TIBCO Managed File Transfer (MFT) Internet ServerAdministrator web pages or by an end user through the Browser client. For more information aboutthe Browser client, see TIBCO Managed File Transfer Internet Server Client User's Guide.


Manage ServersYou can list, update, and delete Platform Servers defined to the MFTCC system through the ManageServers page which can be accessed by clicking Servers > Manage Servers.

To manage server definitions, you must have AdministratorRight or UpdateServerRight.

The following figure shows the Manage Servers page with five servers (*LOCAL is set by default) thatare added to MFTCC:

30


You can search the server database to limit the number of server definitions displayed in the Resultstable by setting the selection criteria in the Selection Criteria section. The following figure shows theSelection Criteria section.

The percent sign (%) can be used as a wildcard character to simplify the search. If multiple fields havesearch criteria defined, a record is only returned when it matches all the search criteria defined. Whenyou finishing defining the selection criteria, click Search to search and create the Results table.

By default, the Results table displays all the servers you have defined in the system; if you defineselection criteria in the Selection Criteria section, the Results table displays the servers that match thedefined selection criteria.

You can click an entry in the Server Name column in the Results table to view detailed information ofthat server definition on the opened Update Server page. You can modify the parameter settings andthen click Update to update this server definition if you are authorized.

To delete a server definition, select the check box next to the server that you want to delete and clickDelete. Multiple server definitions can be deleted at one time.

You can use the Navigation box on the left of the page to refresh the Manage Servers list.

Server CredentialsYou can add and manage server credentials for servers defined in the MFTCC system through theServers > Server Credentials option.

To add and manage server credentials, you must have AdministratorRight orUpdateServerCredentialRight.

Add Server Credentials

You can add server credentials for servers defined in the MFTCC system through the Add ServerCredentials page which can be accessed by clicking Servers > Server Credentials > Add ServerCredentials.

To add server credentials, you must have AdministratorRight or UpdateServerCredentialRight.

The following figure shows the Add Server Credentials page:

31


You can create a new server credential definition manually by setting the parameters in the Add ServerCredentials page and then clicking Add.

The Add Server Credentials page contains the following two sections:

Required Server Credential InformationDefines the most important parameters needed to create a server credential record.

Windows PropertiesDefines a Windows domain for the server credentials being added.


When the system checks server credentials, it first checks the user ID and then checks the group ID. Ifthe user is not found in any defined server credentials, the server credentials defined in the serverdefinition are used.

Upon login, the remote Platform Server authentication validates that the Remote user ID is one of thefollowing options:

● The administrator

● Part of the local administrator group

● Part of the cfadmin or cfbrowse group depending on the action being attempted

Manage Server Credentials

You can list, update, and delete server credentials defined to the MFTCC system through the ManageServer Credentials page which can be accessed by clicking Servers > Server Credentials > ManageServer Credentials.

To manage server credentials, you must have AdministratorRight or UpdateServerCredentialRight.

The following figure shows the Manage Server Credentials page with three server credentials that areadded and can be managed from this page:

32


This page can contain a list of the first 100 defined server credentials. If more than 100 server credentialsare defined, you can click List Next 100 > to access the next 100 server credential definitions. You canclick Back to see the previous definitions.

You can limit the number of server credential definitions displayed in the Results table by settingselection criteria in the Selection Criteria section. You can define selection criteria by any combination ofthe Id Type, Id Name, Server Name, Remote User Id, and Remote User Windows Domain fields. Thepercent sign (%) can be used as a wildcard character.

To update a server credential definition, click the ID type of the server credential definition that youwant to change; make necessary changes and click Update to update the definition.

To delete a server credential definition, select the check box next to the server credential definition thatyou want to delete and click Delete. Multiple server credential definitions can be deleted at one time.

You can use the Navigation box on the left of the page to refresh the Manage Server Credentials list.

ManagementYou can manage MFTCC alerts, DNI daemons, Connection Manager nodes, services, Platform transfers,and Platform functions through the Management option.

AlertsYou can add and manage logon event alerts, transfer event alerts, and transfer non-event alerts throughthe Management > Alerts option.

To add and manage alert definitions, you must have AdministratorRight or UpdateAlertRight. Onlysuper administrators can add or update alerts that are associated with Run Command or Run JavaClass alert action. This means if such an alert is created by an older version of MFTCC for adepartment, when the department administrator tries to look at it, an error You are not authorizedto update alert with run command or run java class is displayed. This is expected. If the superadministrator removes the actions, the department administrator can manage the alert.

MFTCC alerts supports you to perform specific actions when a logon to the TIBCO MFT CommandCenter or TIBCO MFT Internet Server occurs, an Internet transfer or Platform transfer occurs, or theInternet transfer or Platform transfer does not occur (non-event transfer).

Internet transfers generate audit records after each file transfer; Platform transfers generate auditrecords locally, and these records are retrieved from the Platform Servers via the MFTCC Collector. Foreach audit record, the alert server examines the audit record information against the alert triggercriteria defined. If the audit information matches the alert trigger criteria, the actions defined for thealert are executed.

An alert log file is created within the MFTCC <MFT_Install>/logs/audit directory created during theinstallation process. This file lists each alert that is generated and the action taken.

33


Add Logon Event Alert

Logon event alerts support you to perform an action when a user logs onto the system. You can addlogon event alert definitions to the MFTCC system through the Add Logon Event Alert page which canbe accessed by clicking Management > Alerts > Add Logon Event Alert.

To add alert definitions, you must have AdministratorRight or UpdateAlertRight.

The following figure shows the Add Logon Event Alert page:

Logon event alerts are triggered based on the alert trigger criteria defined in the Alert Trigger Criteriasection on this page. Logon alerts are triggered by a logon to TIBCO MFT Command Center and/orTIBCO MFT Internet Server and certain trigger criteria defined. Up to five different alert actions asshown in the following list can be triggered based on the alert trigger criteria; at least one must be used.More than one alert action can be triggered for the same transfer.

● Email: sends an email. The default email template to use is email-alertlogon-notification-template.xml.

● SNMP Trap: sends an SNMP trap.

● Execute Command: executes a command locally on TIBCO MFT Command Center or remotely onTIBCO Managed File Transfer (MFT) Platform Server.

● Execute Java Class: executes a JAVA class.

34


● JMS: sends a notification to a JMS topic.

Add Transfer Event Alert

Transfer event alerts support you to perform an action based on the completion of a file transfer requestin the system. You can add logon event alert definitions to the MFTCC system through the AddTransfer Event Alert page which can be accessed by clicking Management > Alerts > Add TransferEvent Alert.


The following figure shows the Add Transfer Event Alert page:

Transfer event alerts are triggered based on the alert trigger criteria defined in the Alert Trigger Criteriasection on this page. Alerts can be triggered for Internet Server transfers or for Platform Servertransfers. Alerts are triggered for Platform Server transfers only when the Collection service is turnedon. Up to five different alert actions as shown in the following list can be triggered based on the alerttrigger criteria; at least one must be used. More than one alert can be triggered for the same transfer.

● Email: sends an email. The default email template to use is email-alert-notification-template.xml.


● Execute Command: executes a command locally on TIBCO MFT Command Center or remotely onTIBCO MFT Platform Server.

35




Add Transfer Non-Event Alert

Transfer non-event alerts support you to perform an action when a file transfer is not completedsuccessfully in a defined time window. You can add transfer non-event alert definitions to the MFTCCsystem through the Add Non Event Alert page which can be accessed by clicking Management >Alerts > Add Transfer Non-Event Alert.


The following figure shows the Add Transfer Non-Event Alert page:

Transfer non-event alerts are triggered based on the alert trigger criteria defined in the Alert TriggerCriteria section on this page. Transfer non-event alerts can be triggered for Internet Server transfers orfor Platform Server transfers. Up to five different alert actions as shown in the following list can betriggered based on the alert trigger criteria; at least one must be used. More than one alert can betriggered for the same transfer.

● Email: sends an email. The default email template to use is email-alertnonevent-notification-template.xml.


36


● Execute Command: executes a command locally on TIBCO MFT Command Center or remotely onTIBCO MFT Platform Server.



Manage Alerts

You can list and update Internet Server alerts through the Manage Alerts page which can be accessedby clicking Management > Alerts > Manage Alerts.

To manage alert definitions, you must have AdministratorRight or UpdateAlertRight.

The Manage Alerts page can contain a list of the first 100 defined alert definitions. If more than 100 alertdefinitions are defined, you can click List Next 100 > to access the next 100 alert definitions. You canclick Back to see the previous definitions.

You can limit the number of alert definitions displayed in the Results table by setting selection criteriain the Selection Criteria section. You can define selection criteria by any combination of parameters inthis section. The percent sign (%) can be used as a wildcard character.

To update an alert definition, click the alert ID of the alert definition that you want to change; makenecessary changes and click Update to update the definition.

To delete an alert definition, select the check box next to the alert definition that you want to delete andclick Delete. Multiple alert definitions can be deleted at one time.

You can use the Navigation box on the left of the page to refresh the Manage Alerts list.

Manage DNI DaemonsYou can list, start, stop, add, update, or delete DNI (Directory Named Initiation) templates defined forthe selected daemon, or list, view, or delete DNI template log files through the Manage DNI Daemonspage which can be accessed by clicking Management > Manage DNI Daemons.

To manage DNI daemons, you must have AdministratorRight or UpdateServerRight.

The following figure shows the Manage DNI Daemons page with two DNI daemons defined:

Connection Manager NodesYou can create and manage Connection Manager nodes to the MFTCC system through theManagement > Connection Manager Nodes option. Connection Manager supports DMZ serverinstances to create connections to servers in the internal network without opening the connection fromthe DMZ; all connections are opened from the internal network.

The following three types of Connection Manager nodes can be added to the system:

● CMS (Connection Manager Server): CMS executes in the internal network. It connects to CMA(Connection Manager Agent) nodes in the DMZ and waits for CMA to request sessions.

37


● CMA: CMA executes in the DMZ. It waits for a control connection from CMS; it then sendsconnection requests to CMS over the control connection.

● Internet Server: Internet Server instances execute in the DMZ. They request sessions through CMA.

For more information of how the Connection Manager nodes work, see Appendix A. ConnectionManager.

Add Connection Manager Node

You can create Connection Manager nodes and define the information used by MFTCC to connect toConnection Manager nodes through the Add Connection Manager Node page which can be accessedby clicking Management > Connection Manager Nodes > Add Connection Manager Node.

You can create a Connection Manager node manually by setting the fields in the Connection ManagerNode Information section and then clicking Add.

The following table lists the fields on this page:

Parameters Description

Name Defines the name of the Connection Manager node.

Description Defines descriptive information for the Connection Manager node.

Type Defines the Connection Manager node type.

Three types of Connection Manager nodes are supported:

● CMS: Connection Manager Server

● CMA: Connection Manager Agent

● Internet Server: when Internet Server is selected, a drop-down listis displayed to the right. You can select a predefined Internet Server fromthe drop-down list. If selected, the configuration information for thatserver is added to this page.

IP Address or FullyQualified DNSName

Defines the IP address or DNS name of the Connection Manager node.

IP Port Defines the HTTPS IP port that the Connection Manager node is listening on.

When you select a Connection Manager node in the Type field, this field isfilled in with the default port used by that node type. This port should beused unless the default ports are changed.

Password Used forManaging thisNode

Defines the password to be used by MFTCC and validated by the ConnectionManager node when configuring the node.

This password is set during the installation of CMA, CMS, or Internet Server.

Confirm Password Confirms the password entered in the Password Used for Managing thisNode field.

Manage Connection Manager Nodes

You can lists the Connection Manager nodes that are created and select a Connection Manager node toview or update through the Manage Connection Manager Nodes page which can be accessed by

38


clicking Management > Connection Manager Nodes > Manage Connection Manager Nodes. All of thedefined Connection Manager nodes are displayed in the Results Table.

To update a Connection Manager node definition, click the node name of the Connection Manager nodedefinition that you want to change; make necessary changes and click Update to update the definition.

To delete a Connection Manager node definition, select the check box next to the Connection Managernode definition that you want to delete and click Delete. Multiple Connection Manager nodedefinitions can be deleted at one time.

Manage ServicesYou can view the status of and configure the Collection service, Scheduler service, Status service, andJMS service through the Management > Manage Services option.

You can mange the following services:

● Collection Service: pulls logs from remote Platform Server at a given interval of time.

● Scheduler Service: executes the scheduled jobs.

● Status Service: verifies whether a remote system is listening for requests.

● JMS Service: sends and receives JMS message to the configured JMS server.

Collection Service

The Collector is responsible for contacting TIBCO MFT Platform Server to retrieve audit information onall completed transfers. You can view the status of the Collection service and configure the Collectionservice through the Management > Manage Services > Collection Service option.

To manage the Collection service, you must be a super administrator (has AdministratorRight and isnot a member of a department).

Collection Service Status

You can view the current status of the Collection service, update the Collection service status, and startor stop the Collection service through the Collection Service Status page which can be accessed byclicking Management > Manage Services > Collection Service > Collection Service Status.

The following figure shows the Collection Service Status page:

When you add a Platform Server to your server definitions in MFTCC and you select the ManagePlatform Server check box in the Management Options section on the Add Server page (for moreinformation, see Add Server), you have to set the Collect Platform Server History, Collection Interval,and Collect History fields to allow the audit records to be pulled from the Platform Server when theCollector runs.

39


Configure Collection Service

You can enable or disable the Collection service, set the Collection server host name, and set the defaultcollection interval through the Configure Collection Service page which can be accessed by clickingManagement > Manage Services > Collection Service > Configure Collection Service.

The following figure shows the Configure Collection Service page:

The Collection service will be run on the host name selected from the Collector Server Host Namedrop-down list.

Scheduler Service

You can view the status of the Scheduler service and configure the Scheduler service through theManagement > Manage Services > Scheduler Service option.

Scheduler Service Status

You can view the current status of the Scheduler service, update the status of the Scheduler service, andhold, start, and stop the Scheduler service through the Scheduler Service Status page which can beaccessed by clicking Management > Manage Services > Scheduler Service > Scheduler Service Status.

The following figure shows the Scheduler Service Status page:

By default, the Scheduler service is on hold.

Configure Scheduler Service

You can configure the Scheduler service on each MFTCC instance through the Configure SchedulerService page which can be accessed by clicking Management > Manage Services > Scheduler Service >Configure Scheduler Service.

The following figure shows the Configure Scheduler Service page:

40


The Thread Pool parameter is set to 10 by default.

Status Service

The Status service supports you to configure time intervals for the Status service to check your thirdparty servers defined and verify they are listening on the port you have configured in the serverdefinition. You can view the status of the Status service and configure the Status service through theManagement > Manage Services > Status Service option.

To start, stop, or configure the Status service, you must have AdministratorRight.

You can use the Status service to log the following conditions:

● Unsuccessful connections

● Successful connections

● Both successful and unsuccessful connections

● None

The Status service log file is located in <MFT_Install>/logs/message directory. One log is generatedper day.

Status Service Status

You can view the current status of the Status service, update the status of the Status service, and start orstop the Status service through the Status Service Status page which can be accessed by clickingManagement > Manage Services > Status Service > Status Service Status.

Before starting the Status service, you must configure and enable the Status service (see ConfigureStatus Service for more details). To start, stop, or configure the Status service, you must haveAdministratorRight.

The following figure shows the Status Service Status page:

You can view the present status of your third party servers defined in MFTCC through the ServerStatus page which can be accessed by clicking Reports > Server Status. For more information, see Server Status.

41


To view the status of your third party servers, the Check Server Status field in the ManagementOptions section on the Add Server page must be set to Yes.

Configure Status Service

Before starting the Status service, you must configure and enable the Status service through theConfigure Status Service page which can be accessed by clicking Management > Manage Services >Status Service > Configure Status Service.

The following figure shows the Configure Status Service page:

For each MFTCC server that are defined in the database, you can see it listed in the Host Name field.

When the configuration for the Status service changes, click Update to update the service configuration.Any changes to this page require the Status service to be restarted.

JMS Service

You can configure the JMS (Java Message Service) service of MFTCC to allow alerts to be sent to a JMSserver, to perform inquiries on audit records, to send transfer notification requests to a JMS server, andto initiate file transfers between Platform Servers with JMS through the Management > ManageServices > JMS Service option.

The JMS service has been tested with a TIBCO EMS server, ActiveMQ, and IBM MQSeries. JMS serversother than those mentioned above might also work. If additional support beyond general assistance isneeded, professional services might be required.

JMS Service Status

You can view the current status of the JMS service, update the status of the JMS service, and start orstop the JMS service throught the JMS Service Status page which can be accessed by clickingManagement > Manage Services > JMS Service > JMS Service Status.

Before starting the JMS service, you must configure and enable the JMS service.

The following figure shows the JMS Service Status page:

42


Configure JMS Service

Before starting the JMS service, you must configure and enable the JMS service through the ConfigureJMS Service page which can be accessed by clicking Management > Manage Services > JMS Service >Configure JMS Service.

The following figure shows the Configure JMS Service page:

43


When the configurations for the JMS service changes, click Update to update the JMS serviceconfigurations. Any changes on this page require the JMS server to be restarted.

You can click Test to connect to the JMS server to verify that the connection parameters are valid andthat the defined queues and topics can be accessed.

When using the Test button, pay attention to the following points:

● To run the test successfully, the JMS jar files for the JMS server must be installed. After adding theJMS jar files to MFTCC, you must restart the system.

● Because ActiveMQ implements JNDI differently, new queues and topics are created automatically ifthey don’t exist; therefore, tests will be run successfully.

● If both TIBCO MFT Command Center and TIBCO MFT Internet Server are installed and share thesame database, multiple servers are available in the Select Server to Test drop-down list. TIBCOMFT Internet Server also requires the JMS jar files to be applied.

This page contains the following five sections:

44


Server PropertiesDefines the detailed JMS server connection information. This section must be defined to send andreceive messages from a JMS server.

Alert PropertiesDefines the JMS topic that will receive alert messages when an alert defined under the Management >Alerts option has an alert action set to sending a JMS message. For more information about settingalert actions, see Alerts.

Audit PropertiesDefines the JMS queue that will receive audit records.

Transfer Notification PropertiesDefines the JMS topic that will receive completion notifications when Platform Server transfer requestshave occurred.

For a notification message to be sent to a JMS topic for the completion of a Platform Server transfer,the Collection service must be running and either the Platform Server is configured to have auditrecords collected automatically or an Audit Manual Poll is running to collect the audit records fromthe Platform Server. For more information of the Collection service, see Collection Service.

When TIBCO MFT Internet Server is installed and share the same database as TIBCO MFT CommandCenter, start and end notifications can be sent to a JMS topic.

Transfer Request Properties

45


Defines the JMS queue from which the MFTCC JMS service reads XML files that can initiate PlatformServer transfers and Internet Server transfers if TIBCO MFT Internet Server is installed and shares thesame database as TIBCO MFT Command Center.

For more information of each field available to be configured on this page, see the online help page.

Platform TransfersMFTCC administrators can manage transfers being conducted on TIBCO MFT Platform Servers. Anadministrator can create, manage, and execute Platform to Platform transfers from MFTCC.

Users with FTAdminRight can view, add, and manage Platform transfers defined in the system.However, they cannot execute Platform transfers on demand (the Execute button is disabled).

Users with FTTransferRight can view the defined Platform transfers and execute them on demand.However, they cannot add Platform transfers to the system.

Users with UpdateFTTransferRight can view the Platform Transfers option, and add and managePlatform transfers. However, they cannot execute Platform transfers on demand (the Execute button isnot displayed).

Users with ViewFTTransferRight can only view Platform transfers defined in the system.

Add/Execute Platform Transfer

You can configure a Platform Server transfer request through the Add/Execute Platform Transfer pagewhich can be accessed by clicking Management > Platform Transfers > Add/Execute PlatformTransfer. This transfer request will be pushed out by TIBCO MFT Command Center to be initiated by aremote TIBCO MFT Platform Server.

You can add a transfer by using the Add From Existing Transfer link at the top of the Add/ExecutePlatform Transfer page. After clicking this link, the Add From Existing Transfer page is displayed. Clickthe desired transfer ID and all the values except the description and passwords that might be defined,are pulled into a new Platform Server transfer definition. From here, you can edit the settings and saveit to the database or execute it.

If you do not want to use any of the existing transfer definitions, you can create a new transferdefinition manually. After entering the necessary Platform Server transfer request settings, click Add tosave the transfer request to the MFTCC database and run it at a later time, or click Execute to executethe Platform Server transfer on demand without saving it to the database.

TIBCO MFT Platform Server supports PPA (post processing action) tokens in the Data field in the PostProcessing Action section when PPA is turned on for a transfer. With PPA tokens, TIBCO MFT Platform

46


Server users can add file transfer related parameters to the Data field. You can click the PPA Token Listlink at the right of the Data field to see a list of PPA tokens.

The Department field in the Required Transfer Information section is designed to limit Platform Servertransfer access to users in the specified department and users who can manage the specifieddepartment. The department is not saved in the Platform Server audit record and is not available foraudit records collected from Platform Server. For audit records collected by MFTCC, the departmentdefined in the server definition will be saved in the audit record.

For a detailed description for each field available to be configured on this page, see the online helppage.

Manage Platform Transfers

You can update or delete a predefined Platform Server transfer that you save in the MFTCC systemthrough the Manage Platform Transfers page which can be accessed by clicking Management >Platform Transfers > Manage Platform Transfers.

To update a transfer defined, click the transfer ID of the transfer definition that you want to change;make necessary changes and click Update.

To delete a transfer definition, select the check box next to the transfer definition that you want to deleteand click Delete. Multiple Platform Server transfer definitions can be deleted at one time.

Manage Platform FunctionsNode definitions are used by TIBCO MFT Platform Server to identify and define its file transferpartners. Node definitions provide security related settings and some default transfer values for fieldssuch as Default Encryption and Default Compression.

Add Platform Node

Nodes define the parameters necessary for the Platform Server to communicate with remote PlatformServers. You can add Platform Server nodes to the MFTCC database or distribute it to remote PlatformServers that are defined in MFTCC through the Add Platform Node page which can be accessed byclicking Management > Manage Platform Functions > Add Platform Node.

To add Platform nodes, you must have AdministratorRight or FTAdminRight.

The following figure shows the Add Platform Node page:

47


To add a Platform Server node to the database, set all the parameters required for the environment andclick Add. This node can be distributed to other Platform Servers defined to MFTCC at a later datethrough the Manage Platform Nodes page.

If you want to distribute this node configurations to a remote Platform Server that is set to be managedby MFTCC, expand the Server List section and select the Platform Server on which you want to havethis node be defined and then click Update Server. You can distribute a node to more than one remotePlatform Servers.

Manage Platform Nodes

Nodes define the parameters necessary for the Platform Server to communicate with remote PlatformServers. You can list, update, or delete Platform Server node entries through the Manage PlatformNodes page which can be accessed by clicking Management > Manage Platform Functions > ManagePlatform Nodes.

To manage Platform nodes, you must have AdministratorRight or FTAdminRight.

This page contains a list of Platform Server nodes added to the MFTCC database through the AddPlatform Node page. If no nodes are saved in the database, this table is empty.

To update a node definition, click the node name of the node definition that you want to change; makenecessary changes and click Update to update the definition.

To distribute a node configuration to a remote Platform Server that is set to be managed by MFTCC,expand the Server List section and select the Platform Server on which you want to have this node bedefined and then click Update Server. You can distribute a node to more than one remote PlatformServers.

If a Platform Server contains nodes that should be placed in the database, these nodes can be pulled infor future distribution by selecting the Platform Server from the Get Node From Server drop-down list.A list of nodes defined on that Platform Server are returned. You can click the node name to go to theAdd Platform Node page and follow the instructions in Add Platform Node to add the node to thedatabase.

48


The Platform Server in the list must be configured to be managed by MFTCC.

To delete a Platform Server node definition, select the check box next to the Platform Server nodedefinition that you want to delete and click Delete. Multiple Platform Server node definitions can bedeleted at one time.

Add Platform User Profile

User profiles define the parameters necessary for a Platform Server initiator to authenticate to aPlatform Server responder. You can add a Platform user profile to the database or distribute it to remotePlatform Servers that are defined in MFTCC through the Add Platform User Profile page which can beaccessed by clicking Management > Manage Platform Functions > Add Platform User Profile.

To add Platform user profile definitions, you must have AdministratorRight or FTAdminRight.

The following figure shows the Add Platform User Profile page:

To add a Platform user profile to the database, set all the parameters required for the environment andclick Add. This user profile can be distributed to other Platform Servers defined to MFTCC at a laterdate through the Manage Platform User Profiles page.

To distribute a profile configuration to a remote Platform Server that is set to be managed by MFTCC,expand the Server List section and select the Platform Server on which you want to have this profile bedefined and then click Update Server. You can distribute a user profile to more than one remotePlatform Servers.

Manage Platform User Profiles

User profiles define the parameters necessary for a Platform Server initiator to authenticate to aPlatform Server responder. You can list, update, or delete Platform user profiles through the Manage

49


Platform User Profiles page which can be accessed by clicking Management > Manage PlatformFunctions > Manage Platform User Profiles.

To manage Platform user profile definitions, you must have AdministratorRight or FTAdminRight.

This page contains a list of Platform user profiles added to the MFTCC database through the AddPlatform User Profile page. If no user profiles are saved in the database, this table is empty.

To update a user profile definition, click the profile ID of the user profile definition that you want tochange; make necessary changes and click Update to update the definition.

To distribute a user profile configuration to a remote Platform Server that is set to be managed byMFTCC, expand the Server List section and select the Platform Server on which you want to have thisprofile be defined and then click Update Server. You can distribute a user profile to more than oneremote Platform Servers.

If a Platform Server contains user profiles that should be placed in the database, these user profiles canbe pulled in for future distribution by selecting the Platform Server from the Get Profile From Serverdrop-down list. A list of user profiles defined on that Platform Server are returned. You can click theprofile ID to go to the Add Platform User Profile page and follow the instructions in Add Platform UserProfile to add the profile to the database.


To delete a Platform user profile definition, select the check box next to the Platform user profile thatyou want to delete and click Delete. Multiple Platform user profiles can be deleted at one time.

Add Platform Responder Profile

Responder profiles define the parameters necessary for the Platform Server responder to authenticatethe user ID and password passed by the Platform Server initiator. You can add Platform Serverresponder profiles to the database or distribute it to remote Platform Servers that are defined in MFTCCthrough the Add Platform Responder Profile page which can be accessed by clicking Management >Manage Platform Functions > Add Platform Responder Profile.

To add Platform responder profile definitions, you must have AdministratorRight or FTAdminRight.

The following figure shows the Add Platform Responder Profile page:

50


To add a Platform responder profile to the database, set all the parameters required for the environmentand click Add. This responder profile can be distributed to other Platform Servers defined to MFTCC ata later date through the Manage Platform Responder Profiles page.

To distribute a profile configurations to a remote Platform Server that is set to be managed by MFTCC,expand the Server List section and select the Platform Server on which you want to have this profile bedefined and then click Update Server. You can distribute a responder profile to more than one remotePlatform Servers.

Manage Platform Responder Profiles

Responder profiles define the parameters necessary for the Platform Server responder to authenticatethe user ID and password passed by the Platform Server initiator. You can list, update, or deletePlatform Server responder profiles through the Manage Platform Responder Profiles page which can beaccessed by clicking Management > Manage Platform Functions > Manage Platform ResponderProfiles.

To manage Platform responder profile definitions, you must have AdministratorRight orFTAdminRight.

This page contains a list of Platform responder profiles added to the MFTCC database through the AddPlatform Responder Profile page. If no user profiles are saved in the database, this table is empty.

To update a responder profile definition, click the profile ID of the responder profile definition that youwant to change; make necessary changes and click Update to update the definition.

To distribute a responder profile configuration to a remote Platform Server that is set to be managed byMFTCC, expand the Server List section and select the Platform Server on which you want to have thisprofile be defined and then click Update Server. You can distribute a responder profile to more thanone remote Platform Servers.

51


If a Platform Server contains responder profiles that should be placed in the database, these responderprofiles can be pulled in for future distribution by selecting the Platform Server from the Get ProfileFrom Server drop-down list. A list of responder profiles defined on that Platform Server are returned.You can click the profile ID to go to the Add Platform Responder Profile page and follow theinstructions in Add Platform Responder Profile to add the profile to the database.


To delete a Platform responder profile definition, select the check box next to the Platform responderprofile that you want to delete and click Delete. Multiple Platform responder profiles can be deleted atone time.

SchedulerMFTCC provides Scheduler jobs that can be used to initiate a variety of tasks at predefined intervals orat predefined times.

JobsScheduler jobs can be used to initiate a variety of tasks at predefined intervals or at predefined times.You can add, update, or manage MFTCC Scheduler jobs, and view active jobs through the Scheduler >Jobs option.

Add Job

You can add or update Scheduler jobs through the Add Job page which can be accessed by clickingScheduler > Jobs > Add Job.

The Add Job page is divided into the following sections:

● Required Information

● Platform Transfer

● Internet Transfer

● Non-Event Transfer Alert

● Execute Command

● Execute Java Class

● Send Email

● Batch Job

● Purge DB Tables

● Purge Log Files

● Key Expiration Notification

● Scheduling Information

● Additional Information

Required Information

The Required Information section in this page defines the fields that are required to execute a Schedulerjob. The following table lists those field:

52


Field Description

Enabled Defines whether the job is enabled or disabled.

Disabled jobs are display with the Next Fire Time field on the Manage Jobspage, but will not be executed.

Job Name Defines the job name.

This name is used when managing the Scheduler request.

Group Name Defines whether you want to associate this job with a group.

By default, the job is assigned to the group named Default. Scheduler groupssupport you to search for groups in the Manage Jobs page.

The valid values for this field are as follows:

● None: indicates that this job is not associated with a group.

● Assign to Existing Group: assigns this job to a pre-existing group. Adrop-down list is displayed listing the available pre-existing groups.

● Create and Assign Group: assigns this job to a new group. A text box isdisplayed for you to enter the new group name.

Description Define a description for the job.

Job Type Defines the type of job to be executed by the Scheduler.

The supported job types are as follows:

● Platform Transfer: schedules a predefined Platform transfer that can befound on the Manage Platform Transfers page.

● Internet Transfer: schedules a predefined Internet Server transfer thatcan be found on the Manage Platform Transfers page.

● Non-Event Transfer Alert: schedules an event to occur if the transfer ofa file done by Internet Server or Platform Server fails. For example, a filetransfer fails because the source file is not found.

● Execute Command: executes a batch command or script.

● Execute Java Class: executes a Java Class.

● Send Email: schedules an email to be sent out to one or more emailrecipients.

● Batch Job: executes a batch job.

● Purge DB Tables: purges records from database tables.

● Purge Log Files: purges old log and trace files.

● Key Expiration Notification: configures an email to be sent out when asystem or public key expires.

53


Field Description

Batch Name Defines whether you want to associate this job with a batch.

A batch supports you to execute multiple jobs at the same time. When a job isassociated with a batch, the Scheduling Information section on this page isremoved; the job is executed when the batch is executed.

This field is not displayed when the Job Type field is set to BatchJob.

The valid values for this field are as follows:

● None: indicates that this job is not associated with a batch.

● Assign to Existing Batch: assigns this job to a pre-existing batch. Adrop-down list is displayed listing the available pre-existing batches.

● Create and Assign Batch: assigns this job to a new batch. A text box isdisplayed for you to enter the new batch name.

Department Assigns a department to the job.

Super administrators can assign any department to the job by using this field.

Department administrators can assign their own departments or anydepartments that they can manage to the job by using this field. By default, thedepartments to which the department administrators belong are assigned tothe job.

If the user (a non-administrator user) creating the job is in a department, thisfield is disabled; the department of the user is automatically assigned to thejob.

Users assigned to a department cannot create job types of Execute Command, Execute Java Class,Purge DB Tables, or Purge Log Files. Likewise, jobs with these job types cannot be assigned to adepartment.

Platform Transfer

The Platform Transfer section defines the parameters necessary to execute a Platform transfer. Thefollowing table lists these parameters:

Parameter Description

Transfer Defines a predefined Platform transfer.

The drop-down list displays the transfer ID and the transfer description. Whenyou select a predefined transfer, the values associated with the predefinedtransfer are displayed. You can override these parameter values by inputting avalue.

Run Transfer As Defines the MFTCC user to be used to schedule the transfer.

TransferDirection

Defines whether this is a send request or a receive request.

54



Server Name Defines the Platform Server where the request will be executed.

Servers defined with a server type of Platform Server are listed in the drop-down list.

Initiator FileName

Defines the Platform Server initiator file name.

Responder HostType

Defines whether the responder host name is a node or an IP name.

Responder HostName

Defines the responder host IP name or node name.

Responder PortNumber

Defines the responder port number.

This is only used when the Responder Host Type field is set to IPName.

Responder FileName

Defines the Platform Server responder file name.

Initiator User Id Defines the initiator user ID.

InitiatorPassword

Defines the initiator password.

Confirm InitiatorPassword

Confirms the initiator password.

Responder UserId

Defines the responder user ID.

ResponderPassword

Defines the responder password.

ConfirmResponderPassword

Confirms the responder password.

Wait ForCompletion

Defines whether you will wait for the transfer to complete.

The valid values are as follows:

● Yes: wait for the transfer to complete. The return code is the return code ofthe transfer.

● No: do not wait for the transfer to complete. The return code is 0 if thetransfer is scheduled successfully.

Wait Timeout Defines how long the scheduler waits for a transfer to complete when the WaitFor Completion field is set to Yes.

If this interval expires before the transfer is completed, the transfer isconsidered a failure.

55


Internet Transfer

The Internet Transfer section defines the parameters necessary to execute an Internet transfer. Thefollowing table lists these parameters:


TransferDirection

Defines whether this is an upload (sending file to server) or download(receiving file from server) transfer.

JMS Or File Defines whether the JMS Queue or File Name field points to a JMS queue or afile.

Run Transfer As Defines the Internet Server user to be used to execute the transfer.

when the user is selected, the Virtual Alias drop-down list is updated with alltransfers that the user is authorized to access.

Virtual Alias Defines the virtual alias authorized for the selected user.

Select a virtual alias that the transfer will use.

Server Name Defines the Internet Server where the request will be executed.

You must add a server definition for Internet Servers that will executetransfers; the Server Type parameter must be set to InternetServer.

JMS Queue orFile Name

Defines the JMS queue or file name associated with the request.

Remote FileName

Defines the remote file name associated with the transfer.

Data Type Defines the data type as Text or Binary.

MessageDelimiter

Defines whether records are delimited by LF, CRLF, or have no delimiters.

Wait ForCompletion

Defines whether you wait for the transfer to complete.


● Yes: wait for the transfer to complete. The return code is the return code ofthe transfer.

● No: do not wait for the transfer to complete. The return code is 0 if thetransfer is scheduled successfully.

Wait Timeout Defines how long the scheduler waits for a transfer to complete when the WaitFor Completion field is set to Yes.

If this interval expires before the transfer is completed, the transfer is considereda failure.

56



JMS InputSelector

Defines the selector that is used to filter JMS messages when reading from a JMSqueue (in other words, a download request).

This parameter is ignored when writing to a JMS queue (in other words, anupload request).

This parameter uses the standard JMS Selector format: property name='propertyvalue'. It is important that the selector property value is enclosed in singlequotation marks.

Output JMSTypeProperty

Defines the JMSType output property that is set when writing data to a JMSqueue (in other words, an upload request).

This parameter is ignored when reading from a JMS queue (in other words, adownload request).

Only the value of the JMSType property should be entered in thisfield.

JMS OutputProperty

Defines the output property that is set when writing data to a JMS queue (inother words, an upload request).


This parameter is entered in the format of JMS property name=JMS propertyvalue. Unlike the JMS Input Selector field , the property value should not beenclosed in quotation marks.

Only one JMS property can be defined.

JMS MaxMessage Size

Defines the maximum size of any individual message written to the JMS queue.


Valid values for this parameter are 1K - 999K and 1M - 10M; where K stands forkilobytes and M stands for megabytes. Therefore, the maximum JMS messagethat can be written is 10 megabytes.

Non-Event Transfer Alert

The Non-Event Transfer Alert section defines the parameters necessary to execute a non-event transferalert. Non-event transfers support you to detect that a transfer has not been executed within apredefined interval. The non-event alert is defined on the Add Transfer Non-Event Alert page whichcan be accessed by clicking Management > Alerts > Add Transfer Non-Event Alert.

The following table lists the parameters in the Non-Event Transfer Alert section:


AlertDescription

Defines the non-event alert.

57



Checksuccessfulcompletion for

Defines how many minutes, hours, or days before the alert schedule time shouldbe checked for transfer completion.

Execute Command

The Execute Command section defines the parameters necessary to execute a command. The followingtable lists these parameters:


ExecuteCommand

Defines whether you want to execute the command locally on TIBCO MFTCommand Center or remotely on TIBCO MFT Platform Server.

The following parameters are for executing a command locally:

Full Path ofCommand

Defines the fully qualified path name of the command, executable file, or scriptto execute.

When locally executing a UNIX Shell command such as ls or cp, theentire command must be entered in this field in the following format:-c ls -la /tmp.

CommandParameters

Defines parameters that are to be passed to the command, executable file, orscript.

The following parameters are for executing a command on a Platform Server:

Run CommandAs

Defines the MFTCC user to be used to schedule the transfer command.

Full Path ofCommand

Defines the fully qualified path name of the command, executable file, or scriptto execute.

CommandParameters

Defines parameters that are to be passed to the command, executable file, orscript.

Server Name Defines the Platform Server where the command will be executed.

Platform UserId

Defines the Platform Server user ID.

PlatformPassword

Defines the Platform Server password.

ConfirmPlatformPassword

Confirms the Platform Server password.

58


Execute Java Class

The Execute Java Class section defines the parameters necessary to execute a Java Class. The Class mustimplement the com.proginet.scheduler.jobsScheduledAction interface and contain a non-argumentconstructor. An example of a Class can be found in the <MFT_Install>/server/webapps/cfcc/example/scheduler directory on the server.

The following table lists the parameters in this section:


Full Java ClassName

Defines the full package and Class name to be executed.

Parameters Defines parameters that are to be passed to the Java Class.

Send Email

The Send Email section defines the parameters necessary to send an email.



Recipients Defines the recipients.

Multiple Recipients must be delimited by a semicolon.

Sender EmailAddress

Defines the email address of the sender that will be set in the email.

Subject Defines the email subject.

Message Format Defines whether the message will be formatted as text or HTML.

Email Text Defines the contents of the email.

Batch Job

The Batch Job section defines the parameters necessary to execute a batch job. A batch job is a way togroup multiple requests together so that they can be executed at the same time with the samescheduling trigger.

The following table lists the parameter in this section:


Batch To Execute Defines the batch job to be executed.

Purge DB Tables

The Purge DB Tables section defines the parameters necessary to purge database tables.


59



Delete InternetServer AuditOlder Than

Internet Server audit records written before the number of days defined will bedeleted.

If this parameter is set to 0, no records will be deleted.

Delete PlatformServer AuditOlder Than

Platform Server audit records written before the number of days defined willbe deleted.


Delete AlertAudit OlderThan

Alert audit records written before the number of days defined will be deleted.


Delete LoginAudit OlderThan

Login audit records written before the number of days defined will be deleted.


Delete EventsOlder Than

Events written before the number of days defined will be deleted.


Delete ErrorEvents OlderThan

Error events written before the number of days defined will be deleted.


Purge Log Files

The Purge Log Files section defines the parameters necessary to purge log files.



Delete WebServer logs OlderThan

Web server logs written before the number of days defined will be deleted.

If this parameter is left blank or is set to 0, no logs will be deleted.

Delete MFT LogsOlder Than

MFT logs written before the number of days defined will be deleted.

This includes files in the audit, message, trace, and webAdmin folders.

If this parameter is left blank or is set to 0, no logs will be deleted.

Key Expiration Notification

The Key Expiration Notification section defines the parameters necessary to notify one or more userswhen a private key or public key is about to expire.


60



Email Address Defines one or more email addresses to be notified when a key is about toexpire.

Use a semicolon to delimit multiple email addresses.

Expire In Defines the number of days before expiration when expiring keys will bechecked.

When this parameter is not defined or is set to 0, no checking will beperformed.

Include DisabledKeys

Defines whether expiration checking will be performed on disabled keys.

Select the check box to include checking on disabled keys.

Send Email ToPublic KeyOwner

Defines whether to send an email to the owner of public keys.

This is in addition to the email recipients defined in the Email Address field.

Keys To Monitor Defines the types of keys to be monitored.

Select the check box to monitor the various keys. By default, all types of keysare monitored.

Scheduling Information

The Scheduling Information section defines the parameters necessary to trigger scheduled jobs to beexecuted.



ScheduleFrequency

Defines when and how often jobs are to be executed.

When you click a radio button, parameters for that option will be displayed tothe right.

Not Scheduled Defines whether the job is scheduled to execute.

Execute Once Defines the job to be executed for one time.

Supported schedule triggers are as follows:

● Execute Now: executes the request immediately.

● Execute On: selects a date and time when the request will be executed.

● Store job after execution: keeps the job on the scheduler after the job isexecuted.

● Remove job after execution: deletes the job from the scheduler after the jobis executed

61



By Minute Defines the interval in minutes at which the job will be executed.


● Between: defines the time period (start and stop) within which the job isexecuted.

● Every: defines the interval in minutes at which the job is executed.

● Days: defines the days of the week when the job is executed.

By Hour Defines the interval in hours at which the job will be executed.


● Between: defines the time period (start and stop) within which the job willbe executed.

● Every: defines the interval in hours at which the job will be executed.

● Days: defines the days of the week when the job will be executed.

By Day Defines the day and time when the job will be executed.


● Execute Job At: defines the time when the job will be executed.

● Days: defines the days of the week when the job will be executed.

By Month Defines the day and time within each month when the job will be executed.


● Execute Job At: defines the time when the job will be executed.

● Days: defines the days of the month when the job will be executed. TheDays parameter is mutually exclusive with the parameter that supports youto specify a logical day of the month.

● Supports you to specify a variety of logical days. This parameter ismutually exclusive with the Days parameter.

● Months: supports you to select the months when the job will be executed.

Range ofRecurrence

Defines the start and end date of the schedule trigger.

Jobs will not be initiated before the start date and/or after the end date.

Do not Run onCalendar Day(s)

Selects a calendar that defines days on which the job will not be executed.

Time Zone Defines the time zone used to schedule the request.

The default value is Use server time zone.

Priority Defines the priority of jobs from 1 to 10 where 10 represents the highestpriority.

The priority is used to determine the order in which jobs should be executed.

62



Misfire Policy Defines the misfire policy.

A misfire occurs when the scheduler cannot execute the job during the definedinterval. This might be because the threads are busy or the Scheduler service isdown or on hold.


● Do not execute: misfires will not be executed.

● Execute one misfire: if multiple misfires occur for this job, misfires willbe executed for one job execution only. It will be executed immediatelywhen the Scheduler detects the misfire. If the misfire cannot be executed,another misfire will be scheduled until the misfire is executed.

● Execute all misfires: if multiple misfires occur for this job, a misfirewill be executed for each job.

Additional Information

The Additional Information section defines additional information associated with scheduled jobs.



Exclusive Defines whether a job will be executed exclusively.

when Yes is specified, only one iteration of this job will be run at a time. WhenNo is specified, multiple iterations of this job can be executed at the same time.

Recoverable Defines whether a job is recoverable.

A recoverable job is one that will be re-executed after a schedule operationfails. When a job is set as recoverable, it is possible that the job will be run twotimes.

Dependency/Chain Job

Defines a job to be executed based on job completion.


● Execute on success: defines a job to be executed if this job is completedsuccessfully.

● Execute on failure: defines a job to be executed if this job fails.

Manage Jobs

You can list and update MFTCC job scheduler definitions through the Manage Jobs page which can beaccessed by clicking Scheduler > Jobs > Manage Jobs.

Job scheduler definitions support you to define processes to be executed based on a variety of triggercriteria. You can limit the number of job scheduler definitions displayed in the Results table by settingselection criteria in the Selection Criteria section. The percent sign (%) can be used as a wildcardcharacter. If a field has no search criteria entered, no filtering will be done on that field. If multiple fieldshave search criteria defined, a record must match all defined selection criteria before it is returned.After defining the selection criteria, click Search to perform the search and create the Results table.

63


By default, the Results table displays all the scheduler job definitions you have defined in the system; ifyou have defined selection criteria in the Selection Criteria section, the Results table displays thedefinitions that match the defined selection criteria.

To update a scheduler job definition, you can click the job name of the scheduler job definition that youwant to change; make necessary changes and click Update.

To delete a scheduler job definition, select the check box next to the scheduler job definition that youwant to delete and click Delete. Multiple scheduler job definitions can be deleted at one time.

View Active Jobs

You can view the active scheduler jobs through the Active Jobs page which can be accessed by clickingScheduler > Jobs > Active Jobs.

By default, this page lists active jobs running on MFTCC that you log in. You can select other MFTCCservers in the Host Name drop-down list and press Refresh to refresh the list of active jobs.

The Results table lists all active jobs executing on the selected MFTCC. This table is for informationpurpose only. You cannot update or view these jobs from this page.

CalendarWhen creating scheduler jobs, processing might should not occur on certain dates. You can define thedates on which processing should not occur through the Scheduler > Calender option.

Add Calendar

You can add a calendar to the MFTCC system to define the dates on which a scheduler job should notoccur in the Add Calender page which can be accessed by clicking Scheduler > Calender > AddCalender. After a calendar is created, it can be edited from the Manage Calendars page.

The following figure shows the Add Calender page:

You can create a new calendar from an existing calendar by clicking the Add From Existing Calendarlink. When you click this link, a list of defined calendars is displayed. You can select one of thesecalendars and the calendar information from the source calendar is displayed. You can then add or

64


remove days from the displayed list of days to create the new calendar; the source calendar definition isnot changed.

If you do not wan to use any of the defined calender, you can create a new calender manually by settingthe parameters on this page and clicking Add.

After the calender is created, you can assign it to a scheduler job in the Scheduling Information sectionon the Add Job page which can be accessed by clicking Scheduler > Jobs > Add Job.

Manage Calendars

You can list and update calenders defined in the MFTCC system through the Manage Calenders pagewhich can be accessed by clicking Scheduler > Calender > Manage Calenders.

To update a calender, click the calender name of the calender that you want to update and the UpdateCalender page is displayed. you can remove dates from the calender by clicking Remove at the right ofthe dates that you want to delete, or add dates to the calender. Then, click Update to update thecalender.

To delete a calender, select the check box next to the calender name of the calender that you want todelete and click Delete.

AdministrationYou can configure the system, manage transfer servers, create and manage protocol and PGP publicand system keys, monitor Activity, add and manage authenticators, manage LDAP configuration, andperform lockout management through the Administration option.

System ConfigurationYou can define default values for MFTCC through the Administration > System Configuration option.

This page contains the following sections:

● Global Settings

● Password Reset and Self Registration Rules

● Global Password Rules

● Transfer Settings

● Local Settings

● Global Lockout Rules

● Global PGP Settings

● Global FTP Settings

● Global SSH Settings

● Global HTTPS Settings

● Global Platform Settings

Global Settings

You can define settings common to all MFTCC servers in the Global Settings section.

The following figure shows the Global Settings section:

65


Global Success Email and Failed transfer notifications do not apply to AS2 transfers.

Password Reset and Self Registration Rules

You can define whether users can register by themselves or reset their passwords in the Password Resetand Self Registration Rules section.

The following figure shows the Password Reset and Self Registration Rules section:

66


When users request help accessing their account from the MFTCC login page and click the ResetPassword link, they will be prompted to type in and submit their email address associated with theiraccount (to use this feature, the Email Server Information subsection must be configured in the GlobalSettings section on the System Configurations page and an email address must be defined in the users'accounts). They will receive an email with a link to reset their password. The password requests sent tousers will expire based on the minutes defined in the Password Reset and Self Registration Expirationfield. The default value is 30 minutes. A value of 0 indicates that the password request never expires.The maximum value is 1440 minutes.

Global Password Rules

You can define global rules for password modification and expiration in the Global Password Rulessection.

These password rules only apply to MFTCC users. Any passwords of LDAP Sync users are controlledby LDAP.

The following figure shows the Global Password Rules section:

67


Transfer Settings

You can define the regular expression (REGEX) rules to limit the files can be transferred in the TransferSettings section.

The following figure shows the Transfer Settings section:

Local Settings

You can view the unique settings for individual MFTCC servers that are defined during the installationin the Local Settings section.

The following figure shows the Local Settings section:

68


Global Lockout Rules

You can set the global lockout rules apply to the entire system in the Global Lockout Rules section.

The following figure shows the Global Lockout Rules section:

To set any of the fields in the Login Failure Attempts subsection, a lock action in the Lock Actionsubsection must be enabled. You can set either one or both lock actions to Yes.

To enable the Send Alert Email lock action, you must set the Alert Email Address field in the GlobalSettings subsection on this page.

The failure retention period set for a user account is reset upon a successful login of that user account.For example, if the number of login failure attempts for a user is set to 3 and a user fails to log in twicebut logs in successfully on the third attempt, the number of login failure attempts is reset to zero. Thisalso occurs when the lock duration expires. This means if a user is locked out of the system and the lockduration expires, the number of login failure attempts is reset to zero. However, this does not occur forthe failure retention period of a system or IP. To clear the attempts for these actions requires a lockoutrelease for the system or IP address by a super administration account that is configured with arestricted IP address to log in. These user accounts are never locked out of the system. For more detailsabout releasing lockouts, see Lockout Management.

When setting the number of login failure attempts for the system, an acceptable number should bebased on the amount of users that can access the system. The value is reached by the accumulation ofthe number of login failure attempts of users and that of the IP that are being retained. A very simpleexample of a system lockout occurring is if the number of login failure attempts for users is set to 3 andthat for system is set to 7, the entire system is locked when the seventh failed attempt occurs (thedefault failure retention period for users is 120 minutes). Based on the above settings all it takes is threeusers to fail to access the system in a 120 minute time frame because of attempting to log in withincorrect passwords causing the number of failed login attempts being retained to reach the count of 7and the system is locked.

69


Global PGP Settings

You can view the global PGP settings that will be used by the MFT server in the Global PGP Settingssection.

The following figure shows the Global PGP Settings section:

Global FTP Settings

You can view the global FTP settings to be used by the MFT server in the Global FTP Settings section.

You can override the global setting of the FTP Client Authentication Method field by setting the FTPClient Authentication Method filed in the Authentication Options section on the Add User page.

The following figure shows the Global FTP Settings section:

70


Global SSH Settings

You can view the global SSH settings to be used by the MFT server in the Global SSH Settings section.

You can override the global setting of the SSH Client Authentication Method field by setting the SSHClient Authentication Method field in the Authentication Options section on the Add User page.

The following figure shows the Global SSH Settings section:

Global HTTPS Settings

You can view the global HTTPS settings to be used by the MFT server in the Global HTTPS Settingssection.

You can override the global setting of the HTTPS Client Authentication Method field by setting theHTTPS Client Authentication Method field in the Authentication Options section on the Add Userpage.

The following figure shows the Global HTTPS Settings section:

Global Platform Settings

You can define settings for authentication to the Platform Server in the Global Platform Settings section.

The following figure shows the Global Platform Settings section:

71


File ShareYou can configure the File Share server, view the current status of the File Share Archive server, andstart or stop the File Share Archive server through the Administration > File Share option.

Configuration

You can configure the File Share server through the File Share Configuration page which can beaccessed by clicking Administration > File Share > Configuration.

The File Share Configuration page is divided into the following sections:

File Share ConfigurationDefines where File Share attachments are stored.

Settings for Users Created by SendersDefines default values for parameters of users created by File Share senders.

File Share SettingsDefines default settings and limitations for File Share requests.

Archive SettingsDefines settings used by the File Share Archive server. These settings are grouped into the followingthree subsections:

● General Information: provides information about how the Archive server works.

72


● File Sync Archive Settings: defines parameters related to the File Share Sync File Sharingfunctionality.

● Accessibility: provides information about when the Archive server works.

Archive Server Status

You can view the current status of the File Share Archive server, update the status of the File ShareArchive server, and start or stop the File Share Archive server through the Archive Server Status pagewhich can be accessed by clicking Administration > File Share > Archive Server Status.

If the File Share Archive server is not started, an error message is displayed when you open this page.

The following figure shows the Archive Server Status page:

You can click Server Status to update the status of the File Share Archive server.

You can click Start Server to start the File Share Archive server, and the status of the File Share Archiveserver is updated.

You can click Stop Server to stop the File Share Archive server, and the status of the File Share Archiveserver is updated.

73


Platform ServerTIBCO MFT Platform Server supports clients running TIBCO MFT Platform Server on variousplatforms to send and receive files directly to MFT. You can view the Platform Server status andconfigure the Platform Server through the Administration > Transfer Servers > Platform Server option.

To configure, start, or stop the Platform Server, you must have AdministratorRight.

Platform Server Status

You can view the current status of the Platform Server, update the status of the Platform Server, andstart or stop the Platform Server through the Platform Server Status page which can be accessed byclicking Administration > Transfer Servers > Platform Server > Platform Server Status.


Before you start a Platform Server, you must enable it. See Configure Platform Server for informationabout how to enable a Platform Server.

Each Internet Server that shares the database is displayed in a separate section on this page as shown inthe following figure.

You can click Server Status to update the status of the Platform Server.

You can click Start Server to start the Platform Server, and the status of the Platform Server is updated.

You can click Stop Server to stop the Platform Server, and the status of the Platform Server is updated.

Configure Platform Server

You can configure the Platform Server through the Configure Platform Server page which can beaccessed by clicking Administration > Transfer Servers > Platform Server > Configure PlatformServer.


The following figure shows the Configure Platform Server page:

74


Before you start the Platform Server, you must enable it. By default the Platform Server is not enabled.You can set the Enable parameter to Yes and either keep or edit the default port of 46464 on theConfigure Platform Server page.

Each Internet Server that shares the database is displayed in a separate section on this page. You candefine the fields in the section and click Update to update the definition for this Internet Server.

After configuring the Platform Server, you can start each Platform Server you have configured throughthe Platform Server Status page.


Protocol KeysYou can add FTP, HTTPS, Platform Server, and SSH public keys to the system and manage these publickeys through the Administration > Protocol Keys option. In addition, you can create and store AS2,FTP, SSH, Platform Server, HTTPS, and SAML system keys to be used for secure file transfers that arestored in the database through the Administration > Protocol Keys option.

To add or manage any protocol keys, you must be a super administrator (user that hasAdministratorRight and is not a member of a department).

Add Public Key

You can add SSH, FTP, Platform Server, and HTTPS public keys to the MFTCC system and associate thepublic key with a user or server through the Add Public Key page which can be accessed by clickingAdministration > Protocol Keys > Public Keys > Add Public Key.

The following figure shows the Add Public Key page:

75


To add a public key that is received by a third party, select a key type from the Public Key Type drop-down list, define whether the key is to be assigned to a server or a user, define whether the key isenabled or disabled when it is added to the database, and then paste the Base64 format key to the textbox at the bottom. Click Continue and then verify the details to save the public key.

Create System Key

Servers and clients sometimes require system keys to authenticate the connection to the remote system.You can add AS2, FTP, Platform Server, SSH, HTTPS, and SAML system keys through the CreateSystem Key page which can be accessed by clicking Administration > Protocol Keys > system Keys >Create Key.

The following figure shows the Create System Key page:

76


To create a system key, select a system key type, input the rest of the required information and theoptional fields as needed, and click Create.

Some servers (for example, SSH server) will not start until a system key is generated for that protocol.

When adding HTTPS keys, Base64 version of the certificate is supported. Be sure to include the BEGINand END statements as in the following example:

-----BEGIN CERTIFICATE-----

......HTTPS key information.....

......HTTPS key information.....

-----END CERTIFICATE-----

Kerberos KeyTabs

When you create a HDFS server definition and select to perform Kerberos authentication to the remoteHDFS server, you must define the Kerberos KeyTab file to be used for the Kerberos authentication. Youcan import Kerberos KeyTab files into the system and manage those Kerberos KeyTab files through theAdministration > Protocol Keys > Kerberos KeyTabs option.

Import KeyTab

You can import Kerberos KeyTab files into the system through the Import KeyTab page which can beaccessed by clicking Administration > Protocol Keys > Kerberos KeyTabs > Import KeyTab.

The following figure shows the Import KeyTab page:

77


To import a Kerberos KeyTab file, define the required parameters in this page, and then click ImportKey. TIBCO MFT Internet Server validates the KeyTab file. If the information is valid, a confirmationpage is displayed showing details about the key to be imported.

The KeyTab file to be imported must be accessible from the MFT server that is importing the KeyTabfile.

Manage KeyTabs

You can list, update, and delete KeyTabs defined to TIBCO MFT Internet Server through the ManageKeyTabs page which can be accessed by clicking Administration > Protocol Keys > Kerberos KeyTabs> Manage KeyTabs.

The following figure shows the Manage KeyTabs page:

By default, all the KeyTabs defined to TIBCO MFT Internet Server are displayed in the Results table.You can define selection criteria in the Selection Criteria section on this page to limit the number ofKeyTabs displayed in the Results table.

You can click the description of the KeyTab that you want to update. Make necessary changes, and clickUpdate to update the KeyTab information.

You can select the check box next to the description of a KeyTab and then click Delete to delete thisKeyTab. Multiple KeyTabs can be deleted at one time.

78


Trusted Certificates

Trusted certificates provide a more flexible way to define X.509 certificates for both SFTP (SSH) andFTPS transfers.

Typically, CA (Certificate Authority) certificates are added as trusted certificates to TIBCO MFT InternetServer. When certificate authentication is turned on for your Internet Server SSH server through theAdministration > Transfer Servers > SSH Server > Configure SSH Server option and an SSLnegotiation is performed, any certificate signed by the trusted certificate is accepted. Then thedistinguished name of the certificate is matched against the Certificate DN parameter in theAuthentication Options section on the Add User page.

If you want to monitor a CRL for revoked certificates, you must save the CRL list into the<MFTIS_install>\<context>\ftp\crl directory. Then, set the Certificate CRL Processing parameterin the Global Settings section on the System Configuration page which can be accessed by clickingAdministration > System Configurations. All outgoing CRL processing is for server certificateauthentication. Incoming CRL processing is for either user or server authentication.

For incoming CRL processing, validation of certificates is done as follows:

● If a certificate is assigned to a user or server, the trusted certificate is not checked. In addition,TIBCO MFT Internet Server checks the following things:

— Check whether the certificate is enabled.

— Check the CRL if certificate CRL processing is enabled.

● If no certificate is found assigned to a user or server, the trusted certificates are used for validation,performing the following tasks:

— Verify the certificate is signed by one of the trusted certificates in the MFTCC database.

— Check the CRL if certificate CRL processing is enabled.

— Validate the DN extracted from the certificate against the Certificate DN parameter in theAuthentication Options section on the Add User page.

Add Trusted Certificate

You can add trusted certificates to the MFTCC system through the Add Trusted Certificate page whichcan be accessed by clicking Administration > Protocol Keys > Trusted Certificates > Add TrustedCertificate.

The following figure shows the Add Trusted Certificate page:

79


After you enter data in all of the fields, click Continue. The Add Trusted Certificate Confirmation pageis displayed. Click Continue to add the certificate.

After you add the trusted certificate to the system and sign the certificates generated by that trustedcertificate for an end user defined in MFTCC, you can configure the Certificate DN parameter for thatuser by updating that user definition through the Manage Users page.

Manage Trusted Certificates

You can delete or update the certificates through the Manage Trusted Certificates page which can beaccessed by clicking Administration > Protocol Keys > Trusted Certificates > Manage TrustedCertificates. The Manage Trusted Certificates page displays a list of all trusted certificates that aredefined and summary information about each trusted certificate.

The following figure shows the Manage Trusted Certificates page:

To view the details of certificate or update a certificate, click a entry in the Certificate Type column.Detailed information of this certificate is displayed, and you can disable or enable the certificatethrough the Display Trusted Certificate page.

To delete a trusted certificate, select the check box next to the certificate that you want to delete andclick Delete. You are prompted confirm the deletion.

PGP KeysYou can add and manage PGP public keys, and add, import, and manage PGP system keys through theAdministration > PGP Keys option.

To perform these operations, you must be a super administrator.

80


PGP Public Keys

The PGP public keys are associated with a MFTCC user or MFTCC server definition. You can add PGPpublic keys to the MFTCC database, associate the PGP public key to a user or server definition, andmanage PGP public keys defined to the database through the Administration > PGP Keys > PGPPublic Keys option.

To add and manage PGP public keys, you must be a super administrator.

Add PGP Key

You can add PGP public keys to the MFTCC database and associate the PGP public key to a user orserver definition through the Add PGP Public Key page which can be accessed by clickingAdministration > PGP Keys > PGP Public Keys > Add PGP Key.


The following figure shows the Add PGP Public Key page:

After you enter data in all of the fields, press Continue to add the public key.

You cannot add a public key for a user or server that already has a public key associated with it. Youcan update or replace a key for a user or server through the Manage PGP Public Keys page (for moredetails, see Manage PGP Public Keys).

Manage PGP Public Keys

You can view a list of all the PGP public keys defined to the MFTCC database, and delete or update thepublic keys through the Manage PGP Public Keys page which can be accessed by clickingAdministration > PGP Keys > PGP Public Keys > Manage PGP Keys.


The following figure shows the Manage PGP Public Keys page:

81


To view the details of a public key or update a public key, click an entry in the Key Type column. Thefollowing figure shows the information of tuser001:

You can either disable the key or expand the Display/Replace PGP Public Key section to associate a newPGP public key for this user.

PGP System Keys

You can generate PGP system keys, import PGP system keys generated by a PGP or the gpg utility intothe MFT database, and manage PGP system keys in the MFT database through the Administration >PGP Keys > PGP System Keys option.

To add, import, and manage PGP system keys, you must be a super administrator.

82


Create PGP Key

You can create PGP system keys through the Create PGP System Key page which can be accessed byclicking Administration > PGP Keys > PGP System Keys > Create PGP Key.

The following figure shows the Create PGP System Key page:

After defining the necessary parameters, click Continue to add the PGP system key to the MFTCCdatabase.

SAMLYou can import SAML identity provider metadata, configure SAML service provider metadata, andgenerate SAML service provider metadata through the Administration > SAML option.

Import SAML IDP MetaData

You can import SAML identity provider metadata through the Import SAML Identity ProviderMetadata page which can be accessed by clicking Administration > SAML > Import SAML IDPMetaData.

The following figure shows the Import SAML Identity Provider MetaData page:

83


This page should only be used when you are using SAML SSO (Single Sign On).

The SAML identity provider will provide the metadata that must be imported into MFT before SAMLSSO can be used on an MFT server. Paste the metadata into the text box, and then click Import to savethe metadata for the MFT server. The MFT server will validate that the data is in a proper XML formatand contains valid identity provider data.

After importing the identity provider metadata, you must restart the MFT server before SAMLauthentication can be performed.

Configure SAML SP MetaData

You can configure SAML service provider metadata through the Configure SAML Service ProviderMetaData page which can be accessed by clicking Administration > SAML > Configure SAML SPMetaData.

The following figure shows the Configure SAML Service Provider MetaData page:

84



This page defines the SAML metadata required to initiate an SSO connection with a SAML identityprovider. After entering the necessary information, click Update to update the database.

When any of the information on this page is changed, you must restart the MFT server before SAMLauthentication can be performed.

Generate SAML SP MetaData

You can generate SAML service provider metadata through the Generate SAML Service ProviderMetaData page which can be accessed by clicking Administration > SAML > Generate SAML SPMetaData.

Before you can generate the service provider metadata, you must configure the SAML service providermetadata.

The following figure shows the Generate SAML Service Provider MetaData page:


85


Click Generate to generate the service provider metadata. A text box that contains the service providermetadata is displayed. After the SAMP service provider metadata is generated, you should send thisinformation to the SAML identity provider.

The following figure shows sample SAML service provider metadata:

ActivityYou can view the active sessions and checkpoints through the Administration > Activity option.

To view the active sessions, you must have AdministratorRight or UpdateSessionRight.

Active Users

You can view a list of users that are currently logged onto the system, and delete active users from thesystem through the Active Users page which can be accessed by clicking Administration > Activity >Active Users.

To view the active sessions, you must have AdministratorRight or UpdateSessionRight.

The following figure shows the Active Users page:

86


This page displays all the active sessions in the system. In the figure above, you can see the admin’ssession currently running.

To delete a user’s session, select the check box next to the session that you want to delete and clickDelete. Multiple sessions can be deleted at one time.

Internet Checkpoints

You can view a list of checkpoint records for all the transfers executed by TIBCO MFT Internet Serverand delete the checkpoint records from the system through the Internet Checkpoints page which can beaccessed by clicking Administration > Activity > Internet Checkpoints.

This page can contain a list of the first 100 checkpoint records. If more than 100 checkpoint records arecontained in the system, you can click List Next 100 > to access the next 100 checkpoint records. You canclick Back to see the previous definitions.

You can set selection criteria (any combination of Transfer Id, User Id, Client File Name, TransactionId, and Proxy Transaction Id) in the Selection Criteria section in this page to display a list of particularcheckpoint records. The percent sign (%) can be used as a wildcard character.

To delete a checkpoint record, select the check box next to the checkpoint record that you want to deleteand click Delete. Multiple checkpoint records can be deleted at one time.

AuthenticatorsMFTCC users can be added to the MFTCC database manually through the Java Command Line Utilityand by authenticating to an LDAP server such as active directory. MFT provides easy integration withLDAP servers. you can create, update, and test LDAP authenticators through the Administration >Authenticators option.

To add and manage LDAP authenticators, you must have MFTCC AdministratorRight in the system.

By default, the user name, full name, email address (optional), telephone number (optional), anddepartment (optional) of the LDAP user are pulled into the MFTCC database. In addition to controllinguser’s details being pulled from the LDAP server, you can optionally set up the MFTCC right assignedto those LDAP users.

To allow MFTCC to authenticate and synchronize with an LDAP server, you must configure thefollowing information of the LDAP server:

● You must know the host information such as the IP and port of the LDAP server that you areauthenticating to.

● You must know the Bind user DN and password.

● You must have a container such as an OU or group which contains the specific users to besynchronized with the MFTCC database; for example, OU=MFT Users; the OU contains all userswhich will be synchronized with MFT (see the following figure).

● You must know the user base DN and group base DN where the sync group is located.

The following figures show a sample active directory setting:

87


Add Authenticator

To synchronize the MFTCC database through LDAP, you must configure an LDAP authenticator. Youcan add an authenticator to the MFTCC system through the Add Authenticator page which can beaccessed by clicking Administration > Authenticators > Add Authenticator.

To add an authenticator to the system, configure the required parameters and click Add. Then you cantest the authenticator to verify that your configurations will connect successfully and pull the correctusers into the database through the Manage Authenticators page (see Manage Authenticators for moredetails).

This page is divided into the following sections:

● Authenticator

● LDAP Connectivity

● LDAP Search

● LDAP Attributes

● Right Management

Authenticator

This section defines the authenticator attributes.

The following figure shows the Authenticator section:

88




Name Defines the unique name of the LDAP authenticator in MFT.

It is used as the prefix to the user ID followed by a dash when it is pulled in fromthe LDAP server.

It is good practice to use a short name for the authenticator. When LDAP userIDs are synchronized, they are represented in the MFT database in the format ofxxxxx-user ID; where, xxxxx is the authenticator name. End users do not needthis portion of the user ID to log into the system. For example, John Doe (jdoe)logs in with jdoe and not AD162-jdoe.

This field cannot be modified later.

Type Defines the type of directory from where LDAP is pulling the user and rolecredentials.


● Active Directory

● eDirectory

● Sun Directory Server

● Tivali Directory Server

● Other

Server HostNames

Defines the servers that will use this authenticator.

This parameter is split into two boxes. The Available Host Names box displaysthe server host names that have not been assigned to an authenticator; while theAssigned Host Names box displays the servers that have been assigned to anauthenticator.

If no host name is assigned, this authenticator will be used on allservers.

89



Enabled Enables or disables this LDAP authenticator.

If this box is cleared, all users connected to this LDAP server can no longerconnect to the MFT server; those disabled users lose TransferRight and theLDAP Status field in the Optional User Properties section on the Update Userpage of TIBCO MFT Command Center and TIBCO MFT Internet Server changesto Inactive.

LDAP Connectivity

This section defines the parameters necessary to connect to the directory server and pull in the user androle information for synchronization.

The following figure shows the LDAP Connectivity section:



Host Name/IPAddress

Defines the host name or IP address of the LDAP server.

Bind User DN Defines the distinguished name (DN) required for authenticating to the LDAPserver.

Bind Password Defines the password associated with the defined Bind user.

ConfirmPassword

Confirms the password associated with the defined Bind user.

Port Defines the default LDAP port used by the LDAP server.

The default port for Non-SSL requests is 389 and the default port for SSL requestsis 636.

Use SSL Defines whether to use SSL.

If the LDAP server you are connecting to is using SSL, you must enable thisoption.

90


LDAP Search

This section defines the location of the sync group and the users to be synchronized into the MFTdatabase.

The following figure shows the LDAP Search section:

Both the Sync Group DN and Search Filter fields determines which LDAP users can use MFT. Searchfilter is more efficient because it is applied to the LDAP search directly. The Sync Group DN parameteris less efficient because MFT needs to retrieve and examine each LDAP user in the group until it finds amatch or exhausts the list. When search filter can be used to filter out LDAP users, leave the SyncGroup DN field empty. The search filter can be any valid LDAP filter that defines the MFT users.Typically a search filter contains references to one or more groups that contain MFT users. Thefollowing search filter returns all users that match the following criteria:

objectClass=Person

member of group MFTGroup

(&(objectClass=person)(memberOf=cn=MFTGroup,ou=MyOrgUnit,dc=MyOrg,dc=com))

The following examples demonstrate different configurations you can set up to search for LDAP users(see the figures in Authenticators for reference).

Example 1:

In the following example, 10 active directory users are added to the MFT database (see the first figure in Authenticators for reference. Users are in orange boxes):

Example 2:

In the following example, 2 active directory users are added to the MFT database (see the first figure in Authenticators for reference. The Accounting Properties page displays the two users in the Accountinggroup):

91


Example 3:

The following example shows how to use search filter to performing the same operation as example 2(see the first figure in Authenticators for reference. The Accounting Properties page displays the twousers in the Accounting group):

The following examples shows search filters that can be used when searching for users becomes moredetailed:

● Filter to synchronize multiple security groups in a single authenticator

(|(&(objectClass=user)(memberOf=cn=Accounting,ou=User Groups,ou=MFT

Users,dc=QA,dc=com))(&(objectClass=user)(memberOf=cn=Finance,ou=User

Groups,ou=MFT Users,dc=QA,dc=com)))

● Filter to synchronize all users with mail accounts

(&(objectclass=user)(mail=*))



User Base DN Defines the base in the directory tree where users are defined.

The levels searched below this base depend on the Search Scope parameter

Sync Group DN Defines the fully qualified name of the container on the directory server to beused to associate the users with MFT.

Only users who are inside this container are synchronized with the database.

The Sync Group DN and Search Filter parameters are mutuallyexclusive. Defining both parameters might cause a delay inauthentication. It is good practice to define only one of them.

92



Search Filter With the LDAP search filter, you can be more selective of the user objectsreturned during an LDAP search. The search filter can be used instead of or inaddition to the Sync Group DN parameter. Synchronizing unnecessary LDAPobjects with the MFT server can be avoided when using an appropriate searchfilter.

For example, to synchronize all users from the active directory with mailaccounts, the filter string should be as follows:

(&(objectclass=user)(mail=*))

If you do not want to use a specified filter to search for users, you can change thevalue to (objectClass=user).

Contact your directory server administrator for more details on constructingLDAP search filters.

The Sync Group DN and Search Filter parameters are mutuallyexclusive. Defining both parameters might cause a delay inauthentication. It is good practice to define only one of them.

Search Scope The directory levels below the base DN that LDAP will search.


SUBTREE_SCOPE: defines that all levels below the defined User Base DNparameter will be searched. This is the default value and should be used by mostusers.

ONELEVEL_SCOPE: defines that only the level defined by the User Base DNparameter will be searched.

OBJECT_SCOPE: defines that only the object defined by the User Base DN andSearch Filter parameters will be searched.

LDAP Attributes

This section contains the fields that LDAP reads from the directory datastore server to pull in thecorrect information.

The predefined values in this section should be confirmed with the directory server administrator. Inmost cases, no changes are necessary.

Right Management

In this section, you can enable the rights you want to be managed using the LDAP server.

TIBCO MFT Command Center or TIBCO MFT Internet Server users can be assigned with variousrights. The most popular of these rights is TransferRight; without this right being assigned, userscannot perform file transfers. When the Assign TransferRight to all users check box in thisauthenticator is selected, all users in this authenticator are assigned with TransferRight when they aresynchronized. When this check box is selected, you should not select the TransferRight check box toenable the synchronization of TransferRight. Some LDAP environments might want to control whichusers are assigned with this right and other rights from the LDAP server. When the right is enabled formanagement through the LDAP server, it cannot be granted or ungranted from TIBCO MFT CommandCenter or TIBCO MFT Internet Server. A group with the name defined in the LDAP Group Name fieldmust exist on the directory server and the users assigned with this right must be members of the group.

93


In the following example, any users added from the TransferRight group of the active directory aregiven FileXpress TransferRight when they are added to the database (see the second figure in Authenticators for reference. Users are pulled from the TransferRight group):



Right GroupBase DN

Defines the location in the directory tree of the OU which contains the MFT rights.

Enable When this check box is selected, that right will be managed on the defined LDAPserver.

Right Name Defines the right as it is recognized by MFT.

LDAP GroupName

Defines the name of the group on the LDAP server which will be associated withthe right in MFT.

This can be the same as the Right Name parameter or be specified as a differentgroup name. The value of the LDAP Group Name field should match the groupname on the directory server.

Manage Authenticators

You can update, delete, or test authenticators through the Manage Authenticators page which can beaccessed by clicking Administration > Authenticators > Manage Authenticators.

The following figure shows the Manage Authenticators page:

94


To update an authenticator configuration, click the authenticator name link of the authenticator thatyou want to update and the Update Authenticator page is displayed. After making necessary changes,click Update to save the changes.

To delete an authenticator, select the check box next to the authenticator that you want to delete andclick Delete. Multiple authenticators can be deleted at one time.

To test an authenticator connection, click the Test link of the authenticator that you want to test. Thefollowing figure shows the test results: two users are synchronized with the MFT database along withthe TransferRight assignment (see Add Authenticator for more details).

When the test is successful, you can synchronize users and rights from the directory server throughLDAP. If no rights are enabled for the authenticator, the users are added to the MFT database withoutany rights when the LDAP synchronization is performed. Then, the MFT administrator can assignrights to the users through the MFTCC Administrator web pages. For more information ofsynchronizing with the LDAP authenticator, see LDAP Sync.

LDAP SyncTo populate the MFT database with LDAP users, you must synchronize MFTCC with an LDAP server.To bind to the LDAP server, you must set up an authenticator. After the authenticator is configured andtested, you can run an LDAP synchronization.

For more information on how to set up an LDAP authenticator, see Add Authenticator.

By default, synchronization to the MFTCC database pulls in the user name, full name, email address (ifdefined), phone number (if defined), and department (if defined) for the directory user contained in theLDAP sync group, and any rights assigned to the user if rights management is enabled on theauthenticator.

To synchronize LDAP authenticators, you must have MFTCC AdministratorRight.

Synchronization can be performed in the following three different ways:

● Manual Sync: you can perform a manual synchronization through the LDAP Sync page tosynchronize a single user or all LDAP users.

To perform manual synchronization, you must be an administrator.

● Scheduled Sync: you can perform a scheduled synchronization once a day by setting up theparameters in the LDAP Settings subsection in the Global Setting section on the SystemConfigurations page which can be accessed by clicking Administration > System Configurations.By default, this is disabled.

If you have a TIBCO MFT Command Center and TIBCO MFT Internet Server sharing thesame database, the synchronization can be configured to be performed by either server.

● Automatic Sync: this synchronization occurs when an LDAP user logs into the MFTCC system andauthenticates against the LDAP server.

95


If for any reason a user fails to be synchronized, you can find further information on the cause byreading the ldap_sync_report_messages-MFT-xxxx-xx-xx.txt report that is located in<MFT_Install>\logs\message directory; where, xxxx-xx-xx represents the date on which thesynchronization took place.

Manual Sync

You can perform a manual synchronization through the LDAP Sync page which can be accessed byclicking Administration > LDAP Sync to synchronize a single user or all LDAP users.

To perform manual synchronization, you must be a super administrator.

To perform the synchronization, log into TIBCO MFT Command Center or TIBCO MFT Internet ServerAdministrator web pages and click Administration > LDAP Sync. On the LDAP Sync page, you cansynchronize a single user or all users across all active authenticators or a selected group ofauthenticators.

The following figures show a sample manual synchronization:

To synchronize a single user, click the Sync User radio button, type in the user ID that you want tosynchronize with in the UserId field, and then click Sync.

To synchronize all users, click the Sync All Users in These Authenticators radio button. All users andall roles for the defined authenticators will be synchronized. By selecting the default value of All, allusers in all authenticators will be synchronized. Alternatively, you can select a single authenticator byclicking that authenticator. You can select multiple authenticators by pressing CTRL and clicking theauthenticators. Any users defined to LDAP but not to TIBCO MFT Internet Server will be added toTIBCO MFT Internet Server. Any user defined to TIBCO MFT Internet Server but not to LDAP will bedisabled. Any user whose LDAP attributes are different than the database attributes, will besynchronized. Additionally, TIBCO MFT Internet Server checks all Internet Server roles defined toLDAP to insure that they are synchronized with the Internet Server rights. When you synchronize allusers, the synchronization can take a few minutes to complete when a large number of users aredefined by the LDAP authenticators.

After you have selected the action that you want to perform, click Sync to start the synchronizationprocess. The synchronization options can take a few minutes to complete. During the synchronizationprocess, do not click the Sync button until the previous synchronization is completed.

The total amount of LDAP users and rights (if enabled) synchronized are displayed at the top of thescreen. If an error occurs for one user, the synchronization continues on to the next user.

96


After you synchronize the LDAP users, you can see the new LDAP users added to the system on theManage Users page which can be accessed by clicking Users > Manage Users. The following figureshows the two LDAP users added to the system:

When LDAP user IDs are synchronized, they are represented in the MFT database in the format ofxxxxx-userid; where, xxxxx is the authenticator name. End users do not need this portion of the user IDto log into the system. For example, John Doe (jdoe) logs into the system with jdoe instead of AD162-jdoe.

The new users synchronized can now log into MFT using several different user ID options. John Doefrom the example above can log into the system using the following user IDs:

● jdoe

● QA\jdoe: uses the LDAP domain.

If an end user has the same LDAP user ID in multiple domains that will be synchronized, the end usermust always log into the system with the specific domain and user ID to be connected with.

Scheduled Sync

You can perform a scheduled synchronization once a day by setting up the parameters in the LDAPSettings subsection in the Global Setting section on the System Configurations page which can beaccessed by clicking Administration > System Configurations.

The following figure shows the LDAP Settings subsection in the Global Setting section on the SystemConfigurations page:

Select the server on which you want to perform the synchronization from the Server Host Name drop-down list. By default, this is set to Disabled. If you do not have multiple TIBCO MFT CommandCenters or TIBCO MFT Internet Servers sharing the database, you only see one server listed in thedrop-down list.

Then, set the Sync Server Start Time parameter, and click Update to save your configurations.

Automatic Sync

An automatic synchronization occurs every time an LDAP user logs in to the MFTCC system andauthenticates against the LDAP server. This ensures that any updates to an end user account comeacross to the MFT database at the time of login.

LockoutYou can release invalid login locks for users, IP addresses, and the entire system through theAdministration > Lockout option.

To release locks for users, IP addresses, and the system, you must have AdministratorRight.

You can configure when a lockout occurs in the Global Lockout Rules section on the SystemConfiguration page which can be accessed by clicking Administration > System Configuration.

97


Lockout Management

You can release a lock that is placed on users, IP addresses, or the system through the LockoutManagement page which can be accessed by clicking Administration > Lockout > LockoutManagement.

To release locks for users, IP addresses, and the system, you must have AdministratorRight.

The following figure shows the Lockout Management page:

To release a lock on a single user account, type the MFT user ID of the user in the User id(s) field andclick Release Locks. If a lock is in place for that user ID, a message is displayed to inform that the useraccount is released. The same occurs if you release a single IP address. You can release more than oneuser or IP address by typing them in the corresponding fields and separating them with a semicolon asshown in the following example:

10.97.196.26;10.97.196.101

If all the locks need to be released, select either the All User Ids, All IP Addresses, or All Locks radiobutton and click Release Locks.

Validation is not performed on the user IDs or IP addresses entered.

Restarting the web server clears all locks.

ReportsYou can view and manage audits, alerts, events, and error events, view active transfers, performdiagnostic and statistic operations, generate database reports, and view server status through theReports option.

The following figure shows the menus under the Reports option:

98


AuditsYou can search, delete, and save specific search criteria in a filter for audit records either generated byMFTCC or Platform Server audit logs collected by MFTCC.

For more information about collecting Platform Server audit logs, see Collection Service.

Search Audits

You can search for completed Internet Server and Platform Server transfers through the Search Auditspage which can be accessed by clicking Reports > Audits > Search Audits.

By default, the first 100 audit records for the present day are displayed in the Results table. If more than100 audit records are contained in the database, you can click List Next 100 > to view the next 100 auditrecords.

If you want to conduct a more detailed search of the audit records contained in the database, you canset selection criteria in the Selection Criteria section. You can use a single field or a combination of fieldsto define the selection criteria. The percent sign (%) can be used as a wildcard character in all the fields.

To view all the details of an audit record, click the audit ID of the audit that you want to view.

The Internet Server transfer records are written and saved in the database when TIBCO MFT InternetServer transfers are conducted. However, Platform Server audit records are read from one of followingtwo places:

● The database. This happens when the Platform Server audit logs are saved to the database by theCollection service. See Collection Service for more information about collecting Platform Serveraudit logs.

● Directly from the Platform Server when the Platform Server Manual Poll is run by configuring thenecessary parameters in the Platform Server Manual Poll Criteria section to extract records in realtime.

To pull records (these records are not saved to the database) from a Platform Server, youmust have FTAdminRight.

99


Platform Server Manual Poll

To run a Platform Server Manual Poll on a remote Platform Server, a server definition with a server typeof Platform Server must be defined in MFTCC. For this server definition, the Manage Platform Servercheck box must be selected in the Management Options section on the Add Server page (this is the onlyparameter needed to be set at this time for this process). In addition to the server definition beingdefined, you must also have your Collection service configured and running to collect the audit logsfrom that Platform Server. Using the Manual Poll search causes the collector to go out and pull theaudit logs from the Platform Server in real time and bring the audit logs forward for you to view now.

Delete Audits

You can delete Internet Server and Platform Server audit records contained in the database through theAudit Delete page which can be accessed by clicking Reports > Audits > Audit Delete.

To delete audit records, you must have AdministratorRight or DeleteAuditRight.

To delete audit records, configure the Date or Number of Days parameter and the Audit Typeparameter, and then click Delete.

Audit Search Filters

When you use the Selection Criteria section on the Search Audits page to define exactly what auditsyou wants to view, you have to define the selection criteria every time you use the Search Audits page.While, by using the audit search filters, you can define the search criteria you want to use and then savethe search criteria to use them over and over again.

To add or manage audit search filters, you must have AdministratorRight.

Add Audit Search Filter

You can predefine the selection criteria used to display Internet Server and Platform Server auditrecords through the Add Audit Search Filter page which can accessed by clicking Reports > Audits >Audit Search Filters > Add Audit Search Filter.


You can define filters to limit the number of audit records displayed in the Audit Search Filter SelectionCriteria section. After defining the selection criteria, press Add to add the filter to the audit search filterdatabase. Then, you can select this filter in the Retrieve pre-selected filter drop-down list in theSelection Criteria section on the Search Audits page which can be accessed by clicking Reports > Audits> Search Audits to use this filter for search.

Manage Audit Search Filter

You can view the audit search filters that you are authorized to access, and update or delete these filtersthrough the Manage Audit Search Filter page which can be accessed by clicking Reports > Audits >Audit Search Filters > Manage Audit Search Filter.


This page can list the first 100 defined audit search filters saved in the database. If more than 100 auditsearch filters are defined, you can click List Next 100 > to view the next 100 audit search filterdefinitions.

To update an audit search filter you have saved in the system, click the search audit ID of the auditsearch filter definition that you want to change; make necessary changes and then click Update to savethe changes.

100


To delete an audit search filter definition, click the check box next to the audit search filter definitionthat you want to delete and then click Delete. Multiple audit search filters can be deleted at one time.

View Active TransfersYou can view transfers currently executing on a particular server through the View Active Transferspage which can be accessed by clicking Reports > View Active Transfers.

You can select a server from the Remote Server drop-down list and then click Refresh to view theactive transfers of that server.

DiagnosticsYou can view information that assists TIBCO Technical Support in solving issues with TIBCO MFTCommand Center and TIBCO MFT Internet Server through the Diagnostics page which can be accessedby clicking Reports > Diagnostics.

The diagnostic information for each server is displayed in a separate section on this page. You can clickRetrieve Diagnostics in a section to view the diagnostic information of that server. When the diagnosticinformation is displayed, you can click the Save Server Diagnostics to File link to save the page as afile. After clicking this link, the Download file page is displayed and you can select the location whereyou want to save the file. The exact page format and the location of the file are dependent on the webbrowser that you are using.

The Diagnostics includes the following sections:

Section Description

Version Information Displays information about the version and build, and the J2EE servertype and version.

Install Paths Displays the path where TIBCO MFT Internet Server is installed.

Database Info Displays the number of active database connections.

JVM Settings Displays the JAVA virtual machine memory usage and FIPS settings.

Active Transfers Displays information about currently active transfers.

Server Time Settings Displays the current time on the remote server and on the local server.

JVM System Properties Displays information about the JAVA virtual machine.

SSL Ciphers Suites Displays SSL or TLS Ciphers supported by the JVM.

Web.xml ContextParameters

Displays information in the web.xml file.

File Information Displays the path and date and time of files located in the applicationcontext and important JAVA files.

StatisticsYou can view information about the activity on the TIBCO MFT Internet Server system through theStatistics page which can be accessed by clicking Reports > Statistics.

The following table shows the Statistics page:

101


Alert HistoryYou can search for and delete alerts generated by completed Internet Server and Platform Servertransfers through the Reports > Alert History option.

Search Alerts

You can search for alerts that have been generated by completed Internet Server and Platform Servertransfers through the Search Alerts page which can be accessed by clicking Reports > Alert History >Search Alerts.

The following figure shows the Search Alerts page:

If any alerts are defined and executed, the Search Alerts page displays the alert audit records for thepresent day. By default, the first 100 alert audit records are displayed in the Results table. If more than100 alert audit records are available, click List Next 100 > to view the next 100 alerts audit records.

You can define selection criteria in the Selection Criteria section to limit the alert audit recordsdisplayed in the Results table. You can use a single field or a combination of fields to define theselection criteria. The percent sign (%) can be used as a wildcard character in all the fields.

The following figure shows the Selection Criteria section:

102


The Department field in the Common Criteria subsection defines the department specified in the alertdefinition.

To view the details of an alert audit record, click the alert audit ID of the alert audit record that youwant to view and the Alert Details page containing the details of the alert audit record is displayed.

Delete Alerts

You can delete alert audit records from the alert audit database through the Delete Alerts page whichcan be accessed by clicking Reports > Alert History > Delete Alerts.

To delete an alert audit record, you must have AdministratorRight or DeleteAuditRight.

103


To delete alert audit records, define the Date or Number of Days field and then click Delete.

Every alert audit record that is deleted is saved in a file in the Install Audit directory created duringthe MFTCC installation.

EventsYou can search for events and delete events generated by completed Scheduler processes through theReports > Events option.

Search Events

You can search for events generated by completed Scheduler processes through the Search Events pagewhich can be accessed by clicking Reports > Events > Search Events.

The following figure shows the Search Events page:

By default, this page displays the first 100 event records in the Results table.

You can define selection criteria in the Selection Criteria section to limit the number of events that aredisplayed in the Results table. You can use a single field or a combination of fields to define theselection criteria. The percent sign (%) can be used as a wildcard character in all the fields. Theinformation entered in the Selection Criteria section is matched against the records in the TIBCO MFTInternet Server database. Only records that match all the parameters defined in the selection criteria arereturned.

104


Delete Events

You can delete event records from the event database through the Delete Events page which can beaccessed by clicking Reports > Events > Delete Events.

To delete event records, you must have AdministratorRight or DeleteAuditRight.

You can define the events to be deleted by configuring the following two fields:

Parameters Description

Date: Delete Event RecordsOlder Than

Defines a date and all event records written before that date willbe deleted.

Number of Days: Delete EventRecords Older Than

Defines the number of days and all event records written beforethose days will be deleted.

Server StatusYou can monitor the current status of enabled servers (namely, the Check Server Status parameter inthe server definition is set to Yes) through the Server Status page which can be accessed by clickingReports > Server Status. The servers can be monitored include Platform Servers, FTP servers, SSHservers, and AS2 servers.

To view server status through this page, you must have AdministratorRight, UpdateServerRight, orViewServerRight.

The following figure shows the Server Status page:

You can define selection criteria in the Selection Criteria section to limit the number of servers beingmonitored. By default, all servers that are not disabled are monitored.

The server status information of the server being monitored is displayed in the Results table. In theStatus column in the Results table, the following four status colors are used to indicate different serverstatus:

Status Color Description

Blue circle with aquestion mark

Indicates that server status requests are never attempted to this server.

Green Indicates that the server is up and available.

For TIBCO MFT Platform Server, it also means that the server is at a levelcompatible with TIBCO MFT Command Center functions and is configured toaccept the functions.

105


Status Color Description

Yellow (only forTIBCO MFTPlatform Server)

Indicates that the server is available, but the server is not at a level compatiblewith TIBCO MFT Command Center functions, or is not configured to acceptTIBCO MFT Command Center functions (nodes defined in TIBCO MFTPlatform Server for TIBCO MFT Command Center).

Red Indicates that the server is down. MFT cannot connect to the IP name and portdefined in the server definition.

To view the details of a server, click the server name of the server and the Server Status Detail page isdisplayed.

The following figure shows a sample Server Status Detail page:

One of the server status features is to display the license information of a Platform Server, the name ofthe computer on which the server is installed, and the current version of the Platform Server. If thelicense key of the Platform Server will expire in 30 days, an email will be sent to the recipient emailaddress defined on the Configure Status Service page which can be accessed by clicking Management >

106


Manage Services > Status Service > Configure Status Service. As new versions of Platform Server arereleased, this information will be updated; and until that time these parameters might not display thecorrect information.

Database ReportsMFTCC has been integrated with Crystal Reports® software from Business Objects™. This reportingcapability supports you to view reports using the information in the MFTCC database through theDatabase Reports page which can be accessed by clicking Reports > Database Reports. MFTCC comeswith a variety of reports built into the software.

To view database reports, you must have AdministratorRight or DBReportRight.

The following figure shows the Database Reports page:

107


This page lists all of the reports that can be viewed. Each field has a report description and a ViewReport button. To view a report, click View Report. It might take a few minutes for the report tocomplete depending on the amount of data in the report.

You can create your own custom reports, and have the reports listed on this page. For more informationof how to add custom reports, see Adding Custom Reports.

Adding Custom Reports

MFTCC comes with several system auditing reports already created. The reporting feature of MFTCCsupports you to create and display your own custom reports within the MFTCC administrativecomponent.

After you create a custom report with Crystal Reports, it must be placed in the classes directory underthe WEB-INF directory.

MFTCC uses a .xml file to configure the reports that are displayed on the Reports page. This file isnamed Reports.xml and is located in the view/reports directory under the context directory on theweb server. The file holds an entry for each report and each entry contains the text that will bedisplayed on the Reports page, the report file name, and the JSP files that will be used to display thisreport. You can get your custom reports displayed on the Reports page by adding entries to this file.

If you have a report that requires no user input, all you need to do to get the report displayed is to addan entry to the Reports.xml file.

For example:<report category="other"> <label>My Custom Report</label> <report-filename>MyReport.rpt</report-filename> <report-display>report_param2.jsp</report-display></report>

Use MFTCC report_param2.jsp if your report requires no input.

If you have a report that requires input, you have to write the JSP that displays buttons, text box, and soon that will collect user input. You also have to write the JSP that displays the report. You can refer toMFTCC JSPs as an example. For example, the ReportSelectionPage.jsp file displays dates and thereport_param.jsp file uses that input to display the report to the user.

Reports.xml File

The following table lists the tags used in the Reports.xml file:

Tag Name Required Number Description

company-name

Yes One per file This name is displayed in the upper-right corner ofMFTCC supplied reports. It can be changed todisplay your company name.

report No Zero to manyper file

This is a report to be displayed.

It has a required attribute that defines into whichcategory of the Reports page the report will be put.The valid values include transfer, exception, users,security, alerts, and other. If the attribute does notmatch one of these, the report will be put in the othersection. The other section is labeled Miscellaneous onthe Reports page.

108


Tag Name Required Number Description

label Yes One per reporttag

This is the description that is displayed next to theView Report button on the Reports page.

report-filename

Yes One per reporttag

This is the name of the report file located in theclasses directory under the WEB-INF directory

report-input

Yes One per reporttag

This is the name of the JSP file to be used to collectuser input if your report requires input, such as adate range.

This JSP file is located in view/cfcc directory.

report-display

No One per reporttag

This is the name of the JSP file that displays thereport.

It uses the crystal reports JRC API to display thereport.

This JSP file will be located in view/cfcc directory.

Error EventsError events are written when errors are detected in normal processing, but audit records might not bewritten. Error events can help you perform problem determination without taking traces. You cansearch for error event detected through the Reports > Error Events option.

Search Error Events

You can search for error events detected through the Search Error Events page which can be accessedby clicking Reports > Error Events > Search Error Events.

By default, up to 500 error event records can be displayed in the Results table on the Search ErrorEvents page.

You can define selection criteria in the Selection Criteria section to limit the number of events that aredisplayed in the Results table. The following figure shows the Selection Criteria section:

109


You can use a single field or a combination of fields to define the selection criteria. The percent sign (%)can be used as a wildcard character in all the fields. The information entered in the Selection Criteriasection is matched against the records in the TIBCO MFT Internet Server database. Only error eventrecords that match all the parameters defined in the selection criteria will be displayed.

HelpYou can view detailed descriptions of each page and all the fields on the page by clicking the Help icon,

.

110


Delegated Administration

Delegated administration offers an administrator the ability to divide the system into smaller unitswhich can be managed independently of one another. This subdivision of the system offers greatersecurity and eases of burden of administration on a single administrator. It allows businesses to create asystem based on their organizational structure. Internal divisions of a corporation and external partnerscan be given autonomous control over the management of their users and transfers.

These smaller units, called departments, can have one or more administrators assigned to managethem. The department administrator’s domain is over the users, groups, transfers, servers, and auditrecords assigned to the administrator's department and the departments that this administrator canmanage. The department administrator cannot administer anything else in the system. The existingsystem rights, such as UpdateTransferDefinitionRight, can also be applied to a departmentadministrator thus offering a finer granularity of administrative control.

Administrators who are not assigned to a department are considered super administrators who canmanage the entire system. While department administrators can only access their own departments andthe departments they can manage, super administrators have access to all departments in the system.They are the only ones who can administer servers, system configurations, FTP server configuration,and checkpoints. They are also the only ones who can add departments and change the department towhich a server is assigned.

Administrators can further limit the access to their users, groups, and servers through the use ofvisibility. Visibility supports departments to interact with each other without giving up administrativecontrol. When applied to users, groups, and servers, visibility supports departments to expose or hidethese items from each other. This is achieved by setting the Visibility parameter to public or private.For example, the Sales department can create a transfer and give authorization for that transfer to a userwith public visibility in the Accounting department. The administrative control of the transfer stillbelongs to the Sales department that created it but the ability to transfer the file is given to a user in theAccounting department. The Sales department can in no way alter the attributes of the user from theAccounting department. If this Accounting user is with private visibility, the Sales department cannotgive this user authorization to transfer the file. In this case the user is effectively hidden from otherdepartments.

This design supports existing customers to keep their system as it is and gives new customers theoption not to use these features. In these cases, all administrators are super administrators, and transferusers, groups, servers, and audit records are not assigned to any department. The system functionswith respect to administration as it did in versions prior to version 2.2 of SIFT.

Administrative Functions and RulesThe department and visibility features affect how the administrative functions of MFTCC works whenperformed by department administrators and super administrators.

For the tasks that administrators can perform and what the task does when performed by departmentadministrators and super administrators, see the following introductions:

● Active Users

● Alerts

● Audits

● Collector

● Database Reports

● Departments

● Diagnostics

● FTP Server Configuration

111


● Groups

● Platform Nodes

● Platform Responder Profiles

● Platform Transfers

● Platform User Profiles

● Server

● Server Credentials

● Statistics

● System Configuration

● Users

Active UsersUsers with UpdateSessionRight can delete and view active users; while users with ViewSessionRightcan only view active users.

Role Description

DepartmentAdministrator

Department administrators with ViewSessionRight can only view activeusers in their departments.

Department administrators with UpdateSessionRight can delete and viewactive users in their departments.

Super Administrator Super administrators can view or delete any active users.

AlertsAlerts administrative tasks can be limited by the rights that are assigned (or not assigned) to a user. Inaddition to AdministratorRight, administrative users can also be assigned ViewAlertRight andUpdateAlertRight.

Add Alert

Role Description


Department administrators can add alerts to the system, but they arelimited as to which alert actions can be taken.

When department administrators add an alert, they can assign the alert totheir own departments or to any departments that they can manage.

By default, the alert is assigned to the departments to which the departmentadministrators belong.

Department administrators can change the department that an alert isdefined for to their own departments or to the departments that they canmanage.

Super Administrator Super administrators can add alerts to the system utilizing any type of alertaction available.

112


Manage Alert

Role Description


Department administrators can list, update, and delete alerts for their owndepartments and for the departments that they can manage.

Super Administrator Super administrators can list, update, and delete alerts from all departmentsin the system.

AuditsAudits records are assigned to the department from which the corresponding transfer definition isassigned. Audit records do not have a visibility associated with them. An audit record can only belongto one department in the system. Department administrators can view audit records assigned to theirdepartments and audit records assigned to the departments that they can manage. The exception to thisrule occurs when the department administrator performs searches on audit records.

For more information of searching audits, see Search Audits. To perform audit searches, you must haveViewAuditRight.

Search Audits

Role Description


Department administrators can search for and display audit records that areassigned to their departments and to the departments that they can manage.

When performing a search based on user ID, group ID, or server name, onlythose that are assigned to this department and to the department that thedepartment administrator can manage can be used as search criteria.

Department administrators can view audit records of file transfers assignedto their departments and audit records of file transfers assigned to thedepartments that they can manage, except in the case when a search is donebased on a specific transfer user ID or a specific audit ID. Performing asearch on a specific transfer user ID returns all audit records for that user nomatter which department the transfer is assigned to. In the same way,performing a search on a specific audit ID returns the audit record for thetransfer no matter which department the transfer is assigned to. Thisextended search capability is provided as a convenience for departmentadministrators.

Super Administrator Super administrators can search for and display all audit records in thesystem.

Delete Audits

Role Description


To delete audit records, department administrators must be assignedDeleteAuditRight; in this case, department checking is not performed.

Super Administrator Super administrators can delete any audit record in the system.

113


CollectorOnly super administrators can perform Collector tasks.

Database ReportsDatabase report administrative tasks can be limited by the rights that are assigned to a user.

Role Description


To administer database reports, department administrators must haveDBReportsRight.

Super Administrator Super administrators, with only AdministratorRight, can administerdatabase reports. No additional rights are necessary.

DepartmentsThe department administrative tasks can only be performed by super administrator. Departmentadministrators can only manage users assigned to their own departments and users assigned to thedepartments that they can manage.

Add Department

Role Description


Department administrators cannot perform this task.

Super Administrator Super administrators can add departments to the system.

Manage Departments

Role Description



Super Administrator Super administrators can list, update, and delete all departments in thesystem.

DiagnosticsOnly super administrators can perform this task.

FTP Server ConfigurationOnly super administrators can perform these tasks.

GroupsGroups can be assigned to a specific department and they can have public or private visibility.

Granting a group private visibility means that public users from all departments and private users fromits own department can be added to it. This group ID can be managed by its own departmentadministrator as well as by other department administrators that can manage the department assignedto this group. This group can be set as the authorized group ID in a file transfer definition that is

114


assigned to this department. This group can also be used as the group ID value in a user profiledefinition for public and private nodes in this specific department.

Granting a group public visibility means that this group can do what a private group is capable to do;and in addition, this group ID can be seen and are available to all department administrators in thesystem. This group can have public users from other departments added to it, and the group can be setas the authorized group ID in a file transfer definition that is assigned to other departments. The groupcan be used as the group ID value in a user profile definition created for public nodes assigned to otherdepartments. Group IDs must be unique throughout the system, thus groups in different departmentscannot have the same group ID. A group can only belong to one department in the system.

Department administrators can see groups assigned to their departments, groups assigned to thedepartments that they can manage, and groups from other departments that have public visibility. If asuper administrator updates a group originally created by a department administrator, only theinformation that the department administrator has access to can be used. Otherwise, an error occurs.

UpdateGroupRight supports users to add, update, delete, and view groups. ViewGroupRight supportsusers to view groups.

Add Group

Role Description


Department administrators can create a group, and assign the group to theirdepartments or the departments that they can manage.

The visibility of the group can be set to public or private.

Super Administrator Super administrators can create a group which can be assigned to anydepartment in the system or to none at all.

The visibility of the group can be set to public or private.

A group that is not assigned to a department gains no special properties butcan only be administered by super administrators.

Manage Groups

Role Description


Department administrators can update and delete any groups that areassigned to their departments and any groups that are assigned to thedepartments that they can manage.

Department administrators can see and change the Department parameterof a group definition assigned to their departments and the Departmentparameter of a group definition assigned to any departments that they canmanage.

The visibility of the group can be changed to public or private by thedepartment administrator.

Super Administrator Super administrators can list, update, and delete any group in the system.

The department that this group is assigned to can be changed to anydepartment in the system or to none at all.

The visibility of the group can be changed to public or private. Payspecial attention when changing the visibility of a group, because thischange might include or exclude users.

115


Platform NodesAdministrative tasks can be limited by the rights that are assigned (or not assigned) to a user.

Add Platform Node

Role Description


Department administrators can add a Platform node to the system, andassign the node to their own departments or any departments that they canmanage.

By default, the node is assigned to the departments to which the departmentadministrators belong.

Super Administrator Super administrators can creates a Platform node which can be assigned toany department in the system or set to none. A Platform node that is notassigned to a department has no special properties.

Update Platform Node

Role Description


Department administrators can list, update, and delete Platform nodesassigned to their own departments and the departments that they canmanage.

Department administrators can change the department to which thePlatform node is assigned to their own departments or to any departmentsthat they can manage.

Super Administrator Super administrators can list, update, and delete all platform nodes in thesystem. The department that the platform node is assigned to can bechanged to any department in the system or to none.

Platform Responder ProfilesPlatform administrative tasks can be limited by the rights that are assigned (or not assigned) to a user.In addition to AdministratorRight, administrative users can also be assigned FTAdminRight.

Add Platform Responder Profile

Role Description


Department administrators can add a Platform responder profile to thedatabase, and assign it to their own departments or any departments thatthey can manage.

By default, the Platform responder profile is assigned to the departments towhich the department administrator belong.

Super Administrator Super administrators can add Platform responder profiles to anydepartment in the system.

116


Update Platform Responder Profile

Role Description


Department administrators can list, update, and delete Platform responderprofiles assigned to their own departments and the departments that theycan manage.

Super Administrator Super administrators can list, update, and delete any Platform responderprofile in the system.

Platform TransfersBecause Platform transfers can be done on the fly, no department is assigned to an individual ad hoctransfer. However, Platform transfers created and added to the system can have a department assignedto it. When a department user enters the Manage Platform Transfers page, Platform transfers assignedto the user’s department and Platform transfers assigned to the departments that this user can manageare listed.

A Platform transfer can be assigned to only one department in the system. The administrator canchoose not to assign a department to the transfer, but this offers no special properties to the transfer. If atransfer is assigned to a particular department, it can only be administered by super administrators orusers with FTAdminRight. Platform transfers do not have a visibility associated with them. Departmentadministrators can access or view transfers of their departments and transfers of the department thatthey can manage. When users with FTTransferRights log in to perform a Platform transfer, they can seeall the transfers that they are authorized to access.

Role Description


Department administrators can see transfers assigned to their departmentsand the departments that they can manage.

Department administrators can change the department to which the transferdefinition is assigned to their own departments or to any departments thatthey can manage.

Pay special attention when changing the department on a transferdefinition.

Super Administrator If super administrators update a transfer definition originally created bydepartment administrators, only the information that the departmentadministrators have access to can be used. Otherwise, an error occurs.

Super administrators can change the department to which the transferdefinition is assigned to any department in the system or to none.


117


Add/Execute Platform Transfer

Role Description


Department administrators can define a Platform transfer, and assign it totheir departments or any departments that they can manage.

By default, the Platform transfer is assign to the departments to which thedepartment administrators belong.

When selecting Initiator Platform Server, only servers assigned to thisdepartment, servers assigned to the departments that the departmentadministrator can manage, and servers from other departments with publicvisibility can be used.

Super Administrator Super administrators can define a Platform transfer, and assign it to anydepartment in the system or to none.

When selecting the Initiator Platform Server, servers assigned to anydepartments in the system can be used.

Manage Platform Transfers

Role Description


Department administrators can update, list, and delete any Platformtransfer that is assigned to their departments and the departments that theycan manage.

When selecting an Initiator Platform Server, only servers assigned to thisdepartment, servers assigned to the departments that the departmentadministrator can manage, and servers from other departments with publicvisibility can be used.

Department administrators can change the department to which thePlatform transfer is assigned to their own departments or to any departmentthat they can manage.


Super Administrator Super administrators can list, update, and delete any Platform transferdefinition in the system.

When selecting an Initiator Platform Server, servers assigned to anydepartments in the system can be used.

Super administrators can change the department to which the Platformtransfer is assigned to any department in the system or to none.


118


Platform User ProfilesPlatform administrative tasks can be limited by the rights that are assigned (or not assigned) to a user.In addition to AdministratorRight, administrative users can also be assigned FTAdminRight.

Add Platform User Profile

Role Description


Department administrators can add a Platform user profile to the database,and assign it to their own departments or to any departments that they canmanage.

By default, the Platform user profile is assigned to the departments to whichthe department administrators belong.

Super Administrator Super administrators can add Platform user profiles to any department inthe system.

Update Platform User Profile

Role Description


Department administrators can list, update, and delete Platform userprofiles assigned to their own departments and the departments that theycan manage.

Super Administrator Super administrators can list, update, and delete any Platform user profilein the system.

ServerServers can be assigned to departments and they can have a public or private visibility. Superadministrators are the only one who can perform the tasks of creating and configuring servers andassigning them to particular departments. Department administrators cannot add servers. Departmentadministrators can list all servers assigned to their departments and the departments they can manage.Department administrators can update servers assigned to their departments or the departments theycan manage.

Assigning private visibility to a server means that the server can be set as the server for a file transferfor a particular department. Servers can be associated with this server for public and private users orgroups in this department.

Assigning public visibility to a server means that in addition to the features granted by privatevisibility, the server can also be set as the value of the Server Name parameter in a file transfer assignedto another department. Public visibility also means that a server can be associated with this server forpublic users and groups belonging to another department. A server can only belong to one departmentin the system. The administrator can choose not to assign the server to a department, but this offers nospecial properties to the server.

UpdateServerRight supports users to update and view servers. ViewServerRight supports users to viewa server.

119


Add Server

Role Description



Super Administrator Super administrators can create a server which can be assigned to anydepartment in the system or set to none. A server that is not assigned to adepartment has no special properties.

Update Server

Role Description


Department administrators can update servers assigned to theirdepartments and the departments that they can manage.

Super Administrator Super administrators can update and delete all servers in the system.

The department to which the server is assigned can be changed to anydepartment in the system or to none.

Server CredentialsAdministrative tasks associated with severs credentials can be limited by the rights that are assigned(or not assigned) to a user. Department administrators cannot administer server credentials unless theyare given UpdateServerCredentialRight. Otherwise, super administrators are the only ones who canperform these tasks. Users and groups associated with server credentials can only be mapped to serversthat are assigned to their departments or public servers in other departments. A private user or groupin a department can never be mapped to a server that is not assigned to that department of that user orgroup.

ViewServerCredentialRight supports users to view credentials.

Add Server Credentials

Role Description


Department administrators cannot perform this task unless specificallygiven UpdateServerCredentialRight.

Super Administrator Super administrators can add a server credential to the system. Users andgroups can only be mapped to nodes that are assigned to their departmentsor public nodes in other departments.

Manage Server Credentials

Role Description


Department administrators can list, update, and delete server credentials ifthey are given the proper rights. In addition to AdministratorRight,administrative users must also be given UpdateServerCredentialRight toperform this function.

120


Role Description

Super Administrator Super administrators can list, update, and delete any server credentialdefinition in the system.

StatisticsOnly super administrators can perform these tasks.

System ConfigurationOnly super administrators can perform these tasks.

UsersUsers can be assigned to departments and they can have a public or private visibility.

Granting a user private visibility means the user can be added to public and private groups that areassigned to the user's department, the user can be set as the authorized user of transfer definitions thatare assigned to the user's department, and the user can have a server credential created for public andprivate servers assigned to the user's department.

Granting a user public visibility means the user can perform what a private user is capable to perform,can be added to a public group assigned to another department, can be set as the authorized user of atransfer definition that is assigned to another department, and can also have a server credential createdfor a public server assigned to another department. User IDs must be unique throughout the system,thus users in different departments cannot have the same user ID. A user can belong to only onedepartment in the system.

UpdateTransferUserRight supports users to update users who have only TransferRight. ViewUserRightsupports users to view users.

Add User

Role Description


Department administrators can create a user with TransferRight (default)and assign the user to their departments or any departments that they canmanage.

By default, the user is assigned to the departments to which the departmentadministrators belong.

Department administrators can assign users assigned to their departmentsor any departments that they can manage, the system administrative rightswithin these departments. This means department administrators cannotcreate super administrators, but they can create another administrator fortheir departments and any departments that they can manage.

The visibility of the users can be set to public or private. Setting visibilityto public makes the users visible and available for all other departmentadministrators in the system.

Super Administrator Same as department administrators but the user can be assigned to anydepartment in the system or to none at all.

Super administrators can create super administrators, departmentadministrators, and users with any available rights. If a user is not assignedto a department, the user gains no special properties. This means that theuser can only be administered by super administrators.

121


Add From Existing User

Role Description


Using this feature, department administrators can create a new user andassign the user to their departments or any departments that they canmanage.

By default, the user is assigned to the departments to which the departmentadministrators belong.

The new user can be created from a pre-existing user from the departmentsto which the department administrators belong, or from a pre-existing userfrom the departments that the department administrators can manage.

The new user are automatically given rights depending on the user that isbeing used as a template. However, department administrators cannot givethe new user any rights that they do not have. For example, a departmentadministrator who only has AdministratorRight cannot assignUpdateServerCredentialRight to a new user.

Super Administrator Using this feature, super administrators can create a user who can beassigned to any department in the system or to no department at all. Thenew user can only be created from any pre-existing user in the system andwill be given all the rights that the existing user possesses.

Manage User

Role Description


Department administrators can update users assigned to their departmentsand any departments that they can manage.

Department administrators can change the department to which the user isassigned to their own departments or to any departments that they canmanage.

Visibility of the user can be changed to public or private by departmentadministrators.

Super Administrator Super administrators can list, update, and delete all users in the system. Thedepartment that the user is assigned to can be changed to any department inthe system or to none at all. Visibility of the user can be changed to publicor private.

122


Platform Server Functionality

TIBCO MFT Platform Server can be configured and managed, and transfers can be initiated throughPlatform Server interfaces; these interfaces require access to the actual TIBCO MFT Platform Servercomputer. Most functions are executed through a command line program or by editing a configurationfile. Many of these functions can also be performed by MFTCC. MFTCC contains a single point atwhich many of these functions can be executed.

MFTCC is installed on an embedded J2EE application server. You can log onto MFTCC through a webbrowser to configure, manage, and perform transfers on TIBCO MFT Platform Servers.

The features that are supported by MFTCC are those that are often performed more frequently afterTIBCO MFT Platform Server is installed. The following table lists the supported functions.

All TIBCO MFT Platform Server systems support the functions listed in the following table. Theexisting command line utilities remain in the system and might still be used.

Function Description

Collector Retrieves information on completed transfers from TIBCO MFT Platform Serversystems and stores the information in a database.

Audit Polling Supports you to dynamically inquire on completed transfers on TIBCO MFTPlatform Server systems that are not utilizing the collector.

NodeConfiguration

Supports you to add, list, update, and delete TIBCO MFT Platform Server nodeentries.

User ProfileConfiguration

Supports you to add, list, update, and delete TIBCO MFT Platform Server userprofile entries.

ResponderProfileConfiguration

Supports you to add, list, update, and delete TIBCO MFT Platform Serverresponder profile entries.

PerformingTransfers

Supports you to perform file transfers between two TIBCO MFT Platform Serversystems.

Platform Server RequirementsTo perform TIBCO MFT Platform Server functions from TIBCO MFT Command Center, certainconfigurations must be made.

The following requirements must be fulfilled by TIBCO MFT Platform Server:

● Software Version

● Node Authentication

● Security Authentication

● Security Authorization

123


Software VersionTIBCO MFT Platform Server systems must be at version 6.0 or higher for TIBCO MFT CommandCenter Platform Server functions to execute. Prior releases do not support the new functionality.

Node AuthenticationTIBCO MFT Platform Server does not accept requests from any TIBCO MFT Command Center serversuntil they are configured to do so. TIBCO MFT Platform Server servers are required to define the actualTIBCO MFT Command Center servers from whom they will accept requests. This is done through aTIBCO MFT Platform Server node definition.

For each MFTCC system (typically only one with a possible backup server), a node definition must bebuilt, and the Command Center Support parameter must be set. This parameter supports you to definethe individual functions that can be performed by MFTCC. If a Platform node definition is not definedfor MFTCC, or if the Platform node definition does not support a particular function, the request isterminated and an error message is returned to the MFTCC user. Giving MFTCC the ability to performa Platform Server function does not mean that a user can perform that function. The user must still begiven the authorization to perform this function. For details on additional authentication andauthorization checking, see Security Authentication and Security Authorization.

The following table defines the options available to the Command Center Support parameter:

● NODE: supports TIBCO MFT Platform Server to accept TIBCO MFT Command Center requests toadd, list, update, and delete TIBCO MFT Platform Server node entries.

● PROFILE: supports TIBCO MFT Platform Server to accept TIBCO MFT Command Center requests toadd, list, update, and delete TIBCO MFT Platform Server user profile and responder profile entries.

● TRANSFER: supports TIBCO MFT Platform Server to accept TIBCO MFT Command Center requeststo initiate a transfer on this TIBCO MFT Platform Server to send a file to a different TIBCO MFTPlatform Server system.

● AUDIT: supports TIBCO MFT Platform Server to accept TIBCO MFT Command Center requests toview and retrieve information in the TIBCO MFT Platform Server audit log. TIBCO MFT CommandCenter Collector and Audit Polling functions require this option to be set on the TIBCO MFTPlatform Server node definition.

● ALL: supports TIBCO MFT Platform Server to accept all TIBCO MFT Command Center requests. Allof the functions within NODE, PROFILE, TRANSFER, and AUDIT are allowed.

● NONE: TIBCO MFT Platform Server does not support any TIBCO MFT Command Center requests.

Security AuthenticationTo maintain a secure environment, TIBCO MFT Platform Server must validate that the TIBCO MFTCommand Center user attempting to perform a TIBCO MFT Platform Server function is a valid user.

When a TIBCO MFT Command Center user attempts to perform a function, an encrypted user ID andpassword are passed from TIBCO MFT Command Center to TIBCO MFT Platform Server. TIBCO MFTPlatform Server verifies that the user is valid and that the password is valid for that user ID. Only afterthis validation is completed successfully can the TIBCO MFT Platform Server function be continued.

Security AuthorizationAuthentication of a user ID and password is only half the task. TIBCO MFT Platform Server must stillmake sure that the user is authorized to perform the TIBCO MFT Platform Server function. After a useris authenticated, TIBCO MFT Platform Server checks whether the authenticated user is authorized toperform the particular function.

The checking mechanism used to determine whether a user is authorized for a particular function is thesame as that used by the existing command line programs. The following tables list the function, andthe necessary rights that must be configured to support a user to use TIBCO MFT Command Center toperform a TIBCO MFT Platform Server function on each operating system. For more detailed

124


information on these features, see TIBCO Managed File Transfer Platform Server User’s Guide for theindividual platforms.

TIBCO MFT Platform Server for AS400 Authorization

Function Security Validation

Audit Polling

Collector

If the user has QSECOFR, the user is authorized to perform this function.

Otherwise, TIBCO MFT Platform Server checks whether the user is authorized tochange the following data areas: cfadmin, cfbrowse. If the user is authorized tochange one of these data areas, the user is authorized to perform this function.

ExecuteTransfers


Otherwise, TIBCO MFT Platform Server checks whether the user is authorized tochange the following data areas: cfadmin, cfbrowse. If the user is authorized tochange one of these data areas, the user is authorized to perform this function.

Node

User Profile

ResponderProfile


Otherwise, TIBCO MFT Platform Server checks whether the user is authorized tochange the following data area: cfadmin. If the user is authorized to change thisdata area, the user is authorized to perform this function.

TIBCO MFT Platform Server for UNIX Authorization


Audit Polling

Collector

If the user is a root user (or UID=0), the user is authorized to perform thisfunction.

Otherwise, TIBCO MFT Platform Server checks whether the user is a member ofone of the following two UNIX groups: cfadmin, cfbrowse. If the user is amember of either group, the user is authorized to perform this function.

ExecuteTransfers


Otherwise, TIBCO MFT Platform Server checks whether the user is a member ofone of the following two UNIX groups: cfadmin, cfbrowse. If the user is amember of either group, the user is authorized to perform this function.

Node

User Profile

ResponderProfile


Otherwise, TIBCO MFT Platform Server checks whether the user is a member ofthe following UNIX group: cfadmin. If the user is a member of this group, theuser is authorized to perform this function.

TIBCO MFT Platform Server for Windows Authorization

125



Audit Polling

Collector

If the user is a Windows administrator, the user is authorized to perform thisfunction.

Otherwise, TIBCO MFT Platform Server checks whether the user is a member ofone of the following two Windows groups: cfadmin, cfbrowse. If the user is amember of either group, the user is authorized to perform this function.

ExecuteTransfers


Otherwise, TIBCO MFT Platform Server checks whether the user is a member ofone of the following two Windows groups: cfadmin, cfbrowse. If the user is amember of either group, the user is authorized to perform this function.

Node

User Profile

ResponderProfile


Otherwise, TIBCO MFT Platform Server checks whether the user is a member ofthe following Windows group: cfadmin. If the user is a member of this group,the user is authorized to perform this function.

TIBCO MFT Platform Server for z/OS Authorization


Audit Polling

Collector

TIBCO MFT Platform Server checks two RACF (or ACF2 or Top Secret) facilityclasses defined in the TIBCO MFT Platform Server GLOBAL configuration:CCC_ADMIN_FACILITY, CCC_BROWSE_FACILITY.

If the user has read authorization for either facility class, the user is authorized toperform this function.

ExecuteTransfers

TIBCO MFT Platform Server checks two RACF (or ACF2 or Top Secret) facilityclasses defined in the TIBCO MFT Platform Server GLOBAL configuration:CCC_ADMIN_FACILITY, CCC_TRANSFER_FACILITY.

If the user has read authorization for either facility class, the user is authorized toperform this function.

Node

User Profile

ResponderProfile

TIBCO MFT Platform Server checks the RACF (or ACF2 or Top Secret) facilityclass defined by the GLOBAL CCC_ADMIN_FACILITY resource.

If the user has read authorization for this facility class, the user is authorized toperform this function.

MFTCC ConfigurationTo perform TIBCO MFT Platform Server functions from TIBCO MFT Command Center, you have tocreate server definitions and server credential definitions for TIBCO MFT Platform Server in TIBCOMFT Command Center.

For more information of server definitions and server credential definitions in TIBCO MFT CommandCenter, see the following introductions:

● MFTCC Server Definitions

126


● MFTCC Server Credential Definitions

MFTCC Server DefinitionsBefore performing any TIBCO MFT Platform Server functions within TIBCO MFT Command Center,you must first define TIBCO MFT Platform Servers to TIBCO MFT Command Center.

This is done through a MFTCC server definition. You can add a server definition through the AddServer page which can be accessed by clicking Servers > Add Server. You must complete theinformation in the Required Server Information section. Make sure that you define the Server Typeparameter as Platform Server and set the Server Platform parameter to the platform that TIBCOMFT Platform Server is running on. To perform TIBCO MFT Platform Server functions for this serverdefinition, you must select the Manage Platform Server box in the Management Options section. Theother entries within this section are used by the Collector (see MFTCC User ID and Password Rules fordetailed information of these entries).

The Server Credentials section supports you to assign a default TIBCO MFT Platform Server user IDand password to be used if the user ID and password are not provided in other TIBCO MFT CommandCenter definitions. Take special attention about defining users with a lot of rights in this definition,because this are the default user ID and password if TIBCO MFT Command Center does not overridethe requests through another definition. For more information of TIBCO MFT Platform Server user andpassword, see MFTCC User ID and Password Rules.

MFTCC Server Credential DefinitionsServer credentials support you to define in a more granular fashion the user ID and password thatshould be used when communicating with TIBCO MFT Platform Server.

While server definitions support you to define a default TIBCO MFT Platform Server user ID andpassword for all TIBCO MFT Command Center users, server credentials support you to specify aTIBCO MFT Platform Server user ID and password to be used when a Platform Server request is madeby a specific TIBCO MFT Command Center user.

You can create a server credential through the Add Server Credentials page which can be accessed byclicking Servers > Server Credentials > Add Server Credentials. You must complete the information inthe Required Server Credential Information section. Wherein, the User parameter defines the TIBCOMFT Command Center user performing a TIBCO MFT Platform Server function, while the ServerName parameter defines the TIBCO MFT Command Center server entry that defines the TIBCO MFTPlatform Server system. The Remote User Id and Remote User Password parameters define theencrypted user ID and password to be sent to the TIBCO MFT Platform Server system when a TIBCOMFT Command Center Platform Server function is executed.

For example, assume that the TIBCO MFT Command Center administrator creates a TIBCO MFTCommand Center user definition called TechSupp and a TIBCO MFT Command Center serverdefinition called NYMFT Platform Server1 that is configured to communicate with TIBCO MFTPlatform Server. The user TechSupp now wants to communicate with the server NYMFT PlatformServer1. To perform any TIBCO MFT Command Center function on this server, you need a user IDand password that is valid on the server NYMFT Platform Server1. This user ID and password areused whenever the user TechSupp performs a TIBCO MFT Command Center function that requires it tocommunicate with the server NYMFT Platform Server1.

In this example, you build the following server credential:

Parameter Value

User TechSupp

Server Name NYMFT Platform Server1

127


Parameter Value

Remote User Id TSUSER1: the name of the user on the system NYMFT PlatformServer1.

Remote Password abc123: the password for the user TSUSER1.

Confirm Password abc123: the same information as for the Remote Passwordparameter.

If the system NYMFT Platform Server1 defines a Windows computer, you must also define theRemote User Windows Domain parameter in the Windows Properties section.

After defining all the parameters, click Add to add the server credential information. Now, wheneverthe user TechSupp initiates a TIBCO MFT Command Center request that requires TIBCO MFTCommand Center to communicate with the TIBCO MFT Platform Server system NYMFT PlatformServer1, the encrypted user ID TSUSER1 and the password abc123 are sent to the TIBCO MFT PlatformServer system NYMFT Platform Server1.

MFTCC User ID and Password RulesWhen TIBCO MFT Command Center communicates with TIBCO MFT Platform Server systems, it triesto obtain user ID and password credentials from certain definitions in a certain order.

The following table lists where TIBCO MFT Command Center obtains user ID and passwordcredentials when communicating with TIBCO MFT Platform Server systems. The entries in this tableare listed in the order that checking is performed. If a user ID and password are found, that user ID andpassword are used and no additional checking is performed.

FunctionDefinitions Checked for TIBCO MFT Platform Server User ID andPassword

Node

User Profile

Responder Profile

The following definitions are checked:

● The server credential for the TIBCO MFT Command Center user forthat TIBCO MFT Command Center server.

● The Server Credentials section of the server definition on the AddServer page.

If user ID and password are not defined in the above definitions, therequest terminates with an error.

Transfer The following definitions are checked:

● The Initiator User Id and Initiator Password parameters in theCredentials and Security Properties section of a Platform transferdefinition on the Add/Execute Platform Transfer page.


● The Server Credentials section of the server definition.


128


FunctionDefinitions Checked for TIBCO MFT Platform Server User ID andPassword

Platform ServerManual Poll

The following definitions are checked:




Collector The following definitions are checked:

● The server credential for the user Collector for that TIBCO MFTCommand Center server.



User IDs and Passwords within Platform Server Transfers

TIBCO MFT Command Center requires a user ID and password to log onto the system. TIBCO MFTPlatform Server authentication requires that the TIBCO MFT Platform Server initiator and respondersystems have a user ID and password to perform a transfer. Therefore, three user IDs and passwordsare required to perform a transfer.

TIBCO MFT Command Center and TIBCO MFT Platform Server both have facilities to automaticallygenerate and send the user ID and password to the remote systems. The following table describes theuser IDs and passwords and explains how they can be defined.

Authentication Description

TIBCO MFTCommand CenterLogin

This user ID and password is input by the user when logging onto TIBCOMFT Command Center using a web browser.

The command line configuration program encrypts and adds the user ID andpassword in the global.xml file.

TIBCO MFTPlatform ServerInitiator

This information can come from one of three places in the order as describedin MFTCC User ID and Password Rules:

● From the Platform transfer definition.

● From a server credential definition.

● From the Server Credentials section in a server definition. This is thedefault values used for any request to this server.

If the information is not defined on one of the above ways, the requestterminates with an error.

The best way to define the TIBCO MFT Platform Server initiator user ID andpassword is by defining a server credential for the user and servercombination.

129


Authentication Description

TIBCO MFTPlatform ServerResponder

When the TIBCO MFT Platform Server initiator receives a request from TIBCOMFT Command Center, it then communicates with the TIBCO MFT PlatformServer responder to start the file transfer request. The responder user ID andpassword can come from the following places in the order as described in MFTCC User ID and Password Rules:

● From the Platform transfer definition.

● From a user profile defined to the TIBCO MFT Platform Server initiator.When the transfer is initiated on the Platform Server, the Platform Serverscans its user profile definitions for a match on the initiating user ID andthe target node. If a match is found, the responder user ID and passworddefined by the user profile is used for the file transfer.

● TIBCO MFT Platform Server sends a trusted user to the remote TIBCOMFT Platform Server. It is up to the remote system whether the trusteduser request is accepted. TIBCO MFT Platform Server for Windows doesnot support trusted users, and the other platforms must be configured toaccept trusted users.

130


Extended Features

MFTCC provides several extended features such as directory transfers, email notification, file tokensubstitution, multi-language support, LDAP support, and Admin Client Utility that can be used withTIBCO MFT Platform Server.

Admin Client UtilityAdmin Client Utility is designed for the administrator to conduct administrative operations throughcommand line on Windows and UNIX platforms. It can be invoked from a batch file, a UNIX script, andexecuted in unattended mode by a job scheduler for ease of use.

Calling Admin Client Utility from Platform ServerWhen a MFTCC transfer is created on a computer, the MFTCC database must be updated to add thetransfer information so that the transfer can be made available to MFTCC users.

You can run Admin Client Utility through one of the following two ways:

● By executing the utility locally. This means that the machine that runs the utility must be installedwith and configured for Admin Client Utility. Likewise, the proper version of Java needed byAdmin Client Utility must be downloaded for that machine.

● By executing a TIBCO MFT Platform Server request on any computer that supports TIBCO MFTPlatform Server. The target TIBCO MFT Platform Server computer must be installed with andconfigured for Admin Client Utility before this method can be used.

For more information on how to execute the Admin Client Utility via TIBCO MFT Platform Servertransfer request, see Executing Admin Client Utility from Platform Server.

For more information of how to install and configure the Admin Client Utility, see TIBCO Managed FileTransfer Command Center Command Line Utilities Guide.

Executing Admin Client Utility from Platform Server

You can run Admin Client Utility by executing a Platform Server request on any computer thatsupports TIBCO MFT Platform Server.

You can call Admin Client Utility through TIBCO MFT Platform Server through the following twoways:

● By executing a TIBCO MFT Platform Server command. In this method, when a file is madeavailable, TIBCO MFT Platform Server can send a remote command to the target TIBCO MFTPlatform Server where TIBCO MFT Command Center Admin Client Utility is running. This is themost flexible method of calling Admin Client Utility. TIBCO MFT Platform Server on any computercan execute this call to any version of TIBCO MFT Platform Server that is running Admin ClientUtility.

● By running a TIBCO MFT Platform Server file transfer to a remote computer. You can specify a postprocessing action (PPA) either locally or remotely that executes the Admin Client Utility command.The advantage of using this method is that the process of transferring the file and executing AdminClient Utility is a one-step process. Admin Client Utility can be executed either locally or remotely.But CFAdmin (the name of the Admin Client Utility batch job) must run on either the local orremote TIBCO MFT Platform Server computer. You cannot execute the utility on a differentcomputer using this methodology.

131


Executing Admin Client Utility as Platform Server CommandWhen you execute a TIBCO MFT Platform Server remote command, Admin Client Utility must beinstalled and configured on the remote TIBCO MFT Platform Server computer.

To execute a remote command through TIBCO MFT Platform Server, you must make the followingdefinitions:

● Define the transfer as a send request.

● Define the transfer type as command.

● Define the remote command to be executed.

● Configure parameters that define the remote node.

Although you can enter spaces within a TIBCO MFT Command Center parameter such as theDescription parameter; it is good practice to not have any imbedded spaces in a parameter. This isbecause the Java implementations differ slightly over different platforms. Imbedding spaces within aparameter might cause problems with the command line. Therefore, if you want to add a descriptionfor a file you can add it as Description: Tax_Upload_YEAR_2005.

For samples of the parameters that can be used to send a remote command on different platforms, seethe following introductions:

● Executing MFTCC Commands Using Platform Server for z/OS Batch Jobs

● Executing MFTCC Commands as Part of Platform Server for UNIX Transfers

Executing MFTCC Commands Using Platform Server for z/OS Batch Jobs

You can execute TIBCO MFT Command Center commands through the batch interface of TIBCO MFTPlatform Server for z/OS.

The following example is a sample of using the batch interface to send a remote command:PROCESS,SENDMFT,TRANSFER,SEND TRANS_TYPE=COMMAND EXEC="/cfcc/cfccmf.sh upload ++ cfn:c:\temp\testabc ++ sfn:/tmp/testabc.upload ++ d:testabc_Upload_file ++ nn:NYNODEMFT ++ uid:acctuser" NODE=MFTNODE RUSER=*PROFILE TRY=1 WAIT=YES

The features of the above commands are as follows:

● The PROCESS statement defines that this is a send request.

● TRANS_TYPE=COMMAND defines that the system is sending a command rather than a file.

● The EXEC statement defines the command that should be executed. The command in the example ismeant to be executed on a UNIX system running both TIBCO MFT Platform Server and TIBCO MFTCommand Center Admin Client Utility. The utility is stored in the /cfcc directory. The scriptcfccmf.sh is created to execute this command. As the command shows, it uses an action filetemplate. In this case, the template is called upload.xml. Because it uses a template, it can use theshortcut names such as CFN (client file name) and SFN (server file name).

● The NODE command defines the name of the remote node. The MFTNODE node must be defined toTIBCO MFT Platform Server and enabled either at startup or through the ENA command for this towork properly.

132


● The RUSER parameter defines that a user profile should be used to define the remote user ID andpassword. Alternately, you can enter the remote user ID (the RUSER parameter) and remotepassword (the RPASS parameter).

● TRY=1 indicates that you can only try to execute the command for one time.● WAIT=YES means that you should wait for the command to complete rather than for the request to be

scheduled.

If a parameter is not defined in the EXEC statement, the value in the template is used. If the value is notdefined in either the EXEC statement or the template, a default value is used.

upload.xml is the name of the XML file that contains the XML data for this request. You must createthe upload.xml file from the addfile.xml file that is included with MFTCC Admin Client Utility.

The syntax for the EXEC statement is important. Because the EXEC statement is too long to fit onto oneline, continuation is used to continue the parameter from one line to another. If you use double plussigns (++) to continue the parameter from one line to another, it is important that you understand howdouble plus signs (++) continuation works. When you use double plus signs (++) at the end of a line,TIBCO MFT Platform Server takes the current line and appends a space to the last non-blank character,and then appends the first non-space character on the next line. That means that the TIBCO MFTPlatform Server batch interface embeds a single space between the last non-space character of thecurrent line and the first non-space character of the next line.

The batch interface runs as a stand-alone step. It is useful to use the batch interface to call MFTCC whena file is created by a user application. The following typical jobs are run:

1. Create the file.

2. Execute the MFTCC command.

If you are using TIBCO MFT Platform Server to create a file on a remote system, and then want to addthe file to TIBCO MFT Command Center definitions, you can use the TIBCO MFT Platform Serverscript interface. The following example is a sample script job that you can run to transfer a file to aremote system, and then add the file to MFTCC definitions.CALL SENDMFTFILE IF %RC <> 0 then SAY SEND MFT Command Center transfer terminated with RC=%RC EXIT 200 ENDIF CALL SENDMFTCOMMAND IF %RC <> 0 then SAY SEND MFT Command Center command terminated with RC=%RC EXIT 201 ENDIF SAY MFT Command Center File and Command transferred successfully EXIT 0 :SENDMFTFILE PROCESS,SENDFILE,TRANSFER,SEND LF=prod.testabc RF=/tmp/testabc.cfcc NODE=NYNODE RUSER=*PROFILE TRY=1 WAIT=YES RETURN :SENDMFTCOMMAND PROCESS,SENDMFT,TRANSFER,SEND TRANS_TYPE=COMMAND EXEC="/cfcc/cfccmf.sh ++ download ++ cfn:C:\temp\testabc ++ sfn:/tmp/testabc.cfcc ++

133


d:testabc_Download_file ++ nn:NYNODEMFT ++ uid:acctuser" NODE=MFTNODE RUSER*PROFILE TRY=1 WAIT=YESRETURN

The first step transfers a file to the NYNODE node. If that transfer is successful, the second step sends acommand to the MFTNODE node to create a MFTCC file record. When the user acctuser logs ontoMFTCC and requests a list of files, this file is made available to the user. This is still dependent on otherfields in the file record such as the Available date, Expiration Date, and Disable Flag fields amongothers.

The following information shows the processes of this task:

1. The PROD.TESTABC file is created on the z/OS system.

2. TIBCO MFT Platform Server transfers the PROD.TESTABC file to the NYNODE system as the firsttransfer in a TIBCO MFT Platform Server script.

3. TIBCO MFT Platform Server sends a command to the TIBCO MFT Platform Server node,MFTNODE. The MFTNODE node is configured to process TIBCO MFT Command Centercommands. The EXEC statement defines the MFTNODE node to add a file record for the useracctuser. The file record is added for the TIBCO MFT Command Center node, NYNODEMFT.

The NYNODEMFT node and the user acctuser must be defined to TIBCO MFT CommandCenter before the above command can be executed.

4. the user acctuser logs onto TIBCO MFT Command Center, and requests a list of files that areavailable.

5. The file defined as ClientFileName(CFN):C:\temp\testabc and Description (D):testabc_Download_file is then listed on the user's browser.

6. The user requests that TIBCO MFT Command Center transfer the file. TIBCO MFT CommandCenter transfers the /tmp/testabc.cfcc file from the NYNODEMFT node to the user’s computer.The local file is called c:\temp\testabc.

The user has the capability of overriding the ClientFileName parameter (for example,local file name) but cannot change the Node or ServerFileName parameter.

Executing MFTCC Commands as Part of Platform Server for UNIX Transfers

You can execute TIBCO MFT Command Center commands through the batch interface of TIBCO MFTPlatform Server for UNIX.

The following example is a sample of using the batch interface to execute MFTCC Admin Client Utilityas a remote command:cfsend n:MFTnode trtype:command rcmd="/cfcc/cfccmf.sh upload cfn=C=\temp\testabc sfn=/tmp/testabc.cfcc d=testabc_Upload nn=NYNODEMFT"

The command above is a single line within the UNIX command line. Alternately, you can create aTIBCO MFT Platform Serve for UNIX template file with all of the above information, and process theentire request through the following command:

cfsend t:cfccTemplate

The features of the above commands are as follows:

● The cfsend parameter indicates that this is a send request. This parameter is required.

134


● n:MFTnode defines the remote TIBCO MFT Platform Server node that is configured to processTIBCO MFT Command Center requests. This node must be defined to CFUNIX through the cfnodecommand.

● trtype:command defines that a command is passed to the remote system.● The rcmd parameter defines the command to be executed on the remote system. Because the rcmd

parameter contains embedded spaces, you have to enclose the remote command in doublequotation marks.

Based on the configuration of the local and remote TIBCO MFT Platform Server systems, you mighthave to add user ID and password information to the above command.

Executing Internet Server File Transfer as a Post Processing ActionBy using post processing actions, you can define up to four actions to be completed by the respondingserver when a file transfer request is completed.

If you have TIBCO MFT Internet Server installed, you can use this function to execute an MFT InternetServer Command Line Client command as a post processing action (PPA). The advantage of doing thisis that you can perform a file transfer and then execute for instance, a file transfer command line utilitycommand within a single step. See TIBCO Managed File Transfer Internet Server Command Line UtilitiesGuide for more information about Internet Server Command Line Client.

Internet Server Command Line Client must be installed and configured on the system where the filetransfer runs.

When using PPA to initiate an MFT Internet Server Command Line Client command or any commandfor that matter, it is good practice to get the command running successfully in batch mode first. For thisexample, first use the file transfer command for Internet Server Command Line Client to ensure that therequest is executed successfully. After the command is run successfully, you can add it as a PPArequest.

Assume that you want to upload a file to TIBCO MFT Internet Server, and after that file transfer requestis completed, you want to launch a script that uses Internet Server Command Line Client to send thatfile to another MFT server.

You first make sure your Internet Server command ran successfully from a batch job by testing it; seethe following example (the file name is UploadScript.cmd):cd InternetCommandLinecall setutilcpjava cfcc.CFInternet a:ProcessFile Description:UploadToAIX

After the command is tested, add the script to a post processing action in your MFTCC transferdefinition.

After that, each time this transfer request is run, this PPA starts upon the success of the file transfer.

Configuring the Target MFTCC SystemMFTCC comes with a script that works when you issue Admin Client Utility commands. When youwant to execute the Admin Client Utility command as part of a file transfer request, you must create anew script that is tailored for the environment that you are running.

For information of how to generate the script for Windows and UNIX environments, see the followingintroductions:

135


● Configuring Windows Environment● Configuring UNIX Environment

Configuring Windows Environment

When you want to execute the Admin Client Utility command as part of a file transfer request inWindows environment, you must create a new script that is tailored for the Windows environment.

When the Admin Client Utility client (CFAdmin) is installed on a Windows computer, a file calledcfcc.bat is created.

The following example uses a copy of the cfcc.bat file called cfccmf.bat. It is the base program withsome additional parameters set in it.e:cd \cfcc\MFTAdminCLset PATH=%PATH%;c:\program files\java\jre1.8.0_66\bin; ;call setutilcpjava cfcc.CFAdmin t:%1.xml %2 %3 %4 %5 %6 %7 %8 %9

The above script performs the following functions:

● It sets the drive to the drive where the cfccmf.bat file is located. In this case, the cfccmf.bat file islocated on the E: drive.

● It sets the directory to the directory where the cfccmf.bat file is located. In this case, thecfccmf.bat file is located in the \cfcc\MFTAdminCL directory.

● It sets the PATH parameter to include the Java JRE (Java Runtime Environment). If the correct JRE isalready included in the path, this step can be skipped.

● It calls the setutilcp.bat file included with MFTCC Admin Client Utility. This file sets upenvironment variables needed by Java to execute.

● The last statement is the actual Java command that executes Admin Client Utility. Admin ClientUtility is named CFAdmin. The first parameter (t:%1.xml) shows that the first parameter enteredshould be the name of the XML template file without the .xml suffix. Parameters %2 - %9 supportyou to override up to 8 parameters defined in the template XML file.

Even on Windows, the Java program name (CFAdmin) is case sensitive.

Configuring UNIX Environment

When you want to execute the Admin Client Utility command as part of a file transfer request in UNIXenvironment, you must create a new script that is tailored for the UNIX environment.

When the Admin Client Utility client (CFAdmin) is installed on a UNIX computer, a file called cfcc.shis created.

The following example uses a copy of the cfcc.sh file called cfccmf.sh. It is the base program withsome additional parameters set in it.#!/usr/bin/kshcd /cfcc# Set the PATH to include the Java JREexport PATH=./:/usr/AppServer/java/bin:$PATH# Set the Java environment variables (copied from setutilcp.sh)export CLASSPATH=.:ClientCommon.jar:axis-ant.jar:axis.jar:commons-discovery.jar:commons-logging.jar:jaxrpc.jar:log4j-1.2.4.jar:saaj.jar:wsdl4j.jar:trace.jar:CFAdmin.jar:jcert.jar:jnet.jar:jsse.jar:xalan.jar:xercesImpl.jar:xmlParserAPIs.jar# Execute the Java CFAdminjava cfcc.CFAdmin t:$1.xml $2 $3 $4 $5 $6 $7 $8 $9

The above script performs the following functions:

136


● The first line (#!/usr/bin/ksh) is required and defines the UNIX system to use the korn shell toexecute this procedure.

● It then sets the directory to the directory where the cfccmf.sh file is located. In this case, thecfccmf.sh file is located in the /cfcc directory.

● The export PATH statement updates the PATH parameter to include the JRE (Java RuntimeEnvironment) executable files. If the default path includes this directory, this step is not needed.

● The export CLASSPATH statement was copied from the setutilcp.sh script. This sets up the Javaenvironment variables. Although it looks like four lines of data, it is actually one long statement.

● The last statement is the actual Java command that executes Admin Client Utility. Admin ClientUtility is named CFAdmin. The first parameter (t:%1.xml) shows that the first parameter enteredshould be the name of the XML template file without the .xml suffix. Parameters %2 - %9 supportyou to override up to 8 parameters defined in the template XML file.

The Java program name (CFAdmin) is case sensitive.

Template UsersFive template users are added to the database during the MFTCC installation process. Other users canthen be added based on these templates by using the Add From Existing User link on the Add Userpage. Any rights assigned to a template user are also copied to a new user.

The following table lists the template users:

Template User ID Assigned Rights

admin AdministratorRight

TransferRight

HelpDeskUser HelpDeskRight

UpdateSessionRight

ViewAlertRight

ViewAuditRight

ViewGroupRight

ViewUserRight

TransferUser TransferRight

AuditorUser ViewAlertRight

ViewAuditRight

ViewGroupRight


ViewServerRight


ViewUserRight

A Collector ID is also added by default. This ID is used to create server credentials for servers that alsohave the collection option turned on. No rights are given to this ID.

137


MFTCC SOAP APIMFTCC provides two public web services that can be used by a developer to access, control, andintegrate MFTCC with a third party application. The Administrator web service is used to configureand administer MFTCC. The File Transfer web service is used to perform file transfers. Simple ObjectAccess Protocol (SOAP) is used to describe and access the MFTCC web services.

A copy of the SOAP specification can be found at http://www.w3.org/TR/SOAP/ . HTTPS is thepreferred network protocol to be used to access MFTCC web services.

Documentation for each of the web services is provided in javadoc format. You can find thedocumentation in HTML format in the docs.zip file located in docs directory under the directorywhere MFTCC is installed (namely, where the cfcc.jar file is unpacked). Contact the administratorthat installed MFTCC to send you this docs.zip file. Extract the file into any directory. Double-click theindex.html file to get a list of all the packages and classes.

The interfaces of both the Administrator service and the File Transfer service are published on theMFTCC server in a WSDL format.

To access the Administrator service, navigate to the following URL with your browser: https://[DNS_HostName]:[httpsPort]/cfcc/control?view=services/AdministratorService?WSDL.

To access the File Transfer service, navigate to the following URL with your browser: https://[DNS_HostName]:[httpsPort]/cfcc/control?view=services/FTService?WSDL.

Both WSDL files can be used by most major SOAP 1.1 compliant implementations to access each of theMFTCC web services. For examples on how to access web services, see your SOAP implementationdocumentation.

For information of how to use the Administrator service and File Transfer service, see the followinginstructions:

● Using MFTCC Administrator Service

● Using MFTCC File Transfer Service

Using MFTCC Administrator ServiceYou can use Simple Object Access Protocol (SOAP) to describe and access the MFTCC Administratorweb service.

Procedure

1. Contact the Administrator service at the following URL:https://[DNS_HostName]:[httpsPort]/ContextName/control?view=services/AdministratorService

2. Execute the getSession method of the Administrator service.This call returns a session string that is to be used in all further contact to the Administrator service.

3. Execute all other service methods needed to perform the required task.

4. Execute the closeSession method of the Administrator service.This closes the current session.

138


http://www.w3.org/TR/SOAP/

Using MFTCC File Transfer ServiceYou can use Simple Object Access Protocol (SOAP) to describe and access the MFTCC File Transfer webservice.

Procedure

1. Contact the File Transfer service at the following URL:https://[DNS_HostName]:[httpsPort]/ContextName/control?view=services/FTService

2. Execute the getSession method of the File Transfer service.This call returns a session string that is to be used in all further contact to the File Transfer service.

3. Execute all other service methods needed to perform the required task.

4. Execute the closeSession method of the File Transfer service.This closes the current session.

Java Applet

To perform a file transfer, MFTCC File Transfer Java applet must be used.

The File Transfer applet consists of three .jar files. They are located in the following directories on theMFTCC server:

● <MFT_Install>/view/filetransfer/java/JavaApplet_0.0.0.1.jar

● <MFT_Install>/view/filetransfer/java/httpcore-4.3.2.jar

● <MFT_Install>/view/filetransfer/java/httpcore-nio-4.3.2.jar

The File Transfer applet can be embedded in an HTML page, or it can be embedded in a Javaapplication. The following HTML code snippet embeds the File Transfer applet into HTML page thatcan only be accessed by Microsoft Internet Explorer:<object ID = "FileTransferApplet" classid = "clsid:CAFEEFAC-0014-0001-0003-ABCDEFFEDCBA" width = "1" height = "1"> <param name="CODE" value= "com.TIBCO.cfcc.fileTransferApplet.nongui.NonGUIApplet.class"> <param name="ARCHIVE" value = “[Path to File Transfer Applet jar files]”> <param name="FileTransferServletURL" value="https://[DNS HostName]:[httpsPort]/cfcc/control?view=servlet/fileTransfer"> <param name="TransferDirection" value= "[SEND or RECEIVE]"> <param name="FileID" value= "[File ID to be transferred]"> <param name="LocalFileName" value= "[File name as it exists on client]" > <param name="SessionID" value= "[Session ID retrieved from service getSession call]"> <param name="Compression" value="[Yes or No]"> <param name="TraceLevel" value=”[TraceLevel 1-10]”> <param name="type" value= "application/x-java-applet;version=1.6.0">

<comment> <embed type="application/x-java-applet;jpi-version=1.6.0" java_CODE="com.TIBCO.cfcc.fileTransferApplet.nongui.NonGUIApplet. class" java_ARCHIVE= "[Path to File Transfer Applet jar files]" WIDTH="1" HEIGHT="1"

FileTransferServletURL=" https://[DNS HostName]:[httpsPort]/cfcc/control?view=servlet/fileTransfer"

139


TransferDirection="[SEND or RECEIVE]" FileID="[File ID to be transferred]" LocalFileName="[File name as it exists on client]" SessionID="[Session ID retrieved from service getSession call]" Compression="[Yes or No]" TraceLevel="[TraceLevel 1-10]" MAYSCRIPT=true > <noembed> No Java 2 SDK, Standard Edition v 1.8 support for APPLET!! </noembed> </embed> </comment></object>

The following code snippet embeds the File Transfer applet into a Java application:System.setProperty("FileTransferServletURL", "https://[DNSHostName]:[httpsPort]/cfcc/control?view=servlet/fileTransfer");System.setProperty("SessionID", "[Session ID retrieved from service getSession call]");System.setProperty("TransferDirection", "[SEND or RECEIVE]");System.setProperty("FileID", "[File name as it exists on client]");System.setProperty("LocalFileName", "[File name as it exists on client]");System.setProperty("Compression", "[Yes or No]"); theApplet =new NonGUIApplet();theApplet.setStub(this);this.setApplet(theApplet);theApplet.init();theApplet.start();status=((NonGUIApplet)theApplet).getReturnCode(); bytes=((NonGUIApplet)theApplet).getBytesTransfered();compressedBytes=((NonGUIApplet)theApplet).getCompressedByte();

The System.setProperty method is used to pass initialization parameters to the File Transfer applet.

Applet Wrapper

MFTCC uses a Java applet to transfer files. For ease of use, MFTCC provides a wrapper class,SIFTSingleFileTransfer, to wrap the details of how to use the applet. You can create an instance of theclass, set necessary parameters, and then transfer a file. The class performs one file transfer at a time.

See Using Applet Wrapper for more information on how to use the applet wrapper.

Required Concepts

Before you can use the applet wrapper to transfer a file, you should understand the following conceptsand working flow used by MFTCC.

The definitions and explanations given here might be different than those defined in other parts of thisdocumentation. The definitions and explanations here are for developers to understand the internalworking flow of MFTCC for transferring a file so that they can use SOAP calls to get the necessaryinformation about a file and then use this applet wrapper to transfer a file.

File Record

A file record is a record in the MFTCC database that represents a file. You can view all properties of afile using the web interface or the command line utility (the Platform Transfer Client Utility reveals lessinformation than the Admin Client Utility). The important properties for file transfer are as follows:

Property Description

FileId This property must be used to set the fileID value of the applet wrapper.

140


Property Description

SendRecvFlag This is a flag which indicates the transfer direction.

The transferDirection parameter of the applet wrapper must be set accordingto this value.


● S: SEND

● R: RECEIVE

CompressType This is a flag which is used to indicate whether the transfer is compressed.

The compression parameter of the applet wrapper must be set according tothis value.


● 0: NO

● 1: YES

ChkptRestartFlag This is a flag which indicates whether checkpoint restart is enabled for thetransfer.

The restartTransfer parameter of the applet wrapper must be set according tothis value.


● 0: NO

● 1: YES

ChkptInterval This property specifies the checkpoint interval in seconds.

The checkpointInterval parameter of the applet wrapper must be setaccording to this value.

The value in file record is in minutes. If you set the checkpointIntervalparameter according the value in file record, you must convert the value inminutes to a value in seconds by multiplying by 60.

DirectoryTransfer This is a flag to indicate whether the transfer is a directory transfer.

The applet wrapper acts differently for a directory transfer. For more detailson directory transfers, see Directory Transfers using Platform Command LineUtility.


● 1: directory transfer.

● 0: not a directory transfer.

Directory Transfer

MFTCC can transfer a whole directory to or from the server. Inside the implementation, MFTCC cantransfer one file at a time to fulfill the directory transfer.

141


Before any file transfer, the user must know whether the transfer is a file transfer or a directory transferby selecting DirectoryTransfer in the file record. If it is a file transfer, set the necessary parameters ofthe applet wrapper (for details of the parameters, see Class Parameters) and perform the transfer. If it isa directory transfer, it contains the following two situations:

● Directory upload: set the localFileName parameter of the applet wrapper and transfer each file inthe directory same as a normal file transfer.

● Directory download: set the serverFileName parameter of the applet wrapper and download eachfile in the directory of the server. The server file name is the file name specified by the server foreach file under its directory.

Getting the Directory File List

To get server file names for directory download, in file record for directory download, use thegetDirectoryFileList() method of the file record to return FTClient.DirectoryElementList[], an array ofFTClient.DirectoryElementList, which represents the structure of the directory to be downloaded. Youshould parse the structure to get the entire list of server file names.

Major part of source code of this class (extracted from the FTClient.jar file) is as follows:package FTClient;

public class DirectoryElementList implements java.io.Serializable { private java.lang.String elementName; private java.lang.String elementType; private FTClient.DirectoryElementList[] subDirectoryList;

public DirectoryElementList() { }

public java.lang.String getElementName() { return elementName; }

public void setElementName(java.lang.String elementName) { this.elementName = elementName; }

public java.lang.String getElementType() { return elementType; }

public void setElementType(java.lang.String elementType) { this.elementType = elementType; }

public FTClient.DirectoryElementList[] getSubDirectoryList() { return subDirectoryList; }

public void setSubDirectoryList(FTClient.DirectoryElementList[] subDirectoryList) { this.subDirectoryList = subDirectoryList;}

…}

If the value of the elementType parameter is F, this element is the leaf node and the elementNameparameter is a server file name. If the value of the elementType parameter is D, this element is asubdirectory and you should go into the directory, maybe recursively, to find the file name.

142


Using Applet Wrapper

MFTCC uses a Java applet to transfer files. For ease of use, MFTCC provides a wrapper class,SIFTSingleFileTransfer, to wrap the details of how to use the applet. You can create an instance of theclass, set necessary parameters, and then transfer a file. The class performs one file transfer at a time.

Prerequisites

The SIFTSingleFileTransfer class is in the NonGUIApplet_0.0.0.1.jar file which is in the directoryafter installing the Internet Command Line Utility. Put the NonGUIApplet_0.0.0.1.jar file in yourclasspath when compiling and running your application.

Procedure

1. Examine the file record, for example, through SOAP calls, to get necessary information about a fileto set some parameters of the applet wrapper.

2. Set the class parameters of the applet wrapper using set methods.See Class Parameters for detailed descriptions of the class parameters.

3. After setting the necessary parameters, call the transferSingleFile() method to transfer the file.

What to do next

After the file transfer is completed, you can use the Get Result class to get information of the transfer.

The following information are returned:

● returnCode: the return code from the applet.

● bytesTransfered: the number of bytes transferred.

● compressedByte: the number of compressed bytes transferred.

● returnMsg: the return message from the server.

Class Parameters

Before transferring a file by using a Java applet, you must set the class parameters using set methods.

The following table lists the class parameters:


fileTransferServletURL The URL used to contact the file transfer servlet, for example, https://server:port/cfcc/control?view=servlet/fileTransfer.

This parameter is required.

transferDirection This parameter should be set to SEND if the applet is used to sending afile, and should be set to RECEIVE if the applet is used to receive a file.The default value is RECEIVE.

This parameter must be set based on the value in the filerecord.

fileID This parameter represents the transfer record to be transferred.

This parameter must be set based on the value in the filerecord.

143



localFileName The path and name of the local file to be transferred.


serverFileName The name of server file to be downloaded for a directory transfer.

This parameter is only used when receiving a file from a directory filerecord.

For directory download, you must set this parameter.

sessionID The ID of the current session.


you can get the value from previous SOAP call ofgetSession().

compression This parameter defines whether to compress the file being transferred.


● YES: compress the file being transferred. This is the default value.

● NO: do not compress the file being transferred.

traceLevel This parameter defines the level of trace to use.

This parameter is optional.

user id The user ID to be used in an HTTP request requiring BASICauthentication.

This parameter is a required.

password The password to be used in an HTTP request requiring BASICauthentication.

This is a required parameter.

restartTransfer This parameter defines whether to restart the transfer.


● YES: restart the transfer.

● NO: do not restart the transfer.

This parameter is optional.

RestartTransfer=Yes will be ignored unless the transferdefinition is defined with ChkptRestartFlag=Yes.

checkpointInterval This parameter defines the number of seconds between checkpoints.

You must also set this parameter when the restartTransferparameter is set.

144



synchronize This parameter defines the synchronization level if you initiate multipletransfers at the same time.


● Yes: the transfers will execute one at a time.

● No: the transfers will execute concurrently.

Directory Transfers Using Platform Transfer Client UtilityExecuting a directory transfer on the command line works the same way as doing a single file transfer,except that extra commands need to be used. An entire directory or just one file can be transferredusing a directory definition.

The following Internet parameters are used in the same manner as a regular file transfer:

● ListAllFiles

● ListDownloadFiles

● ListFile

● ListUploadFiles

● ProcessAllFiles

● ProcessDownloadFiles

● ProcessFile

● ProcessUploadFiles

Two additional parameters need also be used:


SubDir This parameter defines whether MFTCC scans subdirectories for files totransfer in directory uploads, and defines whether MFTCC processes data inMFTCC server subdirectories for directory downloads.

When No is specified, MFTCC only processes files in the defined directory.When Yes is defined, MFTCC processes files in the subdirectories and in thedefined directory.

This parameter is valid only for MFTCC files defined with the directory flag. Itis ignored for all other requests.

This parameter is supported on all List and Process calls.

FileName This parameter is used only on directory download requests. It defines a singleserver file name to download.

It is only supported on ListFile and ProcessFile calls.

145


Directory Download Request Processing

The following table lists the parameters for directory download requests:


LocalFileName This parameter points to a directory or a file name.

FileName This parameter points to the MFTCC server file name.

SubDir This parameter defines whether to process files in subdirectories.

When the FileName parameter is defined, it means that you want to process only a single file. If theFileName parameter does not point to a valid MFTCC server file name, the request fails. If theLocalFileName parameter is not defined, MFTCC stores the file in the directory pointed to by theClientFileName parameter of the MFTCC server. If the LocalFileName parameter points to a file, thefile is saved to that file name. If the LocalFileName parameter points to a directory, the file is saved tothat directory using the name defined by the FileName parameter. If the LocalFileName parameter isnot defined as either a file or directory, it is treated as a file name. If the fully qualified file name isinvalid, the request fails, and no directory is created in this case.

When the FileName parameter is not defined, it means that you want to process the contents of thedirectory. If the LocalFileName parameter is not defined, MFTCC stores the files in the directorypointed to by the ClientFileName parameter of the MFTCC server. If the LocalFileName parameterpoints to a directory, the files are saved to that directory using the names of the server files. If theLocalFileName parameter does not point to a directory, an error is displayed. MFTCC does not createthe high-level directory; the high-level directory must exist. If the SubDir parameter defines to processsubdirectories, subdirectories should be created within the directory pointed to by the LocalFileNameparameter (or the ClientFileName parameter if the LocalFileName parameter is not defined).

Directory Upload Request Processing

The following table lists the parameters for directory download requests:


LocalFileName This parameter points to a directory or a file name.

SubDir This parameter defines whether to process files in subdirectories.

When the LocalFileName parameter points to a file, MFTCC transmits that file only. When theLocalFileName parameter points to a directory, MFTCC transmits all files within the directory.

Email ProcessingYou can configure MFTCC to send emails from a variety of pages and forward the emails to the definedserver.

Email notification occurs in the following situations:

● When a file is added to the system, email can be sent to all users configured to perform transfer ofthe file. For example, if you define a single user to access the file, an email can be sent to that user. Ifyou define a group to access the file, emails can be sent to all users within the group.

● When a file transfer is completed, either successfully or unsuccessfully, email can be sent to differentemail addresses based on whether the transfer is successful or unsuccessful. For example, you cansend an email to the Accounting department when a transfer is successful, and send an email to the

146


Help Desk when a transfer fails. Email can also be sent for Internet Server transfers and PlatformServer transfers and can have multiple recipient addresses separated by a comma.

● Email can be sent as an alert action. When certain trigger criteria are met, an email can be sent to oneor several recipients. An example of such criteria can be Internet Server transfers or Platform Servertransfers, transfers to or from a particular MFTCC server, uploads, downloads, sends, receives,transfer success or transfer failure.

● Email can also be sent for Platform to Platform transfers. They are sent via the initiating TIBCO MFTPlatform Server system and do not use the templates defined in MFTCC.

MFTCC email can be configured to change the look and feel so that the emails are in any format thatyou want. MFTCC email templates are built using XML. They are simply files on the MFTCC serverand can be changed using any text editor. No restriction is set to the number of email templates thatyou can define. The email templates can be customized for individual users and companies. MFTCCprovides four different email templates. For detailed information of the four email templates, see EmailTemplates.

To implement the email capability, you must configure the system to define when emails must be sent.For information of how to configure MFTCC for email support, see Configuring MFTCC for EmailSupport.

See the following introductions for how to configure email notification for each situation:

● Configuring Email Notification for Transfer Availability

● Configuring Email Notification for File Transfer Completion

● Configuring Alert Email

Configuring MFTCC for Email SupportTo support email notification, you must configure the MFTCC server email parameters in the GlobalSettings section on the System Configuration page which can be accessed by clicking Administration >System Configuration.

The following table lists the parameters for email support:


Email AdminUser Id

This is an optional field. It defines the administrator user ID for the emailserver.

It is only required when the email server requires a user ID and password.

Email AdminUser Pwd

This is an optional field. It defines the administrator password for the emailserver.

It is only required when the email server requires a user ID and password forauthentication.

147



Email FailureTemplate

This is an optional field. It defines the default value for the Email FailureTemplate parameter.

This definition can be overridden by the Email Failure Template parameterdefined in the Internet transfer definition. If a template is defined here, insteadof in the Internet transfer definition, this template is used.

This field should be defined if you only have a single email template to be usedfor all unsuccessful transfers. If this field is not defined, the default emailfailure template is used: cfcc\email-template\email-failure-template.xml. If the template is in the MFTCC email-template directory,you can enter the file name. Otherwise, you must enter the fully qualified filename including the path.

Email Host Name This parameter is required if you want to use the email features. It defines thename of the email system; for example, emailserver.company.com.

If this field is not defined, MFTCC email support is disabled.

Although this field can contain an IP address, it typically containsthe IP name of the email server at your site.

Email Host Port This is an optional field.

If this field is not defined, the default host port of 25 is used.

This field should only be used when the email host port does not usethe default value of 25.

Email SuccessTemplate

This is an optional field. It defines the default value for the Email SuccessTemplate parameter.

This template can be overridden by the Email Success Template parameterdefined in the Internet transfer definition. If a template is defined here, insteadof in the Internet transfer definition, this template is used.

This field should be defined if you only have a single email template to be usedfor all successful transfers. If this field is not defined, the default email successtemplate is used: cfcc\email-template\email-success-template.xml. Ifthe template is in the MFTCC email-template directory, you can enter the filename. Otherwise, you must enter the fully qualified file name including thepath.

Configuring Email Notification for Transfer AvailabilityWhen a file is added to the system, email can be sent to all users configured to perform transfer of thefile.

All users authorized to perform the transfer and have email notification addresses defined will receiveemail notifications that the file is ready to be transferred.

When you want to send an email to users to notify them that a transfer is available for them to execute,perform the following steps:

148


Procedure

1. Define the email address within the MFTCC user record for the user associated with the transferrequest.If no email address is defined in the user record, no file availability notification email will be sent tothat user.

2. When a transfer record is added for a user or group of users, define the File Notification EmailTemplate field with a valid email template file name.The name must exactly match the name of the template file. When processing an email template,MFTCC first looks in the MFTCC server /cfcc.war/email-template directory for the emailtemplate file specified. If you do not specify a fully qualified name, the email templates must bestored in this default directory. If for some reason, you want to store the email template files in adifferent directory, you have to define the fully qualified email template file name in the FileNotification Email Template field.

Configuring Email Notification for File Transfer CompletionYou can configure MFTCC server to send email notification messages to authorized users upon transfercompletion.

You can send transfer completion messages on success and failure. You can send the success and failureemails to different email addresses.

To use this support, the Email Success Template and Email Failure Template parameters must bedefined and the target email addresses must be defined.

To implement transfer completion email notification, perform the following steps:

Procedure

1. Define the email template files.You can define the email template file either through the Administration > System Configurationoption or through the Transfer option.

If the template is defined in both places, the MFTCC Internet transfer definition overridesthe MFTCC system configuration definition.

2. Define the target email addresses.Email file completion support is enabled by entering the target email address in the SuccessRecipient and Failure Recipient fields in the Email Notification section in the MFTCC Internettransfer definition. You can send the email notifications to several different email addresses(separated by commas). Likewise, you can choose to send notification on success but not on failure,or vice versa.

What to do next

After the configuration parameters are defined, you can run a transfer. If the transfer is successful, theemail will be sent to the email address of the user defined by the Success Recipient field.

Completion email notification is sent only if the file transfer was actually started. If an error occursbefore the transfer is started, no email will be sent.

Configuring Alert EmailWhen an alert definition record is added to MFTCC, one of the alert actions that can be taken is sendingan email.

Before sending an email, MFTCC checks the alert trigger criteria defined through the Management >Alert option. The alert trigger can be transfer type, server name, file name, user ID, transfer direction,

149


and so on. You can enable alert email by selecting the Send Email check box and entering the recipientemail address in the alert definition. Multiple email addresses can be defined (separated by commas).

For more information of alert definition, see Alerts.

Email TemplatesMFTCC provides four different email templates built using XML. You can edit the email templatesusing any text editor.

MFTCC provides the following email templates:

● File Availability Template● Transfer Completion Templates● Alert TemplateThe three types of templates are configured differently and use different XML DTD files. You canchange the format of the template XML files, but you cannot update the DTD files. The XML filesincludes references to the DTD files defined. The DTD files should be located in the same directory asthe email template XML files. If you move the XML files (for example, they are not located in theMFTCC server email-template directory), the DTD files should be copied from the email-templatedirectory into the directory where the XML files are located.

Both types of templates have tokens that can be used to add parameters associated with the file transferinto the email. The tokens are defined using the following format:

<token name=”transferdirection”/>

The above example defines the use of the transferdirection token that has a value of either UPLOADor DOWNLOAD.

File Availability Template

MFTCC provides a file availability template. The template is named as email-notification-template.xml and is located by default in the MFTCC <MFT_Install>\server\webapps\cfcc\email-template directory.

The following example is a copy of the file availability template that is shipped with the MFTCCsoftware:

<?xml version="1.0"?><!DOCTYPE file-notification-email SYSTEM "file-notification-email.dtd">



<file-notification-email> <sender> <address><token name="emailsender"/></address> </sender> <subject>File Availability Notification</subject> <message> FileID: <token name="fileid"/> Transfer Direction: <token name="transferdirection"/> Client File Name: <token name="clientfilename"/> Description: <token name="description"/> Available Date: <token name="availabledate"/> Expiration Date: <token name="expirationdate"/>

To access this file, click on the following URL: <token name="emailurl"/>/bclient/index.jsp?FileID=<token name="fileid"/>

To check for all available files, click on the following URL: <token name="emailurl"/>/bclient/index.jsp

150


</message></file-notification-email>

The following table lists the description for each line in the template:

Line Description

<!DOCTYPE file-notification-email SYSTEM "file-notification-email.dtd">

This line defines the DTD file associated with the XMLfile.

You should insure that this file exists in the samedirectory as the email template. If the DTD file is not inthe same directory as the email template, emailprocessing does not work.

<sender><address><token name="emailsender"/></address>

This line defines the name of the email sender.

The default sender name is [email protected].

This name can be changed to any appropriate emailaddress. When the user receives an email, the dataentered here is shown as the Sender (or From).

Some email systems require this to be a validemail address.

<subject>File Availability Notification</subject>

This line defines the information that is shown in theSubject field of the email.

FileID: <token name="fileid"/>Transfer Direction: <token name="transferdirection"/>Client File Name: <token name="clientfilename"/>Description: <token name="description"/>Available Date: <token name="availabledate"/>Expiration Date: <token name="expirationdate"/>

These fields define information from the transferdefinition that is added.

When a token is included in the field, the informationfrom the Internet transfer definition is substituted for thetoken.

To access this file, click on the following URL:<token name="emailurl"/>/bclient/index.jsp?FileID=<token name="fileid"/>

These fields define the URL that can be used by anauthorized user or group of users to access the file that ismade available to transfer.

When you click the URL, you are brought directly to thescreen where you can access the file.

The administrators must change the fieldhost:port to point to their MFTCC server. Ifyou build your own user interface, you caninsert the URL to your page here as well.

151


Line Description

To check for all available files, click on the following URL:<token name="emailurl"/>/bclient/index.jsp

These fields define the URL that can be used to access alltransfer definitions that are available for you.

When you click the URL, you are brought directly to thescreen where you can start the MFTCC file transferapplet.

The administrators must change the fieldhost:port to point to their MFTCC server. Ifyou build your own user interface, you caninsert the URL to your page here as well.

Tokens Supported in the File Availability Template

You can use tokens in the file availability template provided by MFTCC.

The format of a token is as follows:

<token name=”xxxxxxxxxx”/>

Where, xxxxxxxxxx defines the name of the token. The following tokens are supported in the fileavailability template:

Token Description

fileid This token is typically used in the URL to define the file name that is just madeavailable.

clientfilenam

e

This token defines the name that is defined for the file on the client side.

serverfilenam

e

This token defines the name that is defined for the file on the server side.

This information is not usually displayed on the users screen. If the notificationmessage is sent to a user, it is good practice to not add this field to the fileavailability template. If this email is sent to an internal user, you can include thistoken in the email.

description This token defines the description that is defined for the file in the transfer record.

This is an important field for the client because it can describe the contents of thefile to be sent or received.

availabledate This token defines the date on which the file will be made available to transfer.

expirationdat

e

This token defines the date on which the file will expire and be no longer validfor transfer.

transferdirec

tion

This token defines whether the transfer is an upload (client to MFTCC server) ora download (MFTCC server to client).

Transfer Completion Templates

MFTCC provides two file transfer completion templates: one for successful transfers and one forunsuccessful transfers. The templates are named as transfer-success-email-template.xml and

152


transfer-failure-email-template.xml and are located by default in the MFTCC <MFT_Install>\server\webapps\cfcc\email-template directory.

The following example is a copy of the transfer completion template for successful transfers.

The two templates are essentially the same except for some comments indicating the success or failureof the transfer.<?xml version="1.0"?><!DOCTYPE transfer-notification-email SYSTEM "transfer-notification-email.dtd">



<transfer-notification-email> <sender> <address><token name="emailsender"/></address> </sender> <recipient> <address><token name="recipientemailaddress"/></address> </recipient> <subject>File Transfer Success Notification</subject> <message> File Transferred Successfully!! User: <token name="userid"/> Transfer Description: <token name="description"/> Transfer Direction: <token name="transferdirection"/> Client File Name: <token name="clientfilename"/> To Server: <token name="node"/> Server File Name: <token name="serverfilename"/> Start Time: <token name="starttime"/> End Time: <token name="endtime"/> Byte Count: <token name="bytecount"/> Transfer Status: <token name="transferstatusmsg"/> Audit ID: <token name="auditid"/> Client IP: <token name="clientip"/>

</message></transfer-notification-email>


Line Description

<!DOCTYPE transfer-notification-email SYSTEM "transfer-notification-email.dtd">

This line defines the DTD file associated with theXML file.

You should insure that this file exists in the samedirectory as the email template. If the DTD file isnot in the same directory as the email template,email processing does not work.



The default sender email address used is defined inthe Sender Email Address field in the GlobalSettings section on the System Configuration page.

This email address can be changed to anyappropriate email address. When the user receivesan email from MFTCC, the data entered here isshown as the Sender (or From).

153


Line Description

<recipient><address><token name="recipientemailaddress"/></address>

This code is currently commented out. It defines thedefault recipient.

If you define an email address in the SuccessRecipient field of a transfer definition, this userreceives an email when a transfer is conductedsuccessfully. If no email address is defined here, noemail will be sent.

If you want to send an email to a specific party, youcan uncomment the line by removing the XMLcomments, <!—from the top line and --> fromthe last line. Then in place of the token, <tokenname="recipientemailaddress"/>, add arecipient email address, such as,[email protected]. One reason you mightwant to do this is for a specific user to get all theemails when a transfer fails. This can be a TIBCOTechnical Support user in your company. To do this,set the user ID in the transfer-failure-email-template.xml file. That way, an email is sent to thatuser when any requests fail.

<subject>File Transfer Success Notification</subject>

This line defines the information that is shown inthe Subject field of the email. In this case, itindicates that the file is successfully transferred.

File Transferred Successfully!! This is a comment that indicates the file has beentransferred successfully.

You can also insert other comments or instructionshere.

User: <token name="userid"/>Transfer Description: <token name="description"/>Transfer Direction: <token name="transferdirection"/>Client File Name: <token name="clientfilename"/>To Server: <token name="node"/>Server File Name: <token name="serverfilename"/>Start Time: <token name="starttime"/>End Time: <token name="endtime"/>Byte Count: <token name="bytecount"/>Transfer Status: <token name="transferstatusmsg"/>Audit ID: <token name="auditid"/>Client IP: <token name="clientip"/>

These fields define information from the definitionrecord of the file that is transferred.

When a token is included in the field, theinformation from the transfer definition and auditrecords is substituted for the token.

Tokens Supported in Transfer Completion Templates

You can use tokens in the transfer completion template provided by MFTCC.



154


Where, xxxxxxxxxx defines the name of the token. The following tokens are supported in the fileavailability template:

Token Description

auditid This token defines the audit record number associated with the file transferrequest.

This token can be used in a URL to point to the audit record for the file that istransferred. If done correctly, you can branch directly to the audit record forthis file transfer request. It is more likely that this is included on the failuretemplate than the success template.

bytecount This token defines the number of bytes that are transmitted during thetransfer.

In a successful transfer, this should match the size of the file. In anunsuccessful transfer, this number does not necessarily match the number ofbytes that are transferred; it defines the number of bytes that are sent orreceived before an error is detected.

clientfilename This token defines the name that is defined for the file on the client side.

endtime This token defines the time when the file transfer request is completed.

fileid This token is typically used in the URL to define the record ID of the file thatis transferred.

node This token defines the target server associated with the file transfer.

proxystatusmsg This token defines the last error message associated with the file transferrequest.

This is usually a better indication of the actual reason that caused a filetransfer failure.

serverfilename This token defines the name that is defined for the file on the server side.

This is also the name of the file on the target server.

sessionid This token defines the session ID used for the file transfer.

This is for information purposes only.

starttime This token defines the time when the file transfer request is started.

transferdirectio

n

This token defines whether the transfer is an upload (client to MFTCC server)or a download (MFTCC server to client).

transferstatus This token defines the transfer status.

It can be SUCCESS or FAILURE.

transferstatusms

g

This token defines the last message associated with the file transfer request.

This is often a generic message that indicates that the transfer fails.

userid This token defines the user ID associated with the file transfer.

155


Alert Template

MFTCC provides an alert template. The template is named as email-alert-notification-template.xml and is located by default in the MFTCC <MFT_Install>\server\webapps\cfcc\email-template directory.

The following example is a copy of the alert template that is shipped with the MFTCC software:<?xml version="1.0"?><!DOCTYPE alert-notification-email SYSTEM "alert-notification-email.dtd">



<alert-notification-email> <sender> <address><token name="emailsender"/></address> </sender> <subject>Email Alert</subject> <message> A transfer matches alert definition, and triggers the alert processing.

--- Alert Properties --- Alert ID: <token name="alertname"/> Alert Time: <token name="alerttime"/> Alert Description: <token name="alertdescription"/> Alert Severity: <token name="severity"/>

--- Transfer Properties --- Audit ID: <token name="auditid"/> Department: <token name="department"/> File Description: <token name="description"/> Local Transaction Id: <token name="localTranId"/> Transfer Direction: <token name="transferdirection"/> Client File Name: <token name="clientfilename"/> To Server: <token name="node"/> Server File Name: <token name="serverfilename"/> Byte Count: <token name="bytecount"/> Start Time: <token name="starttime"/> End Time: <token name="endtime"/> Transfer Status Message ID: <token name="transferstatusmsg"/> Transfer User: <token name="userid"/> Transfer status: <token name="transferstatus"/> Client IP: <token name="clientip"/> Proxy Msg: <token name="proxystatusmsg"/> ProcessName: <token name="processname" /> UserData: <token name="userdata" />

Email comment: <token name="comment"/>

</message></alert-notification-email>


Line Description

<!DOCTYPE alert-notification-email SYSTEM "alert-notification-email.dtd">

This line defines the DTD file associated with theXML file.

You should insure that this file exists in the samedirectory as the email template. If the DTD file is notin the same directory as the email template, emailprocessing does not work.

156


Line Description



The default sender name is [email protected].

This name can be changed to any appropriate emailaddress. When the user receives an email, the dataentered here is shown as the Sender (or From).

<subject> Email Alert</subject> This line defines the information that is shown in theSubject field of the email.

In this case, it indicates that the file is successfullytransferred.

A transfer matches alert definition, and triggers the alert processing.

This is a comment that indicates the file istransferred successfully.

You can also insert other comments or instructionshere.

Audit ID: <token name="auditid"/>Department: <token name="department"/>File Description: <token name="description"/>Local Transaction Id: <token name="localTranId"/>Transfer Direction: <token name="transferdirection"/>Client File Name: <token name="clientfilename"/>To Server: <token name="node"/>Server File Name: <token name="serverfilename"/>Byte Count: <token name="bytecount"/>Start Time: <token name="starttime"/>End Time: <token name="endtime"/>Transfer Status Message ID: <token name="transferstatusmsg"/>Transfer User: <token name="userid"/>Transfer status: <token name="transferstatus"/>Client IP: <token name="clientip"/> Proxy Msg: <token name="proxystatusmsg"/>ProcessName: <token name="processname" />UserData: <token name="userdata" />

Email comment: <token name="comment"/>

These fields define information regarding thetransfer that triggers the alert.

When a token is included in the field, theinformation from the transfer definition and auditrecords is substituted for the token.

Tokens Supported in the Alert Template

You can use tokens in the file availability template provided by MFTCC.



157


Where, xxxxxxxxxx defines the name of the token. The following tokens are supported in the alerttemplate:

Token Description

alertname This token defines the alert ID that is automatically assigned when an alert isdefined.

alerttime This token defines the time and date on which the alert is processed.

auditid This token defines the audit record number associated with the file transferrequest.

This token can be used in a URL to point to the audit record for the file that istransferred. If done correctly, you can branch directly to the audit record forthis file transfer request. It is more likely that this is included on the failuretemplate than the success template.

bytecount This token defines the number of bytes that are transmitted during thetransfer.

In a successful transfer, this should match the size of the file. In anunsuccessful transfer, this number does not necessarily match the number ofbytes that were transferred; it defines the number of bytes that are sent orreceived before an error is detected.

clientfilename This token defines the name that is defined for the file on the client side.

endtime This token defines the time when the file transfer request is completed.

fileid This token is typically used in the URL to define the record ID of the file thatis transferred.

node This token defines the target server associated with the file transfer.

proxystatusmsg This token defines the last error message associated with the file transferrequest.

This is usually a better indication of the actual reason that causes a filetransfer failure.

serverfilename This token defines the name that is defined for the file on the server side.

This is also the name of the file on the target server.

sessionid This token defines the session ID used for the file transfer.

This is for information purposes only.

starttime This token defines the time when the file transfer request is started.

transferdirectio

n

This token defines whether the transfer is an upload (client to MFTCC server)or a download (MFTCC server to client).

transferstatus This token defines the transfer status.

It can be SUCCESS or FAILURE.

158


Token Description

transferstatusms

g

This token defines the last message associated with the file transfer request.

This is often a generic message that indicates that the transfer fails.

userid This token defines the user ID associated with the file transfer.

File TokensTIBCO MFT Internet Server supports the use of file tokens in the server file name.

When creating a file record in the TIBCO MFT Internet Server database, you can use any of thesupported file tokens in the name. When this file is transferred, the tokens are translated to a new valuewithin the file name.

Tokens use the following format within the file name: #(token).

If tokens are available, you can click the File Token List link next to the Server File Name field on theAdd Transfer page for the complete token list.

Multi-Language SupportMFTCC supports multiple languages for various file transfer clients of MFTCC. This feature supportstext on the pages and messages that are to be displayed to the end user to be displayed in variouslanguages.

The multi-language support is applied in MFTCC as follows:

● All messages and texts that are displayed to the end user using the MFT file transfer pages aredisplayed in the language preferred by that end user. The MFTCC Administrator pages do notsupport multiple languages and are shown in English.

● All dates and times that are displayed to the end user performing the file transfer are displayed inthe format preferred by that end user’s region (according to language). The dates and times in theMFTCC Administrator pages are displayed in the U.S. format only.

● File transfer end user messages consist of texts produced by the following MFTCC components:

— File transfer applets: includes the Java client file transfer applet and the file browse applet.

— File transfer web pages: includes the web pages that support the Java client applet.

— File Transfer web service: includes all error messages that are returned by the File Transfer webservice.

— File Transfer servlet: includes all success and error messages that are returned by the FileTransfer servlet.

— File Transfer utility: includes all success and error messages that are produced by this utility.

● Trace messages produced by these components remain in English.

● File transfer end users communicate their preferred language to MFTCC by configuring theirbrowser and local operating system to request information in their preferred language.

Language preference is usually done automatically when working on an internationalversion of Windows or can be controlled manually by setting the language preference inthe browser.

● If the end user’s preferred language is not one supported by MFTCC, all messages and texts are inEnglish.

● MFTCC supports the following languages: English, French, Italian, Portuguese, and Spanish.

159


● Multi-language support is performed on the machine that produces the texts to be translated. Inother words, language translation for JSPs and Servlets occurs on the MFTCC server, whilelanguage translation for applets and File Transfer Utility occurs on the client machine.

Updating the Database SettingsYou can use the dbsettings utility to create a new user ID and password to be used to connect to theCFCC database.

The dbsettings utility supports you to update the DBUser and DBPass fields defined in the web.xmlfile of your web server. The utility saves the DB password in an encrypted format if desired.

To use this utility, run the dbsettings.bat script for Windows (dbsettings.sh for UNIX) in the<MFTIS_Install>\distribution\util\dbsettings directory.

The following example shows a sample output:* The dbsettings program allows you to configure your* database settings contained in the application's* web.xml file as well as encrypt the database user's* password contained in this xml file.** To make any changes to the web.xml file you will need* to provide the full path to the web.xml file. Some* examples are displayed for your convenience.* To edit your database settings choose option 1 from* the main menu and you will be given the choice to:* update your database driver, update the database URL* used to make a connection to the database server, update* the database userid, or to update the database password* which can be stored in encrypted or clear text format.** Any changes made will be saved upon exiting the program* by choosing option 2. At that time you will be asked if you* want to save your changes.****************************************************************************Enter the full path to the application's web.xml file. (Such as the example below)C:\MFT\server\webapps\cfcc\WEB-INF: C:\MFT711\server\webapps\mftcc\WEB-INFPlease select one of the following options:===========================================1. Update Database settings2. Exit1Current Database Settings in web.xml====================================1. Driver: oracle.jdbc.driver.OracleDriver2. URL: jdbc:oracle:thin:@10.97.198.82:1521:orcl3. User ID: QA_714. DB Password: ****** Encrypted? Yes5. Back to Main MenuEnter the number of the setting you wish to change.:3Enter the database user ID (Current [QA_71]):DBUSERIDCurrent Database Settings in web.xml====================================1. Driver: oracle.jdbc.driver.OracleDriver2. URL: jdbc:oracle:thin:@10.97.198.82:1521:orcl3. User ID: QA_714. DB Password: ****** Encrypted? Yes5. Back to Main MenuEnter the number of the setting you wish to change.:5Do you wish to encrypt the password? y or n. (Default [y]): yDo you wish to save your changes? y or n. (Default [n])

160


When you change the user ID, you should choose option 4 to change the password for that user ID. Youcan save the changes and encrypt the password if you want.

For installations using an MSSQL database that will be using Windows authentication, you must addthe domain parameter with the domain name to the end of the database URL. To do this, choose option2 and enter the new database URL, for example, jdbc:jtds:sqlserver://10.1.2.182:1433/MFT67;domain=DomainName.

161


Sample JMS XML

TIBCO MFT Internet Server and TIBCO MFT Command Center provides nine JMS XML schema filesending with the .xsd extension and three accompanying sample XML files.

To view any of the XML schema files or sample XML files, it is good practice to use a text editor, such asNotepad or NotePad++.

See the following introductions for details of the XML schema files or sample XML files:

● JMS XML Schema Files

● XML Files

JMS XML Schema FilesThe JMS XML Schema files define the rules that must be followed when creating XML files andtherefore should not be updated.

The JMS XML Schema files are located in the <MFTIS_Install>/server/webapps/<context>/example/JMS directory.

The following table lists the nine JMS XML Schema files:

XML Schema File Description

AuditRequest.xsd Defines the format of the parameters necessary to initiate an auditsearch of the MFT database.

The audit request searches the MFT database for transfers thatmatch the defined audit search filters.

AuditResponse.xsd Defines the format of the audit response.

This .xsd file is used for multiple responses and returns an array of0 or more audit records. For the audit search, it returns a record foreach transfer that matches the audit search filters. For otherrequests, it returns only one record.

The audit response is written in response to the following TIBCOMFT Command Center and TIBCO MFT Internet Server functions:

● Alert

● Audit Request

● Transfer Notification

● Internet Server Transfer Request

● Platform Server Transfer Request

ManageConfigResponse.xsd Defines the XML data that is returned when a management requestis initiated and the request type is ManageConfigRequest. Thisresponse XML maps the MFT JMS configuration parameters.

162



ManageRequest.xsd Defines the format of the parameters necessary to initiate amanagement request. This request is used internally to extractconfiguration information from MFTCC.

The following three request types are supported:

● ManageConfigRequest: returns the JMS configurationparameters.

● ManageServerRequest: returns a list of MFT servers defined toMFTCC.

● ManageServerTransfers: returns a list of predefined transfers.

The ManageServerRequest request returns a different listof servers based on the request JMS type set:

● ManageServerRequest: returns all Platform Serverservers.

● ManageServerRequestIS: returns all Internet Serverservers.

ManageServerResponse.xsd Defines the XML data that is returned when a management requestis initiated and the request type is ManageServerRequest.

The following two types of responses can be returned, based on theJMS type setting of the ManageServerRequest request:

● ManageServerRequest: returns the name of all Platform Serverservers defined to MFTCC.

● ManageServerRequestIS: returns the name of all Internet Serverservers defined to MFTCC.

ManageTransferResponse.x

sd

Defines the XML data that is returned when a management requestis initiated, the request type is ManageTransferRequest and therequest JMS type is ManageTransferRequest.

This response returns all Platform Server transfers defined toMFTCC.

ManageTransferResponseIS

.xsd

Defines the XML data that is returned when a management requestis initiated, the request type is ManageTransferRequestIS and therequest JMS type is ManageTransferRequestIS.

This response returns all Internet Server transfers defined toMFTCC that the user defined in the ManageRequest request isauthorized to access.

163



TransferRequestInternetS

erver.xsd

Defines the format of the parameters required to initiate an InternetServer transfer. Internet Server transfers can only be initiatedthrough JMS.

Internet Server transfers can perform the following actions:

● Read a JMS queue and send the data to a remote destination.

● Read a local file and send the data to a remote destination.

● Read data from a remote destination and write data to a JMSqueue.

● Read data from a remote destination and write data to a localfile.

Two JMS records can be returned for this request:

● Immediate response: indicates whether the request is acceptedand submitted to Internet Server for processing. This responsedoes not have XSD data because no XML data is returned withthis response. All data is returned in the JMS header.

● Audit response: this is written when a request is accepted andthe TransferStatusCheck parameter is set to Yes.

TransferRequestPlatformS

erver.xsd

Defines the format of the parameters required to initiate a PlatformServer transfer. This is occasionally called a third party transfer.MFTCC retrieves data from the JMS queue and initiates a transfer toPlatform Server A to transfer a file to or from Platform Server B.

Two JMS records can be returned for this request:

● Immediate response: indicates whether the request is acceptedand submitted to the Platform Server for processing. Thisresponse does not have XSD data because no XML data isreturned with this response. All data is returned in the JMSheader.

● Audit response: this is written when a request is accepted andthe TransferStatusCheck parameter is set to Yes.

XML FilesThe XML files define the parameters necessary to perform a JMS function.

When you want to update the XML files, it is good practice to copy them to a new folder to keep theoriginal files in their original status. Each sample XML file has a corresponding XSD file. See the XSDfile associated with the XML file for the rules that define allowable values in the XML file.

The following table lists the three sample XML files:

Sample XML File Description

AuditRequest.xml Defines sample XML data to perform an audit request.

164


Sample XML File Description

TransferRequestInternetServe

r.xml

Defines sample XML data to initiate an Internet Server transfer.

TransferRequestPlatformServe

r.xml

Defines sample XML data to initiate a Platform Server transfer.

Using JMS XML FilesEach sample XML file has a corresponding XSD file. MFTCC provides three sample XML files. Whenyou want to create an accompanying XML file for one of the XSD files, see the element details in theXSD files.

165


ID Information

MFTCC assigns IDs to various functions. All the IDs have the same format except for the length of thesequential number given at the end.

The sequential number at the end of the ID is only five digits in length for the initiator or responderplatform transfers. All the other IDs contain a seven digit number.

The following table lists the components of an ID:

Byte Description

1 The source of the ID:

● A: TIBCO MFT Platform Server Internet audit

● C: TIBCO MFT Platform Server Platform audit

● E: alert audit ID

● F: transfer definition ID

● I: initiator audit record

● L: alert ID

● N: node ID

● P: Platform Server user profile and responder profile definitions

● R: responder audit record

● S: audit search filter definition

● T: Platform Server transfer definition

2 The month:

● 1: January

● 2: February

● 3: March

● 4: April

● 5: May

● 6: June

● 7: July

● 8: August

● 9: September

● A: October

● B: November

● C: December

3, 4 The day of the month from 01 to 31.

5 The year.

F - Z: represent 2015 - 2036.

166


Byte Description

6 - 12 The sequential number in hex between 0 to FFFFFFF.

167


Appendix A. Connection Manager

Connection Manager solves a common problem typically found when a server in the DMZ needs tocommunicate with a server in the internal network.

For example, TIBCO MFT Internet Server generally executes in the DMZ to support external clientaccess; Internet Server must connect to the following servers executing in the internal network, andtherefore must make TCP connections with these servers.

● LDAP Server for Authentication

● Oracle Server DB Instance

● TIBCO MFT Platform Server where data resides

Many firewalls are configured to not support TCP connections to be opened from the DMZ to theinternal network. When supported, a security exception is often required. With Connection Manager,DMZ server instances can create connections to servers in the internal network without opening theconnection from the DMZ; all connections are opened from the internal network.

Connection Manager ComponentsConnection Manager provides the following components: Connection Manager Agent (CMA),Connection Manager Server (CMS), TIBCO MFT Command Center, and TIBCO MFT Internet Server.

The following figure shows a simple Connection Manager environment:

Connection Manager Agent (CMA)

CMA accepts TCP connection requests from Internet Server. It then sends these requests to CMS overthe control connection established by CMS. CMA generally executes in the DMZ.

CMA is distributed with TIBCO MFT Internet Server. It can be installed and configured as part of theInternet Server installation or it can be installed and configured standalone. CMA can execute on thesame computer as Internet Server or it can execute on a different computer than Internet Server.Multiple instances of CMA can be installed to provide high availability. For more information of CMAinstallation, see TIBCO Managed File Transfer Internet Server Installation.

168


Connection Manager Server (CMS)

CMS creates a TCP control connection with CMA. CMA uses this control connection to send TCPconnection requests to CMS. When CMA sends a connection request, CMS initiates the connection tothe remote server and responds back to the CMA request. CMS generally executes in the internalnetwork.

CMS is distributed with MFTCC. It is installed and configured in a standalone environment. CMS canexecute on the same computer as MFTCC or it can execute on a different computer than MFTCC.Multiple instances of CMS can be installed to provide high availability. For more information of CMSinstallation, see TIBCO Managed File Transfer Command Center Installation.

TIBCO MFT Command Center

With MFTCC, you can configure the CMA, CMS, and Internet Server components.

TIBCO MFT Internet Server

Internet Server requires connections to the internal network. It can execute in the internal network or inthe DMZ. When executing in the DMZ, Internet Server might require CMA to establish connections tothe internal network. When connections to the internal network are required, Internet Server connectsto CMA to initiate TCP connections.

Connection Manager Data FlowConnection Manager can work in a simple environment or two-tiered DMZ structure.

The following figure shows a simple Connection Manager data flow:

The following brief explanation shows how Connection Manager works.

Initialization Steps:

169


1. When CMS is started, it attempts to make a connection to each CMA. If the connection cannot beestablished, CMS waits 30 seconds and tries again. It continues retrying the connection until theconnection is successfully established.

2. At some point, CMA is started and listens for incoming CMS connections. CMA listens for TCPconnections on the following two ports:

● 48000: control connection from CMS● 48001: data connections from CMSWhen CMS retries the connection to CMA control port, the connection is established successfully.

Steps to Create a Connection:

1. When Internet Server needs to establish a TCP connection, it must first determine whether theconnection must be routed through Connection Manager. Internet Server reviews its configurationto find a match on an IP address or IP address subnet. Assuming that the connection must be madethrough Connection Manager, Internet Server requests a TCP connection with CMA. It then sends aSOCKS packet to CMA indicating the destination connectivity information (IP address and IP port).

2. CMA reads the Internet Server data packet and sends the request to CMS over the controlconnection.

3. CMS reads the data from the control connection and establishes a connection with the destinationserver.

4. CMS then establishes a TCP connection with CMA data port. CMA ties this connection togetherwith the connection request from Internet Server.

5. CMA accepts the connection from CMS and the Internet Server data begins to flow over thisconnection.

The following figure shows a two-tier DMZ architecture:

In this two-tier architecture, Internet Server is executing in DMZ1, while CMA is executing in DMZ2.

This architecture also shows the high availability capability of Connection Manager. Internet Server canconnect to multiple CMA instances and CMA can accept requests from multiple CMS instances.

170


Internet Server connects to the first CMA instance that is available and CMA requests a connection onthe first active connection to a CMS instance.

Performance Implications of Using Connection ManagerConnection Manager replaces the single connection between Internet Server and the target server (forexample, Oracle DB) with three connections (Internet Server-CMA, CMA-CMS, and CMS-Oracle).Therefore, TCP connection establishment takes longer when using Connection Manager as compared todirect connections initiated by Internet Server.

When connecting to internal servers that require many connections (for example, Internet Serverconnections to Oracle DB), it is best practice to minimize the number of connections established. Use ofMFT Connection Pooling can minimize the number of TCP connections created between Internet Serverand the Oracle DB server.

Slight performance degradation also exists when Internet Server uses Connection Manager to send bulkto internal servers. For example, Internet Server often needs to send gigabytes of data to TIBCO MFTPlatform Server in the internal network. Instead of sending the data over a single connection, the dataneeds to be sent over multiple connections (Internet Server-CMA, CMA-CMS, and CMS-PlatformServer). Many variables can affect the performance of file transfers using Connection Manager: Clientnetwork bandwidth, file size, and latency. At best, negligible performance differences exist betweendirect connections. Initial tests show approximately 10% - 15% performance degradation when used ina high volume, low latency, and fast network. After connections are made, CMA and CMS just pipesdata from the source connection to the target connection and therefore use very little CPU and verylittle memory. To save CPU cycles, data is piped to the remote destination exactly as sent or received byInternet Server. If you want to encrypt the data, you must configure Internet Server to use secureprotocols.

Connection Manager High AvailabilityConnection Manager supports high availability.

The following figure shows how high availability can be configured:

To configure high availability, you must conform to the following rules:

● Create two or more CMS instances in the internal network, executing on different computers.

171


● Create two or more CMA instances in the DMZ, executing on different computers.

● Create two or more Internet Server instances in the DMZ, executing on different computers.

CMA and Internet Server can execute on the same computer or on different computers.

● CMS1 and CMS2 must be configured to connect to CMA1 and CMA2.

● CMA1 and CMA2 must be configured to accept connections from CMS1 and CMS2.

● CMA1 and CMA2 must be configured to accept connection requests from MFTIS1 and MFTIS2.

● MFTIS1 and MFTIS2 must be configured to connect to CMA1 and CMA2.

Connection Manager operates in an active or passive mode. Requests are sent to the first availablecomponent. If the connection to that component fails or is not available, the Connection Managerattempts to send the request to the next component.

The configuration in the figure above works as follows.

MFTIS1 needs to connect to a Platform Server in the internal network.

1. At startup, CMS1 and CMS2 both attempt to establish connections to CMA1 and CMA2. If anyconnection requests fail, CMS1 and CMS2 continue to connect to CMA every 30 seconds until theconnection request is successful.

2. MFTIS1 attempts to connect to CMA1 to perform this connection. Assume that CMA1 is notavailable; MFTIS1 then connects to CMA2.

3. CMA2 looks for an active control connection from CMS. If CMA has an active control connectionwith CMS1, it initiates the request to CMS1. Assume no active control connection to CMS1 isavailable; CMA2 then initiates the request to CMS2 over an active control connection.

4. After CMA2 makes an active connection to CMS2, CMS2 connects to the target Platform Server.

5. CMS2 then connects back to CMA2 over the data connection port (48001).

6. CMA2 then completes the connection with MFTIS1. Data begins to flow over the connection:MFTIS1 > CMA2 > CMS2 > Platform Server.

7. CMA2 issues heartbeat requests to CMS2 every 45 seconds. If no response is received within 30seconds, CMA2 breaks the connection and waits for CMS2 to initiate a new connection.

8. CMS2 waits for heartbeat requests from CMA2. If no heartbeat request is received within 90seconds, CMS2 closes the connection to CMA2 and attempts to re-establish the connection to CMA2.If this fails, the CMS2 attempts to connect to CMA2 every 30 seconds.

Configuring High Availability Using the Administrator PagesDuring the installation process, Connection Manager is installed without the high availability capacity.You can use the MFTCC Administrator pages to configure Connection Manager for high availabilitythrough the Management > Connection Manager Nodes option.

To create a high availability environment, you must make the following configurations:

● Install multiple CMA and CMS Instances.

● Configure each Internet Server to connect to multiple CMA instances.

When configuring Internet Server, configure multiple CMA hosts and ports by separating theentries with a semicolon. For more details, see Updating Internet Server Configuration Information.

● Configure each CMS to connect to multiple CMA instances.

When configuring CMS, configure multiple CMA IP addresses and host names. For more details,see Updating CMS Configuration Information.

172


● Configure CMA to accept connections from multiple Internet Server and CMS instances. For moredetails, see Updating CMA Configuration Information.

Connection Manager Load BalancingBecause most Internet Server instances are located on the same computer as CMA, Internet Serverconnects to the first available CMA. If the first CMA is not available, it connects to the next definedCMA.

When CMA needs to request a connection from CMS, CMA randomly requests the connection fromone of the control connections already established by the CMS servers. If that request fails, CMArequests the connection from another CMS control connection.

CMA and CMS servers do not use substantial amounts of CPU or memory, so load balancing is notgenerally beneficial.

Configuring Connection ManagerWhen the Connection Manager components (CMA, CMS, and Internet Server) are installed, defaultvalues are set which can support Connection Manager to work in most installations. MFTCC supportsyou to update the configurations of the components in the MFTCC Administrator pages.

The Connection Manager configuration pages can be accessed through the following MFTCC options:

● Management > Connection Manager Nodes > Add Connection Manager Node● Management > Connection Manager Nodes > Manage Connection Manager Nodes

If you want to use MFTCC to configure CMA, CMS, and Internet Server, firewall ports must be openedto allow MFTCC to communicate with CMA, CMS, and Internet Server. For more information of therequired ports and firewall settings, see Connection Manager Ports and Firewall Considerations.

The help pages for the Connection Manager Administrator pages describe in great detail theparameters on the individual pages. See the help pages for detailed information on the parameters.

In addition to updating the component configurations through the MFTCC Administrator pages, youcan configure the Connection Manager parameters through configuration files. CMS, CMA, andInternet Server Connection Manager configuration parameters are saved in .xml files. You can use a texteditor to configure the Connection Manager parameters. Use a text editor to configure the CMA, CMS,and Internet Server configuration files only when you cannot use MFTCC to configure these files.

You can find the configuration files in the following directories:

● MFTIS: <MFTIS Install>/server/webapps/cfcc/WEB-INF/reverseProxyDmz.xml

● CMA: <CMA Install>/webapps/connmgr/WEB-INF/reverseProxyDmz.xml

● CMS: <CMS Install>/webapps/connmgr/WEB-INF/reverseProxyInternal.xml

For more information of the configuration files, see Connection Manager Configuration Files.

Adding Connection Manager ComponentsBefore configuring the Connection Manager components, each component must be defined to MFTCC.This is done through the Add Connection Manager Node page.

In this page, you can define the connectivity information required to communicate with the ConnectionManager component.

The following figure shows the Add Connection Manager Node page. The Type parameter defines theConnection Manager type (CMA, CMS, or Internet Server). As you change the type, the IP Port fieldchanges to the default value for that node type.

173


The value of the Password Used for Managing the Node field must match the password entered whenthe component is first installed.

On this page, you can click the Test button to verify that the IP address, IP port, and passwords aredefined correctly. When the test is successful, click Add to add the component.

Add Connection Manager Node: Internet Server

When the Type parameter is set to InternetServer, you can use the From Existing Internet Serverdrop-down box to extract the IP address and IP port from an Internet Server that is installed.

Click Test before adding the node to ensure that the type, IP address, IP port, and passwords areconfigured correctly.

174


Add Connection Manager Node: CMA


175


Add Connection Manager Node: CMS


Managing Connection Manager NodesYou can use the Manage Connection Manager Nodes page to view and update the Connection Managernodes defined.

The following figure shows the Manage Connection Manager Nodes page:

You can click an entry in the Name column in the Results table to get the detailed information for thisnode and update this node.

To delete Connection Manager nodes, select one or more check boxes under the Delete column andthen click Delete.

176


Updating CMA Configuration Information

After clicking SampleCMA, the Update Connection Manager Node page is displayed with theinformation entered on the Add Connection Manager Node page.

You can click Update to update the connectivity information for this CMA.

You can click Retrieve Config to retrieve the Connection Manager configuration parameters for thisnode. The following page is displayed.

177


This page displays the configuration information for the Connection Manager node. You can updateparameters and click Update Config to update the configuration.

If you update the New Password field, make sure to update the password on the Update ConnectionManager Node page.

If you want to use the Get Status > Test function, make sure that the Accept Connections from TheseInternet Servers field is configured to accept changes from 127.0.0.1 and ::1, in addition to the IPaddresses of the Internet Server instances. MFTCC tests are initiated from the TCP Loopback address(127.0.0.1).

When updating the Command Center Hosts That Can Manage This CMA field, make sure that youcorrectly define the IP address or subnet of MFTCC. Otherwise, you might be unable to manage theConnection Manager node through MFTCC. If this happens, you need to update the configuration .xmlfile described in Connection Manager Configuration Files and then manually restart the CMA server.

When you click Get Status, the following page is displayed showing the current status of theConnection Manager node.

178


In this page, you can perform the following functions:

● Get Status: updates the CMA status.

● Start CMA: starts the CMA server.

● Stop CMA: stops the CMA server.

● Test: tests whether a connection to an internal server is available through Connection manager.

Enter an IP name or IP address and the IP port and click Test. A message is display showingwhether a connection can be established to this remote server.

179


Updating CMS Configuration Information

After clicking SampleCMS, the Update Connection Manager Node page is displayed with theinformation entered on the Add Connection Manager Node page.

You can click Update to update the connectivity information for this CMS.


180




When updating the Command Center Hosts That Can Manage This CMS field, make sure that youcorrectly define the IP address or subnet of MFTCC. Otherwise, you might be unable to manage theConnection Manager node through MFTCC. If this happens, you need to update the configuration .xmlfile described in Connection Manager Configuration Files and then manually restart the CMS server.


In this page, you can perform the following functions:

181


● Get Status: updates the CMS status.

● Start CMS: starts the CMS server.

● Stop CMS: stops the CMS server.

Updating Internet Server Configuration Information

After clicking SampleIS, the Update Connection Manager Node page is displayed with the informationentered on the Add Connection Manager Node page.

You can click Update to update the connectivity information for this Internet Server.


182




When updating the Command Center Hosts That Can Manage This Internet Server field, make surethat you correctly define the IP address or subnet of MFTCC. Otherwise, you might be unable tomanage the Connection Manager node through MFTCC. If this happens, you need to update theconfiguration .xml file described in Connection Manager Configuration Files and then manually restartInternet Server.


183


In this page, you can perform the following function:

● Get Status: updates the Internet Server status.

Connection Manager PortsThe following figure shows the ports and IP addresses used in a simple Connection Managerinstallation.

The TCP ports shown in the figure above are the default ports as configured when CMA and CMS areinstalled.

Internet Server

When Internet Server requires a connection to the internal network, it makes a connection to CMA overport 41080.

During Internet Server initialization, Internet Server listens on one HTTPS port (443 or 7443) and waitsfor connections from MFTCC to configure the Internet Server Connection Manager properties.

184


When you use MFTCC to configure the Internet Server Connection Manager properties, MFTCC makesa connection to the Internet Server HTTPS port (typically 443 or 7443).

CMA

During the CMA initialization, CMA listens on the following four ports:

● 41080: waits for connection requests from Internet Server.

● 48443: waits for connections from MFTCC to configure the CMA properties.

● 48000: waits for CMS control channel connections.

● 48001: waits for CMS data connections (requested by CMA over the CMS control channel).

CMS

During the CMS initialization, CMS listens on one port (48443) and waits for connections from MFTCCto configure the CMS properties.

At Initialization, and each time a new CMA is activated or a CMA connection is lost, CMS attempts toconnect to CMA port 48000. If this connection fails, CMS waits for 30 seconds and tries again.

When CMA requests a connection from CMS, CMS connects to the remote server (for example, OracleDB server). After that connection is completed, CMS connects to the CMA server on port 48001 (dataconnection port).

MFTCC

MFTCC communicates with Internet Server, CMA, and CMS servers to configure the ConnectionManager properties:

● CMA: using port 48443.

● CMS: using port 48443.

● Internet Server: using port 443 or 7443.

Firewall ConsiderationsYou must conform to the following firewall rules for Connection Manager to operate correctly:

● MFTCC must be able to open TCP connections to CMS, CMA, and Internet Server.

CMS generally executes in the internal network on port 48443; CMA generally executes in the DMZon port 48443; Internet Server generally executes in the DMZ on port 443 or 7443.

If these ports are not opened, Connection Manager can still operate but you cannot use MFTCC toconfigure the Connection Manager nodes. Normal MFTCC and Internet Server definitions stillwork. But if you want to change the ports on a CMA or Internet Server, you must make the changesdirectly to the .xml configuration files. For more information of the configuration files, see Connection Manager Configuration Files.

● CMS must be able to open TCP connections to CMA on ports 48000 and 48001. If not, ConnectionManager does not work.

● Internet Server must be able to open TCP connections to CMA on port 41080. If not, ConnectionManager does not work.

● CMS must be able to open TCP connections to internal servers. If not, the Connection Managerrequests does not work to this server.

● Server shutdown ports (generally 48005) do not have to be allowed by the firewall. Internet Server,CMA, and CMS shutdown ports are typically used by shutdown scripts executing on the instancewhere the Internet Server, CMA, or CMS server is executing.

185


● When a connection is active between a CMS and a CMA, CMA initiates heartbeat requests to CMSevery 45 seconds. If a response is not received within 45 seconds, CMA breaks the connection toCMS and waits for CMS to establish a new connection to CMA.

Connection Manager Configuration FilesYou can use a text editor to configure the Connection Manager parameters saved in the CMS, CMA,and Internet Server configuration files.

Use a text editor to configure the CMA, CMS, and Internet Server configuration files only when youcannot use MFTCC to configure these files.

CMS Configuration FileThe CMS configuration file is located in the <CMS_Install>/server/webapps/commgr/WEB-INF/reverseProxyInternal.xml directory.

It is good practice to update this file only when directed to by TIBCO Technical Support or when youcannot use MFTCC to manage CMS.

A sample CMS configuration file is as follows:<?xml version="1.0" encoding="UTF-8" standalone="no"?><proxy-config>  <internal-proxy>  <command-channels max-inactive="90">  <connection-setup retry-interval="30" timeout="20"/>  <channel><address>10.1.2.3.</address><command-port>48000</command-port><data-port>48001</data-port></channel>

</command-channels>

 <data-channel>  <connection-setup timeout="45"/> </data-channel>

 <socks>  <connection-setup timeout="45"/> </socks>  <proxy-manage> <valid-hosts>10.0.0.0/8;192.168.0.0/16</valid-hosts> <password>xxxxxxxxxxxxxxxxxxxxxxxx </password> </proxy-manage>

 <allowed-dest/>

186


</internal-proxy></proxy-config>

CMS Configuration Parameters

The CMS configuration parameters are as follows.

command-channels

● max-inactive: defines the amount of time that a command channel remains inactive beforeterminating the connection. The default value of 90 indicates that CMS waits for up to 90 secondsbefore terminating the connection to CMA. CMS then attempts to re-establish the controlconnections to the control channel every 30 seconds (depending on the value of retry-interval).

● retry-interval: defines how frequently CMS attempts to establish a connection to CMA when theconnection to the CMA command channel is down.

● timeout: defines the timeout for TCP connection establishment to the control channel.

channel

Defines each CMA to which CMS connects. Define a channel for each CMA.

● address: defines the CMA IP address or IP name.

● command-port: defines the IP port for command (namely control) connections to CMA. CMA mustbe configured to listen on this port.

● data-port: defines the IP port for data connections to CMA. CMA must be configured to listen onthis port.

data channel

● connection-setup-timeout: defines the timeout for TCP connection establishment to the datachannel.

socks

connection-setup-timeout: defines the timeout for TCP connection establishment to the destination(namely target) server in the internal network.

proxy-manage

● valid-hosts: defines the MFTCC hosts that can manage this CMS. IP addresses can be specified asa full IP address or an IP address with the number of subnet bits. Multiple IP addresses can bedefined by separating them with a semicolon.

● password: defines the encrypted MFTCC management password.

allowed-dest

Defines the destination IP address or IP names and IP ports to which CMS can connect. This parametercan be defined in the following formats:

● 10.1.2.3: connections can be made to all ports on IP address 10.1.2.3.

● 10.1.2.0/24: connections can be made to all ports on subnet 10.1.2.0.

● SQLServer1:1433: connections can be made to IP name SQLServer1 on port 1433.

● FTPServer:40000-40100: connections can be made to IP name FTPServer on ports 40000-40100.

187


CMA Configuration FileThe CMA configuration file is located in the <CMA_Install>/server/webapps/commgr/WEB-INF/reverseProxyDmz.xml directory.

It is good practice to update this file only when directed to by TIBCO Technical Support or when youcannot use MFTCC to manage CMA.

A sample CMA configuration file is as follows:<?xml version="1.0" encoding="UTF-8" standalone="no"?><proxy-config>

 <dmz-proxy>

 <command-channel>  <listener handshake-timeout="20" keep-alive="45" keep-alive-timeout="30"> <address>0.0.0.0</address>  <port>48000</port> </listener>  <valid-internal-hosts>10.0.0.0/8;192.168.0.0/16</valid-internal-hosts> </command-channel>

 <data-channel>  <listener> <address>0.0.0.0</address>  <port>48001</port> </listener> <data-pipe connect-timeout="45" idle-timeout="1800"/> </data-channel>

 <socks-channel>  <listener> <address>0.0.0.0</address>  <port>41080</port> </listener>  <valid-sock5-hosts>127.0.0.1;::1</valid-sock5-hosts> </socks-channel> <proxy-selector state="cma">  <internaladdress>10.0.0.0/8;192.168.0.0/16</internaladdress>  <socks-servers loadBalance="no">127.0.0.1:41080</socks-servers> </proxy-selector>

 <proxy-manage> <valid-hosts>10.0.0.0/8;192.168.0.0/16</valid-hosts> <password>xxxxxxxxxxxxxxxxxxxxxxxx </password> </proxy-manage> </dmz-proxy> </proxy-config>

188


CMA Configuration Parameters

The CMA configuration parameters are as follows.

command-channel

● handshake-timeout: defines how long CMA waits for the handshake to complete.● keep-alive: defines how frequently CMA issues heartbeat requests to CMS. The default value of 45

indicates that CMA sends heartbeat requests to CMS every 45 seconds during periods of inactivity.● keep-alive-timeout: defines the number of seconds that CMA waits for heartbeat response from

CMS before closing the connection.● address: defines the adapter IP address that CMA binds to before listening for incoming control

channel requests. The default value of 0.0.0.0 indicates using all adapter IP addresses.● port: defines the IP port that CMA listens on for incoming control channel connections.● valid-internal-hosts: defines IP addresses of internal CMS servers. IP addresses can be specified

as a full IP address or an IP address with the number of subnet bits. Multiple IP addresses can bedefined by separating them with a semicolon.

data-channel

● address: defines the adapter IP address that CMA binds to before listening for incoming datachannel requests. The default value of 0.0.0.0 indicates using all adapter IP addresses.

● port: defines the IP port that CMA listens on for incoming data channel connections.● connect-timeout: defines how long CMA waits for a CMS connection requested by CMA over the

command (namely control) channel.● idle-timeout: this parameter is for future use and can be ignored.

socks-channel

● address: defines the adapter IP address that CMA binds to before listening for incoming requestsfrom Internet Server. The default value of 0.0.0.0 indicates using all adapter IP addresses.

● port: defines the IP port that CMA listens on for incoming connections from Internet Server.● valid-sock5-hosts: defines the Internet Server hosts from which CMS accepts connection

requests. The default value of 127.0.0.1 indicates accepting requests from the local host. MultipleIP addresses can be defined by separating them with a semicolon.

proxy-manage

● valid-hosts: defines the MFTCC hosts that can manage this CMS. IP addresses can be specified asa full IP address or an IP address with the number of subnet bits. Multiple IP addresses can bedefined by separating them with a semicolon.


Internet Server Configuration FileThe Internet Server Connection Manager configuration file is located in the <MFTIS_Install>/server/webapps/cfcc/reverseProxyDmz.xml directory.

It is good practice to update this file only when directed to by TIBCO Technical Support or when youcannot use MFTCC to manage the Connection Manager component of Internet Server.

A sample Internet Server Connection Manager configuration file is as follows:<?xml version="1.0" encoding="UTF-8" standalone="no"?><proxy-config>

189


 <dmz-proxy>

 <command-channel>  <listener handshake-timeout="20" keep-alive="45" keep-alive-timeout="30"> <address>0.0.0.0</address>  <port>48000</port> </listener>  <valid-internal-hosts>10.0.0.0/8;192.168.0.0/16</valid-internal-hosts> </command-channel>

 <data-channel>  <listener> <address>0.0.0.0</address>  <port>48001</port> </listener> <data-pipe connect-timeout="45" idle-timeout="1800"/> </data-channel>

 <socks-channel>  <listener> <address>0.0.0.0</address>  <port>41080</port> </listener>  <valid-sock5-hosts>127.0.0.1;::1</valid-sock5-hosts> </socks-channel> <proxy-selector state="on">  <internaladdress>10.0.0.0/8;192.168.0.0/16;1.2.3.4/32</internaladdress>  <socks-servers loadBalance="no">10.1.2.3:41080</socks-servers> </proxy-selector>

 <proxy-manage> <valid-hosts>10.0.0.0/8;192.168.0.0/16</valid-hosts> <password>xxxxxxxxxxxxxxxxxxxxxxxx </password> </proxy-manage> </dmz-proxy> </proxy-config>

Internet Server Configuration Parameters

The Internet Server configuration parameters are as follows.

proxy-selector

● internaladdress: defines the target IP addresses that Internet Server routes through CMA. IPaddresses can be specified as a full IP address or an IP address with the number of subnet bits.Multiple IP addresses can be defined by separating them with a semicolon.

190


socks-server

● ipaddresses: defines the IP addresses and IP ports of the CMA servers. Use the format ofIPAddress:port when defining this parameter. Multiple CMA servers can be defined by separatingthe IP addresses with a semicolon.

● load-balance: this parameter is for future use and can be ignored.

proxy-manage

● valid-hosts: defines the MFTCC hosts that can manage this Internet Server. IP addresses can bespecified as a full IP address or an IP address with the number of subnet bits. Multiple IP addressescan be defined by separating them with a semicolon.


Configuring Internal ClientsWhen Internet Server establishes connections to internal servers, the TCP connection uses the IPaddress of Internet Server. Therefore, the internal server detects that Internet Server initiates theconnection request. When using Connection Manager, CMS initiates the TCP connection to the internalserver. The internal server detects that CMS initiates the connection request. Therefore, whenever aninternal server is configured to accept connections from a particular IP address, you must configure theCMS IP address instead of the Internet Server IP address.

Platform Server

When Platform Server is configured to Require Node Definitions or is using responder profiles, youmust create a node definition for each CMS server that can connect to Platform Server. Additionally, ifyou are using responder profiles, you must add a responder profile for each CMS node definition.

Database Servers

If database servers are configured to accept connections from particular Internet Servers, the databasemust be configured with the IP addresses or IP names of all of the defined CMS servers that can connectto this database server.

Best PracticesFor best results, follow the following guidelines when implementing the Connection Manager:

● Use the default ports whenever possible when installing and testing Connection Manager. Theseports are used only by Connection Manager and are not used by external clients. Firewalls must beconfigured to prohibit external client access to these ports. If you want to change the ports, makechanges one at a time and test the change before changing additional ports.

● Use the default configuration to start testing. The default configuration is very generic and can workin most environments. If you want to lock down Connection Manager, make one change at a timeand test this change before making additional changes.

● When adding a Connection Manager CMA, CMS, or Internet Server, always use the Test button toverify the connectivity information and password. This ensures that MFTCC can communicate withthe Connection Manager node.

● Use the Get Status button to determine the status of CMA, CMS, and Internet Server.● Get simple Connection Manager connectivity working before configuring more complicated high

availability or high availability Connection Manager connectivity.● After installation, you can use the CMA Get Status > Test buttons to test connectivity to the target

server in the internal network.

191


DebuggingFollow the following steps to debug Connection Manager:

1. Make sure that you configure the Connection Manager CMA, CMS, and Internet Server nodes withthe correct connectivity information and password. On the Add Connection Manager Node page,click the Test button to verify that the connectivity information is correct.

2. Verify that the firewall ports are opened as defined in the Firewall Considerations.

3. Use MFTCC to configure Internet Server, CMA, and CMS. If you cannot use MFTCC to retrieveconfiguration, a message is displayed to show the error. If you receive a connection error, check thefollowing things:

● Verify that the firewall has been opened for the necessary ports.

● Verify that the IP address and IP port have been configured correctly.

● Issue a NETSTAT command on the Connection Manager node to make sure the ConnectionManager node is listening on the defined port.

4. If you have connectivity to the Connection Manager nodes, but connections fail, use the CMA GetStatus > Test function. This function tests whether CMA can access the defined internal server.MFTCC tests are initiated from the CMA TCP Loopback address (127.0.0.1); therefore, make surethat the CMA Accept Connections from These Internet Servers field is configured to acceptchanges from 127.0.0.1 and ::1, in addition to the IP addresses of the Internet Server computers.Otherwise, tests initiated from MFTCC fail with an error indicating that CMA will not acceptrequests from local host.

5. Tracing can be configured to assist in debugging. For CMA and CMS, the default tracing is INFO; forInternet Server, the default tracing is ERROR. This writes trace files to the following directories:

● CMA: <CMA_Install>/bin/RPLog.txt

● CMS: <CMS_Install>/bin/RPLog.txt

● Internet Server: <MFTIS_Install>/server/logs/catalina.out

Generally speaking, look at the CMS tracing first. The CMS tracing documents problems inconnecting to CMA.

192


Appendix B. Configuring RADIUS Authentication

MFT supports authentication to a RADIUS server. This can be used to provide multi-factorauthentication using tokens or security cards. You can configure RADIUS authentication through theweb.xml file.

When configured, RADIUS authentication replaces all user ID and password authentications for theMFT instance, except for users configured in the RADIUS-SpecialUsers parameter in the web.xml file.

To configure RADIUS configuration, perform the following steps:

1. Updating the Trace Settings

2. Defining RADIUS Configuration Parameters

3. Setting the RADIUS Primary and Backup Secrets

4. Restarting the MFT Server

Updating the Trace SettingsTo configure RADIUS authentication, you must first update the trace settings.

Edit the log4j.properties file located in the <MFT_Install>\server\webapps\cfcc\WEB-INF\classes directory.

If the following RADIUS entries listed are not in the log4j.properties file, add these lines to this file.The placement of these lines is not important as long as it is not in the middle of another section.# Set logging level for RADIUS authenticationlog4j.logger.com.proginet.sift.login.RADIUSAuthMethod=TRACE, RADIUSFilelog4j.appender.RADIUSFile.File=${cfi.trace.dir}/RADIUS-trace.txtlog4j.appender.RADIUSFile=org.apache.log4j.DailyRollingFileAppenderlog4j.appender.RADIUSFile.ImmediateFlush=truelog4j.appender.RADIUSFile.Append=truelog4j.appender.RADIUSFile.DatePattern='-'yyyy-MM-ddlog4j.appender.RADIUSFile.layout=org.apache.log4j.PatternLayoutlog4j.appender.RADIUSFile.layout.ConversionPattern=%d{dd MMM yyyy HH:mm:ss} [%t] %-5p %c - %m%n

Normally the trace level is set to ERROR. It is good practice to set the trace level to TRACE whileconfiguring and testing RADIUS for the first time. After RADIUS is tested, set the trace level to ERROR.

For these changes to take place, the MFT server must be restarted.

Defining RADIUS Configuration ParametersAfter updating the trace settings, you have to define RADIUS configuration parameters in the web.xmlfile.

The web.xml file is typically located in the <MFT_Install>/server/webapps/cfcc/WEB-INF directory.To configure RADIUS authentication, you must add the following parameters to the web.xml file. Theseparameters should be placed with the other context-param parameters before the filter parameters.

See Sample web.xml RADIUS Parameters for sample RADIUS web.xml parameters.

193


Web.xml Parameter Description

RADIUS-Enabled Defines whether RADIUS authentication is enabled or disabled.


● True: RADIUS authentication is enabled and replaces MFT user IDand password authentication.

● False: RADIUS authentication is disabled. Standard MFT user IDand password authentication is used. This is the default value.

RADIUS-PrimarySecret Defines the primary RADIUS encrypted secret.

This parameter is set by executing the dbsettings utilityand must be set before performing RADIUS authentication.It cannot be set manually.

RADIUS-PrimaryHost Defines the IP address or IP name of the primary RADIUS server.

This parameter is required if RADIUS authentication is enabled.

RADIUS-PrimaryPort Defines the IP port of the primary RADIUS server.

This parameter is required if RADIUS authentication is enabled.

RADIUS-

PrimaryAdapterIP

Defines the IP address that is used when communicating with theprimary RADIUS server.

The default value of 0.0.0.0 indicates accepting responses over anyadapter.

RADIUS-BackupSecret Defines the backup RADIUS encrypted secret.

This parameter is required only if you want to communicate to abackup RADIUS server.

This parameter is set by executing the dbsettings utilityand must be set before performing RADIUS authentication.It cannot be set manually.

RADIUS-BackupHost Defines the IP address or IP name of the backup RADIUS server.


RADIUS-BackupPort Defines the IP port of the backup RADIUS server.


RADIUS-BackupAdapterIP Defines the IP address that is used when communicating with thebackup RADIUS server.

The default value of 0.0.0.0 indicates accepting responses over anyadapter.

194


Web.xml Parameter Description

RADIUS-Synchronous Defines whether communication to primary and backup RADIUSservers is synchronous or asynchronous.


● True: RADIUS authentication is synchronous. Communication tothe RADIUS backup host is only performed if communication tothe RADIUS primary host times out.

● False: RADIUS authentication is asynchronous. Requests aremade to both RADIUS primary host and RADIUS backup host atthe same time. MFT uses the first response that is received. Thisparameter is ignored if a RADIUS backup server is not defined.

RADIUS-Timeout Defines the number of seconds the RADIUS client waits for a responsefrom the RADIUS server before the request times out and fails.

RADIUS-SpecialUsers Defines the users to be authenticated using standard MFTauthentication in the event that RADIUS authentication fails.

You can define one or more MFT users separated by a semicolon.

Sample web.xml RADIUS ParametersTo configure RADIUS authentication, you have to define RADIUS configuration parameters in theweb.xml file.

The following example shows sample web.xml RADIUS parameters: <context-param> <param-name>RADIUS-Enabled</param-name> <param-value>True</param-value> </context-param> <context-param> <param-name>RADIUS-PrimarySecret</param-name> <param-value> </param-value> </context-param>

<context-param> <param-name>RADIUS-PrimaryHost</param-name> <param-value>10.1.2.100</param-value> </context-param>

<context-param> <param-name>RADIUS-PrimaryPort</param-name> <param-value>1812</param-value> </context-param>

<context-param> <param-name>RADIUS-PrimaryAdapterIP</param-name> <param-value>0.0.0.0</param-value> </context-param>

<context-param> <param-name>RADIUS-BackupSecret</param-name> <param-value> </param-value> </context-param>

<context-param> <param-name>RADIUS-BackupHost</param-name> <param-value>10.1.2.200</param-value>

195


</context-param>

<context-param> <param-name>RADIUS-BackupPort</param-name> <param-value>1812</param-value> </context-param>

<context-param> <param-name>RADIUS-BackupAdapterIP</param-name> <param-value>0.0.0.0</param-value> </context-param>

<context-param> <param-name>RADIUS-Synchronous</param-name> <param-value>False</param-value> </context-param>

<context-param> <param-name>RADIUS-Timeout</param-name> <param-value>10</param-value> </context-param>

<context-param> <param-name>RADIUS-SpecialUsers</param-name> <param-value>admin;mftuser</param-value> </context-param> 

Setting the RADIUS Primary and Backup SecretsAfter defining RADIUS configuration parameters in the web.xml file, you must execute the dbsettingsutility to save the RADIUS primary and backup secrets.

Follow the following instructions to execute this utility:

● On UNIX: navigate to the <MFT_Install>/distribution/util/dbsettings directory and run thedbsettings.sh file.

● On Windows: navigate to the <MFT_Install>\distribution\util\dbsettings directory and runthe dbsettings.bat file.

Follow the instructions to set the RADIUS primary and backup secret keys.

Restarting the MFT ServerFor the RADIUS authentication configurations to take effect, you must restart the MFT server aftercompleting the RADIUS authentication configurations.

196


Appendix C. web.xml Parameters

Most TIBCO MFT Internet Server and TIBCO MFT Command Center parameters are configuredthrough the Administrator web pages. But, some parameters, which are infrequently used or must beconfigured at server startup, must be configured in the web.xml file.

The web.xml file is located in the <MFT_Install>\server\webapps\cfcc\WEB-INF directory.

In most cases, you should not update the web.xml parameters unless instructed to do so by TIBCOTechnical Support.

The web.xml parameters are defined by the context-parm element. The parameter name is defined bythe param-name attribute while the parameter value is defined by the param-value attribute.

After updating the web.xml file, the MFT server must be restarted for the changes of the web.xml file totake effect.

If MFT detects an XML syntax error, the MFT server does not start. See the catalina.out file in the<MFT_Install>\server\logs directory for details.

The web.xml parameters are divided by functionality into the following categories:

● Security Parameters: parameters that affect the security of the MFT instance.

● Miscellaneous Parameters: parameters that do not fit into the other categories.

● Connectivity and Protocol Parameters: parameters associated with file transfers and file transferprotocols.

● RADIUS Authentication Parameters: parameters associated with RADIUS authentication.

● OEM Parameters: parameters that can be used to change the product names and branding.

● Database Driver Parameters: parameters associated with the JDBC connection.

● Database Pooling Parameters: parameters associated with database pooling.

Security ParametersSecurity parameters affect the security of the MFT instance.

The following table lists the security parameters:

Parameter Default Description

SessionTimeOut 30 Defines the session timeout in minutes for active SFTPconnections and FTP control connections.

If the connection is inactive for longer than the definedtimeout, the next request fails.

The HTTP timeout is set by the SessionTimeOutparameter configured in the web.xml file located in the<MFT_Install>\server\conf directory.

197



InstallAdminServ

ice

Set duringinstallation

Defines whether the Administrator service is installed onan Internet Server instance.

If the Administrator service is installed, this parameter isset to YES. If you set it to NO, Administrator servicerequests for this Internet Server fail.

If the Administrator service for the InternetServer instance is not installed and is set to NOby the installer, setting this parameter to YESwill be ignored.

PasswordHashNew SHA-256 Defines the hashing algorithm used when a userpassword is changed or a new user is created.

Because this password is a hash, it cannot be decrypted.

UnsecuredHTTPSup

port

NO Defines whether HTTP requests will be accepted.

The default value of NO indicates that HTTP requests willnot be accepted. When it is set to YES, HTTP requests willbe accepted if an HTTP connector is defined.

Anonymous No default Defines users that can log in without passwordvalidation.

Make sure that these users have limited file transferauthorization. More importantly, make sure that theseusers do not have any administrator rights.

BCProvider No default Defines the BouncyCastle security provider.

Use the default value unless you are instructed by TIBCOTechnical Support to change this.

AllowedReferersA

dminJSP

By default,referrer URLchecking will notbe performed.

Defines the referrer URLs supported by MFT.

Defining referrer URLs provides an additional layer ofsecurity to MFT.

This parameter is used by the administrator JSP pages.You can define multiple URLs separated by commas.

You should enter the URL for this MFT server.

AllowedReferersF

orXferNavigation

By default,referrer URLchecking will notbe performed.

Defines the referrer URLs supported by MFT.

Defining referrer URLs provides an additional layer ofsecurity to MFT.

This parameter is used by the file transfer client. You candefine multiple URLs separated by commas.

You should enter the URL for this MFT server.

198



SmtpTLSEnabled false Defines whether SSL/TLS is used when communicatingto an SMTP server.

The value of false indicates that SSL/TLS will not beused.

The value of true indicates that the SMTPcommunication will be performed using SSL.

PrivacyPolicyURL No default Defines the URL of the privacy policy link that is addedto the footer of each browser page.

When no value is defined, the footer will not contain aprivacy policy link.

When any value is defined, the View Privacy Policy linkwill be displayed on the footer of each page. You canclick this link to open a privacy policy page.

MFT does not provide a privacy policy page.You must define a privacy policy page that willbe opened by the View Privacy Policy link.

LoadBalancerIPAd

dressList

No default For HTTP requests that go through a load balancer, MFTuses the HTTP header X-Forwarded-For IP address as theIP address of the incoming request when the actual IPaddress matches one of the addresses defined by thisparameter.

You can define multiple Load Balancer IP addresses byseparating them with a semicolon.

Miscellaneous ParametersMiscellaneous parameters refer to parameters that do not fit into the other categories.

The following table lists the miscellaneous parameters:


TraceDir The directorydefined duringinstallation

Defines the directory where MFT trace files arelocated.

MessageDir The directorydefined duringinstallation

Defines the directory where MFT message filesare located.

WebAdminLogFile The directorydefined duringinstallation

Defines the directory where MFT WebAdminfiles are located.

AuditDir The directorydefined duringinstallation

Defines the directory where MFT audit filesare located.

199



ExpiredFilesLog ./

ExpiredFilesLog.

txt

This parameter is not used.

crystal_image_uri /cfcc/control?

view=view/cfcc/

crystalreportvie

wers11

Defines the URL for the MFT reportingapplication.

HostName The host namedefined duringinstallation

Defines the host name that is set during theconfiguration process.

This parameter is used to identify the MFTserver in the database tables. This should notbe changed without guidance from TIBCOTechnical Support.

AssignViewEmailContent

sRight

admin This parameter is not used.

SendGlobalEmail true This parameter is not used.

EmbeddedServer true This parameter should always be set to true.

MinimumJREVersion 1.7.0+ Defines the minimum JRE version for the Javafile transfer applet.

If the version is lower than this value, the useris prompted to upgrade the Java version.

HttpSSOCustomizationCo

nfigFile

No default Defines the HTTP SSO customization file.

This should only be used when the server isconfigured to support SSO. Generally, thisparameter is set to the SSO configuration file,httpssocustomization.xml.

tilesDefinitions /WEB-INF/

tiles.xml

This parameter should not be changed.

SoapSkipFieldsConfigFi

leName

No default When a customer uses SOAP calls and wantsto upgrade MFT to a different version, settingthis parameter defines the SOAP calls to becompatible with older versions of MFT.

Any RETRIEVE or GET call returns data in theformat defined by MFT version 7.2.4.

DefaultTransferClient browser Defines the default transfer client.

The value of browser indicates the defaulttransfer client is the browser client. It is goodpractice to use the browser client by default.

The value of java indicates the default transferclient is the Java client.

200



MaximumFileNumber 10000 Defines the maximum number of files to bereturned to the browser or Java client for asingle directory scan.

SyncLdapAtLogon true Defines whether an LDAP user will besynchronized with the LDAP authenticatorwhen HTTP users log on.

The value of True indicates that LDAP userswill be synchronized when the user logs on.

The value of False indicates that LDAP userswill not be synchronized with the LDAPauthenticator when the user logs on. Thesynchronization is performed when the on-demand or scheduled synchronization occurs.

SearchAuditAtPageEntry true Defines whether MFT performs an auditsearch when the Search Audits page is firstconfigured.

The value of true indicates that MFT performsan audit search when the Search Audits pageis first configured.

The value of false indicates that MFT doesnot perform an audit search when the SearchAudits page is first configured. Searches are ondemand when the user defines the selectioncriteria and click Search.

Connectivity and Protocol ParametersConnectivity and protocol parameters are associated with file transfers and file transfer protocols.

The following table lists the connectivity and protocol parameters:


TLSSecurityProvider The default MFTsecurity provider

Defines the security provider used by FTP andPlatform Server SSL connections.

TLSCipherSuite No default Defines the cipher suites used by FTPS andPlatform Server SSL connections.

This parameter is used to limit the cipher suitesused in creating FTP or Platform Server SSLconnections. MFT typically defaults to usingsecure cipher suites during installation.

HTTPS cipher suites are defined inthe HTTPS connector in theserver.xml file located inthe<MFT_Install>/server/confdirectory.

201



TLSProtocols TLSV1, TLSV1_1,

TLSV1_2

Defines the protocols supported by FTP andPlatform Server SSL connections.

TCPBufSize 256000 Defines the TCP buffer size used by SSL, FTP,and Platform Server connections.

Using a high value will increase performanceover connections with high latency.

FTPFileNameEncoding ISO-8859-1 Defines the file name encoding for FTPconnections.

The default value of ISO-8859-1 can work formost western European languages. For double-byte languages, set this value to UTF-8.

SSHSecurityProvider The default MFTsecurity provider

Defines the security provider used by SFTPconnections.

SSHCipherSuite All SSH ciphers Defines the SSH cipher suites supported.

When the MFT SFTP (SSH) server is started, itdisplays the SSH ciphers supported in thecatalina.out file. Look for the header, SSHServer - supported ciphers.

SSHKeyExchange All SSH KeyExchangealgorithms exceptthe insecure diffie-hellman-group1-sha1 algorithm

Defines the SSH key exchange algorithmssupported.

Some older SFTP clients might require diffie-hellman-group1-sha1. When the MFT SFTP(SSH) server is started, it displays the SSH keyexchange algorithms supported in thecatalina.out file. Look for the header, SSHServer - supported key exchange.

SSHDigestSuite All SSH DigestSuites

Defines the SSH digest suites supported.

When the MFT SFTP (SSH) server is started, itdisplays the SSH ciphers supported in thecatalina.out file. Look for the header, SSHServer - supported hash.

SSHFileNameEncoding ISO-8859-1 Defines the file name encoding for SFTP (SSH)connections.

The default value of ISO-8859-1 can work formost western European languages.

For double-byte languages, set this value toUTF-8.

202



AS2TempDirectory No default Defines the AS2 temporary directory. Thisparameter is generally defined only when verylarge (larger than 500MB) AS2 files aretransferred.

This parameter defines MFT to use a two-stageAS2 transfers. For uploads to MFT, encryptedAS2 data is written to this directory beforebeing transferred to the target internal MFTservers. For downloads from MFT, encryptedAS2 data is written to this directory beforebeing transferred to the target AS2 server.

When this parameter is not defined, data isstreamed from AS2 to the target server withoutwriting it to a disk.

AS2Acknowledgement No default When very large AS2 requests are received orsent, set this parameter to deferred.Encrypted AS2 data will be written to thedirectory defined by the AS2TempDirectoryparameter and then processed.

TempDir No default Defines a temporary directory that MFT useswhen virus scanning is enabled.

DisplayFTPBanner YES Defines whether the FTP/SFTP banner isdisplayed when the user logs on.

The value of YES indicates that the FTP/SFTPbanner is displayed when the user logs on.

The value of NO indicates that the FTP/SFTPbanner is not displayed when the user logs on.

RADIUS Authentication ParametersRADIUS authentication parameters are used to configure RADIUS authentication.

The following table lists the RADIUS authentication parameters:


RADIUS-Enabled False Defines whether all user ID and passwordauthentications use the RADIUS protocol.

The value of true indicates that all user ID andpassword authentications use the RADIUSprotocol.

The value of false indicates that the RADIUSprotocol is not used.

The following parameters are available only when the RADIUS-Enabled parameter is set to true:

203



RADIUS-PrimarySecret No default Defines the primary RADIUS server secret.

You must set this parameter before performingRADIUS authentication.

This parameter can only be set byusing the dbsettings utility; itcannot be set manually.

RADIUS-PrimaryHost No default Defines the IP address or name of the primaryRADIUS host.

RADIUS-PrimaryPort No default Defines the port of the primary RADIUS host.

RADIUS-

PrimaryAdapterIP

No default Defines the binding adapter IP address of theprimary RADIUS host.

RADIUS-BackupSecret No default Defines the backup RADIUS server secret.

You must set this parameter before performingRADIUS authentication.

This parameter can only be set byusing the dbsettings utility; itcannot be set manually.

RADIUS-BackupHost No default Defines the IP address or name of the backupRADIUS host.

RADIUS-BackupPort No default Defines the port of the backup RADIUS host.

RADIUS-BackupAdapterIP No default Defines the binding adapter IP address of thebackup RADIUS host.

RADIUS-Synchronous True Defines whether communication to primaryand backup RADIUS servers is synchronous orasynchronous.

The value of True indicates that the RADIUSauthentication is synchronous. Communicationto the backup RADIUS host is only performedif communication to the primary RADIUS hosttimes out.

The value of False indicates that the RADIUSauthentication is asynchronous. Requests aremade to both the primary RADIUS and backupRADIUS hosts at the same time. MFT uses thefirst response that is received.

This parameter is ignored if nobackup RADIUS server is defined.

204



RADIUS-Timeout 10 Defines the RADIUS authentication timeout inseconds.

If a response is not received in this amount oftime, the request fails.

RADIUS-SpecialUsers No default Defines users that will not be authenticated bythe RADIUS protocol.

It is good practice to add one user(administrator) that is not authenticated byRADIUS.

OEM ParametersOEM parameters are used to change the product names and branding.

The following table lists the OEM parameters:


OEM-CompanyName TIBCO Software

Inc.

Defines the text to be displayed when the longcompany name is displayed on a web page.

OEM-ShortCompanyName TIBCO Defines the text to be displayed when the shortcompany name is displayed on a web page.

OEM-LongProductName TIBCO Managed

File Transfer

Defines the text to be displayed when the longproduct name is displayed on a web page.

OEM-ShortProductName MFT Defines the text to be displayed when the shortproduct name is displayed on a web page.

OEM-Copyright Copyright (c)

2003-2016. TIBCO

Software Inc.

All Rights

Reserved.

Defines the copyright information.

This should not be changed. Changing thismight be a violation of the TIBCO licenseagreement.

OEM-InternetServerName Internet Server Defines the text to be displayed when theproduct name of TIBCO MFT Internet Server isdisplayed.

OEM-CommandCenterName Command Center Defines the text to be displayed when theproduct name of TIBCO MFT Command Centeris displayed.

OEM-PlatformServerName Platform Server Defines the text to be displayed when theproduct name of TIBCO MFT Platform Server isdisplayed.

205



OEM-InternetName Internet Defines the text to be displayed when the shortproduct name of TIBCO MFT Internet Server isdisplayed.

OEM-PlatformName Platform Defines the text to be displayed when the shortproduct name of TIBCO MFT Platform Server isdisplayed.

OEM-ProductURL http://

www.tibco.com/

products/

automation/

application-

integration/

managed-file-

transfer/

default.jsp

Defines the URL of the link to the TIBCOwebsite for the MFT server.

OEM-CompanyURL http://

www.tibco.com

Defines the URL of the link to the TIBCOwebsite.

Database Driver ParametersDB driver parameters are associated with the JDBC connection.

The following table lists the DB driver parameters:


DBDriver The JDBC driverclass name definedduring installation

Defines the JDBC driver class.

This parameter is rarely changed unless youdecide to change the JDBC driver used byMFT.

DBConn The JDBC URLdefined duringinstallation

Defines the JDBC URL.

This parameter is rarely changed after the MFTinstallation. It can occasionally be changedwhen you want to add the SSL support or theHigh Availability support.

DBUser The database userdefined duringinstallation

Defines the database user associated with theJDBC connection.

DBPass The encrypteddatabase passworddefined duringinstallation

Defines the password of the database userassociated with the JDBC connection.

DBPwdEncrypted true Defines whether the database password isencrypted.

206



OracleDatabaseSSLCiphe

rSuites

SSL_DH_anon_WITH_

3DES_EDE_CBC_SHA

SSL_DH_anon_WITH_

RC4_128_MD5

SSL_RSA_WITH_3DES

_EDE_CBC_SHA

Defines the cipher suites used by Oracle JDBCconnections.

Different Oracle server releases requiredifferent SSL cipher suites.

Database Pooling ParametersDB pooling parameters are used to configure database pooling.

The following table lists the DB pooling parameters:


DataBasePoolingFlag APACHE Defines whether connection pooling issupported.

The value of APACHE indicates that connectionpooling is used.

The value of None indicates that connectionpooling is not used.

MaxActive 400 Defines the maximum number of activeconnections available to database pooling.

400 active connections should be sufficient forall but the most active MFT system.

MaxIdle 20 Defines the maximum number of idleconnections that should be kept in the databasepool at all times.

MinIdle 10 Defines the minimum number of idleconnections that should be kept in the databasepool at all times.

MaxWaitTime 1 Defines the time in minutes that databasepooling waits for a connection before theconnection request fails.

ValidationQuery SELECT COUNT(1)

FROM FtpSrvCfg

Defines the query executed when theTestOnBorrow, TestOnReturn, orTestWhileIdle parameter is set to true.

TestWhileIdle true Defines whether connections should be testedwhile they are idle. Connections are testedbased on the interval defined by theTimeBetweenEvictionRuns parameter.

207



TestOnBorrow true Defines whether existing connections in thepool should be tested before use.

It is good practice to set this parameter to true.

TestOnReturn false Defies whether existing connections in the poolshould be tested after being used and returnedto the pool.

It is good practice to set this parameter tofalse.

TimeBetweenEvictionRu

ns

20 Defines the time in minutes to wait betweenexecution of the idle connection validationclasses.

MinEvictableIdleTime 40 Defines the time in minutes for a connection tobe idle before it is eligible for eviction.

208

Date post:	16-May-2020
Category:	Documents
Upload:	others
View:	30 times
Download:	0 times

TIBCO Managed File Transfer Command Center User's Guide€¦ · TIBCO® Managed File Transfer...

Documents